> über uns > bedingungen richtlinien > Sicherheitsmaßnahmen

Sicherheitsmaßnahmen

Sicherheitsmaßnahmen
PDF

Sicherheitsmaßnahmen von ProcessMind

Gültig ab: 14. September 2026

Dieses Dokument beschreibt die technischen und organisatorischen Maßnahmen („TOMs“), die ProcessMind B.V. zum Schutz der Vertraulichkeit, Integrität und Verfügbarkeit von Kundendaten unterhält. ProcessMind verfolgt einen mehrschichtigen Sicherheitsansatz, bei dem mehrere unabhängige Sicherheitsebenen Kundendaten auf jeder Ebene schützen – vom Netzwerk und der Infrastruktur über Identität, Autorisierung, Datentrennung, Verschlüsselung, Überwachung und Softwareentwicklung. Diese Maßnahmen ergänzen den Nachtrag zur Auftragsverarbeitung, die Datenschutzerklärung und die SaaS-Hosting-Richtlinie. ProcessMind überprüft und aktualisiert diese Maßnahmen mindestens einmal jährlich.

Kundendaten werden niemals an Dritte verkauft, mit ihnen geteilt oder von ihnen für eigene Zwecke verwendet.

1. Infrastruktursicherheit

1.1 Cloud-Plattform. ProcessMind wird ausschließlich auf Amazon Web Services (AWS) in der EU (Frankfurt, Deutschland, eu-central-1) gehostet. AWS verfügt über Zertifizierungen nach ISO 27001, ISO 27017, ISO 27018, SOC 1/2/3 und PCI DSS. Eine vollständige Liste finden Sie unter AWS Compliance Programs.

1.2 Serverlose Architektur. Die Anwendungslogik von ProcessMind wird auf AWS Lambda und von AWS verwalteten Diensten ausgeführt. ProcessMind betreibt keine kundenseitig verwalteten, dauerhaft laufenden Anwendungsserver. Dadurch entfällt ein großer Teil der Arbeiten zum Einspielen von Betriebssystem-Patches und zur Härtung von Servern.

1.3 Netzwerkgrenzen. ProcessMind unterhält eine AWS VPC für Datenbank- und Netzwerkkontrollen. Aurora PostgreSQL wird in privaten Subnetzen ohne ausgehenden Internetzugriff betrieben, ist nicht öffentlich zugänglich und VPC-Flow-Logs sind aktiviert. ProcessMind platziert Anwendungs-Lambda-Funktionen standardmäßig nicht innerhalb der VPC. Lambdas greifen über die AWS RDS Data API mittels TLS und unter Verwendung von IAM- und Secrets-Manager-Authentifizierung auf Aurora zu.

1.4 Inhaltsbereitstellung und Edge-Kontrollen. Die kundenorientierte Website, die Frontend-SPA und der Datenverkehr zu öffentlichen Ressourcen werden über Amazon CloudFront bereitgestellt. Für alle CloudFront-Distributionen gilt eine Mindest-TLS-Richtlinie von TLS 1.2 (2021). Die Distributionen der Website und der Frontend-SPA fügen außerdem Sicherheitsheader für Antworten hinzu, darunter HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), frame-ancestors 'none', X-Frame-Options: DENY, X-Content-Type-Options, eine Referrer-Richtlinie und eine Berechtigungsrichtlinie. Die Distribution für öffentliche Ressourcen verwendet CloudFront Origin Access Control, um den Ursprungs-Bucket privat zu halten. Der kundenorientierte API-Datenverkehr wird separat über Amazon API Gateway abgewickelt: HTTPS-Anfrage-/Antwortverkehr wird über eine HTTP API auf einer dedizierten API-Subdomain bereitgestellt, und Echtzeitverbindungen von Clients werden über eine separate API-Gateway-WebSocket-API auf einer dedizierten WebSocket-Subdomain bereitgestellt.

1.5 Trennung der Umgebungen. Produktions- und Entwicklungsumgebungen verwenden separate AWS-Konten, separate Datenbanken und separate Infrastruktur-Stacks. Entwicklerzugangsdaten gewähren keinen Zugriff auf Produktionskundendaten.

2. Datenverschlüsselung

2.1 Verschlüsselung bei der Übertragung. Alle zwischen Clients und ProcessMind-Diensten übertragenen Daten werden mit TLS 1.2 oder höher verschlüsselt. Kundenorientierte Endpunkte sind über HTTPS erreichbar. S3-Buckets, SNS-Themen und SQS-Warteschlangen, die ProcessMind direkt erstellt, erzwingen den ausschließlichen Zugriff über SSL. Der Datenbankzugriff über die RDS Data API und andere AWS-Dienstaufrufe erfolgt über HTTPS/TLS.

2.2 Verschlüsselung im Ruhezustand. Aurora PostgreSQL wird im Ruhezustand mit kundenseitig verwalteten AWS-KMS-Schlüsseln und automatischer Schlüsselrotation verschlüsselt. Kundendaten- und Betriebs-S3-Buckets, die ProcessMind direkt erstellt, einschließlich Buckets für Uploads, Ressourcen und Zugriffsprotokolle, verwenden kundenseitig verwaltete KMS-Schlüssel. CloudWatch-Loggruppen, SNS-Themen und SQS-Warteschlangen, die ProcessMind direkt erstellt, verwenden ebenfalls kundenseitig verwaltete KMS-Schlüssel. SST-verwaltete Ursprungs-Buckets für Website und Frontend verwenden die von AWS verwaltete serverseitige S3-Verschlüsselung (SSE-S3 / AES-256) anstelle kundenseitig verwalteter KMS-Schlüssel.

2.3 Schlüsselverwaltung und Geheimnisse. Datenbankverschlüsselungsschlüssel werden zentral über AWS KMS verwaltet; der Schlüsselzugriff unterliegt IAM-Richtlinien, die dem Prinzip der geringsten Berechtigungen folgen. Datenbankzugangsdaten werden in AWS Secrets Manager gespeichert. Das Aurora-Master-Geheimnis und das eingeschränkte Geheimnis des Anwendungsbenutzers werden automatisch alle dreißig (30) Tage rotiert. Produktionsschlüssel und -geheimnisse werden niemals im Quellcode gespeichert; ausschließlich für die Entwicklung bestimmte Zugangsdaten sind von der Produktionsumgebung getrennt. Einige von AWS/CDK/SST verwaltete unterstützende Ressourcen verwenden weiterhin die von AWS verwaltete Verschlüsselung, wenn der Dienst oder das Framework keine Konfiguration kundenseitig verwalteter Schlüssel ermöglicht.

3. Datentrennung und Datenstandort

3.1 Mandantentrennung. Jeder Kundenmandant erhält eine dedizierte, isolierte Datenbankinstanz. Kundendaten werden auf Datenbankebene niemals mit den Daten anderer Kunden vermischt. Gemeinsam genutzte Metadaten (z. B. Kontodatensätze, Abrechnungsdaten und Zuordnungen von Benutzern zu Mandanten) werden in einer separaten mandantenfähigen Datenbank mit strengen Zugriffskontrollen gespeichert. Gemeinsam genutzte Tabellen mit Mandanten- und Organisationsbezug werden zusätzlich durch PostgreSQL-Richtlinien zur Sicherheit auf Zeilenebene (RLS) geschützt, die über einen anfragebezogenen Datenbankkontext durchgesetzt werden.

3.2 Datenstandort. Alle Kundendaten, einschließlich Datenbanken, Datei-Uploads, Backups und Abfrageergebnisse, werden ausschließlich in der EU (Frankfurt, Deutschland) gespeichert. Wird für eine bestimmte Verarbeitungstätigkeit ein außerhalb des EWR ansässiger Unterauftragsverarbeiter eingesetzt (zum Beispiel für die Verarbeitung durch KI-Modelle oder die Zahlungsabwicklung), ist die Übermittlung durch einen geeigneten Übermittlungsmechanismus abgedeckt, wie im Auftragsverarbeitungszusatz beschrieben; der Unterauftragsverarbeiter und sein Verarbeitungsstandort sind in der Liste der Unterauftragsverarbeiter aufgeführt.

3.3 Datenaufbewahrung und Löschung. Die Aufbewahrungs- und Löschfristen sind in Abschnitt 6 des Nachtrags zur Auftragsverarbeitung festgelegt. Kunden können ihre Daten jederzeit über die Anwendung oder durch Kontaktaufnahme mit ProcessMind löschen. Sicherungskopien werden entfernt, sobald die jeweils geltenden Aufbewahrungsfristen für Sicherungskopien ablaufen (Abschnitt 7.1).

4. Identitäts- und Zugriffsverwaltung

4.1 Authentifizierung. ProcessMind unterstützt Single Sign-On (SSO) über Microsoft Entra ID (Azure AD), Google OAuth 2.0/OIDC und LinkedIn OAuth 2.0/OIDC. ProcessMind fungiert als vertrauende Partei und speichert keine Benutzerpasswörter. Die Mehr-Faktor-Authentifizierung wird vom Identitätsanbieter durchgesetzt – wenn beispielsweise eine Organisation Microsoft Entra ID (Azure AD) verbindet, gelten die eigenen MFA- und Zugriffsrichtlinien dieser Organisation.

4.2 Sitzungsverwaltung. Browsersitzungen verwenden signierte JSON Web Tokens (JWT), die über sichere HttpOnly-Cookies mit SameSite- und Secure-Flags übertragen werden. Die Token-Signaturen werden bei jeder authentifizierten Anfrage überprüft.

4.3 Autorisierungsmodell. ProcessMind ist für seine zentralen Anwendungs-APIs nicht auf native API-Gateway-Autorisierer angewiesen. Die Autorisierung wird in gemeinsam genutzten Lambda-Handler-Wrappern durchgesetzt, die den Sitzungsstatus und den Mandantenbereich überprüfen, bevor die Geschäftslogik ausgeführt wird. Öffentliche Routen sind ausdrücklich für nicht authentifizierte Abläufe, Webhooks, die Erfassung von Ereignissen und CORS-Preflight-Anfragen freigegeben. Externe API-Endpunkte verwenden dedizierte Authentifizierungs-Handler. Der Zugriff auf Kundendaten ist auf den Kontext des authentifizierten Mandanten oder der Organisation beschränkt.

4.4 Geringstmögliche Berechtigungen. Interne Systeme folgen dem Prinzip der geringstmöglichen Berechtigungen. IAM-Rollen werden, soweit das Framework eine präzise Eingrenzung ermöglicht, auf die mindestens erforderlichen Ressourcen beschränkt. Einige von SST/CDK generierte Rollen verwenden für Bindings und den Laufzeitbetrieb weiter gefasste verwaltete oder Inline-Richtlinien; diese Fälle werden überprüft, soweit möglich auf Ressourcen beschränkt und als ausdrückliche Ausnahmen erfasst.

4.5 Zugriffskontrollen für Beschäftigte. Der Zugriff von Beschäftigten auf interne Systeme wird über Active Directory mit SSO und verpflichtender MFA verwaltet. Die rollenbasierte Zugriffskontrolle (RBAC) stellt sicher, dass der Zugriff auf Kundendaten auf befugtes Personal beschränkt ist, das diese Daten zur Erfüllung seiner Aufgaben benötigt. Zugriffsrechte werden regelmäßig überprüft.

5. Protokollierung, Überwachung und Audit

5.1 Zentralisierte Protokollierung. Die HTTP-API-Zugriffsprotokollierung und die WebSocket-Zugriffsprotokollierung sind mit strukturierten JSON-Feldern aktiviert und werden mit einer Aufbewahrungsdauer von einem (1) Jahr in Amazon CloudWatch Logs geschrieben. Diese Zugriffsprotokollgruppen sind mit einem vom Kunden verwalteten AWS-KMS-Schlüssel verschlüsselt. Anwendungsprotokolle werden in zentralisierten Amazon-CloudWatch-Protokollgruppen gespeichert, die mit einem vom Kunden verwalteten AWS-KMS-Schlüssel verschlüsselt sind und zehn (10) Jahre lang aufbewahrt werden. Separate Audit- und Telemetrie-Protokollgruppen sind ebenfalls mit einem vom Kunden verwalteten AWS-KMS-Schlüssel verschlüsselt und werden zehn (10) Jahre lang aufbewahrt. Die Exportgruppe für die Aurora-PostgreSQL-Engine-Protokolle wird eine (1) Woche lang aufbewahrt.

5.2 Was protokolliert wird und was nicht. ProcessMind protokolliert HTTP-API- und WebSocket-Zugriffsereignisse – Anforderungszeitpunkt, Anforderungskennungen, Route oder Pfad, Antwortstatus und Latenz. Die Zugriffsprotokolle enthalten weder die Quell-IP-Adresse noch den User-Agent des Aufrufers. ProcessMind protokolliert außerdem Authentifizierungsereignisse, asynchrone Fehlerpfade und unterstützende Lambda-Anwendungsaktivitäten in zentralisierten CloudWatch-Protokollgruppen. VPC-Flow-Logs sind aktiviert. ProcessMind aktiviert derzeit keine standardmäßige CloudFront-Zugriffsprotokollierung für die Website, die Frontend-SPA oder die Verteilungen öffentlicher Ressourcen.

5.3 Überwachung und Alarmierung. CloudWatch-Alarme und -Dashboards überwachen den Systemzustand, Dead-Letter-Queues und sicherheitsrelevante Fehler. Fehler bei der asynchronen Verarbeitung werden an verschlüsselte Dead-Letter-Queues weitergeleitet (Aufbewahrung für vierzehn (14) Tage; zwei (2) Tage für die Warteschlangen für Miniaturansichten und Suchindizes), und DLQ-Alarme lösen SNS-Benachrichtigungen zur Untersuchung aus. Darüber hinaus verwendet ProcessMind Sentry zur Echtzeitverfolgung von Frontend-Fehlern, zur Leistungsüberwachung und zur Sitzungswiedergabe. Sitzungswiedergaben werden nur für Sitzungen aufgezeichnet, in denen ein Fehler auftritt; Text, Formulareingaben und Medien werden in den Wiedergaben maskiert oder blockiert. Sentry-Daten werden in der EU (Frankfurt) erfasst und sind auf ProcessMind-Nutzungsdaten beschränkt (Browserfehler, Leistungstraces, Gerätemetadaten und maskierte Sitzungsaufzeichnungen). Sentry ist in der Liste der Unterauftragsverarbeiter aufgeführt.

5.4 Schutz von Protokollen. Protokolle werden in dedizierten, zugriffskontrollierten CloudWatch-Loggruppen gespeichert und im Ruhezustand verschlüsselt. Produktions- und Entwicklungsprotokolle werden durch getrennte Umgebungen und Kontogrenzen voneinander getrennt.

6. Automatisierte Kontrollvalidierung und Schwachstellenmanagement

6.1 Maßnahmen von ProcessMind. ProcessMind führt cdk-nag im Rahmen seines Infrastruktur-Synthese- und Bereitstellungsablaufs unter Verwendung mehrerer branchenüblicher Regelpakete aus (einschließlich AWS Solutions, NIST 800-53 und PCI DSS). Für jeden Stack werden Berichte erstellt und im Rahmen des Änderungsmanagements der Infrastruktur überprüft. Feststellungen werden als behoben, als akzeptiertes Risiko oder als geplante Verbesserung eingestuft.

6.2 Umgang mit Ausnahmen. Ausnahmen werden, soweit das Framework dies ermöglicht, in einem zentralen Register erfasst, auf die betroffenen Stacks beschränkt und müssen schriftlich begründet werden; enthält ein Stack eine Inline-Ausnahme, wird diese zusammen mit dem betreffenden Stack dokumentiert. Wird eine Feststellung behoben, wird die entsprechende Ausnahme aktualisiert oder entfernt. ProcessMind betrachtet eine Ausnahme nicht als pauschalen Ausschluss von einer Überprüfung.

6.3 Was ProcessMind derzeit nicht tut. ProcessMind erfasst und überprüft wesentliche Ausnahmen von Infrastrukturkontrollen. Die wichtigsten sind:

  • Anwendungs-Lambdas werden standardmäßig nicht innerhalb der VPC platziert; sie greifen über die RDS Data API mit TLS sowie IAM- und Secrets-Manager-Authentifizierung auf Aurora zu
  • Kein Teil des Dienstes ist durch AWS WAF geschützt: AWS WAF unterstützt keine API Gateway HTTP APIs, und auch die übrigen Einstiegspunkte sind nicht durch WAF geschützt (WebSocket-Verbindungen verwenden kurzlebige HMAC-Token; geografische Beschränkungen für Zahlungen werden im Zahlungssystem durchgesetzt); für statische Distributionen ist außerdem kein standardmäßiges CloudFront-Zugriffsprotokoll aktiviert
  • Die Datenbankwiederherstellung stützt sich auf automatisierte Aurora-Backups und Point-in-Time-Recovery statt auf einen separaten AWS-Backup-Plan oder Aurora Enhanced Monitoring
  • Es gibt keine regionsübergreifende S3-Replikation und keine S3 Object Lock für veränderbare Buckets
  • Einige von AWS/CDK/SST verwaltete unterstützende Ressourcen verwenden von AWS verwaltete Verschlüsselung oder weiter gefasste, generierte IAM-Richtlinien, wenn der Dienst keine vom Kunden kontrollierbare Alternative bietet

Das vollständige Verzeichnis der Ausnahmen wird zusammen mit dem Infrastrukturcode gepflegt und ist auf Anfrage verfügbar. Die Verwendung von cdk-nag Regelpaketen dient der technischen Validierung von Kontrollen und stellt weder eine externe Zertifizierung noch ein Prüfungsurteil oder eine rechtliche Bestätigung der HIPAA-, NIST- oder PCI-DSS-Konformität dar.

6.4 Abhängigkeitsmanagement. Softwareabhängigkeiten werden kontinuierlich auf bekannte Schwachstellen überwacht. Schwachstellen mit kritischem und hohem Schweregrad werden mit dem Ziel behoben, dies innerhalb von sieben (7) Tagen zu tun. Abhängigkeiten werden regelmäßig aktualisiert.

6.5 Sicherer Softwareentwicklungslebenszyklus (SDLC). ProcessMind verfolgt bei der Softwareentwicklung einen Defense-in-Depth-Ansatz. Jede Änderung an der Produktionsumgebung muss vor der Bereitstellung mehrere unabhängige automatisierte Validierungsebenen durchlaufen:

  • Statische Analyse und Typsicherheit: Der strikte Modus von TypeScript und ESLint erzwingen zur Kompilierzeit Typkorrektheit, Null-Sicherheit und sicherheitsrelevante Programmiermuster.
  • KI-gestützte Codeprüfung: Die KI-gestützte Analyse bietet eine zusätzliche Prüfungsperspektive für Pull Requests, um Sicherheitsrisiken, Logikfehler und Abweichungen von Konventionen zu erkennen, und ergänzt damit automatisierte Tests.
  • Unit- und Integrationstests: Eine umfassende Vitest-Testsuite validiert Geschäftslogik, Datenzugriffsmuster, API-Verhalten und Fehlerbehandlung anhand aktiver AWS-Ressourcen in der Entwicklungsumgebung.
  • End-to-End-Tests: Browsertests auf Basis von Playwright überprüfen kritische Benutzerabläufe, einschließlich Authentifizierung, Daten-Upload, Prozessmodellierung, Simulation und mandantenübergreifender Isolation.
  • Prüfung der Infrastrukturkonformität: cdk-nag validiert Infrastruktur als Code bei jeder Änderung anhand mehrerer Compliance-Frameworks.
  • Prüfung von Abhängigkeiten auf Schwachstellen: Automatisierte Abhängigkeitsprüfungen verhindern, dass bekannte Schwachstellen mit kritischem oder hohem Schweregrad in die Produktionsumgebung gelangen.

Die menschliche Prüfung konzentriert sich auf Architektur, Sicherheitsgrenzen und Entscheidungen auf Entwurfsebene und nicht auf die Prüfung einzelner Codezeilen. Bei strukturellen, sicherheitsrelevanten oder die Infrastruktur betreffenden Änderungen ist zusätzlich zur automatisierten Validierung eine ausdrückliche menschliche Freigabe erforderlich.

Alle Validierungsebenen werden in CI als erforderliche Merge-Sperren für Änderungen an Anwendungen und Infrastruktur im Main-Branch durchgesetzt. Website-Inhalte und Veröffentlichungen statischer Assets folgen einem separaten, dokumentierten Veröffentlichungsprozess mit Prüfungen zum Zeitpunkt der Bereitstellung – einschließlich einer automatisierten Prüfung, ob die Rechtsdokumente aktuell sind – und nicht der CI-Sperre für Anwendungen. Notfallkorrekturen in der Produktionsumgebung können die CI-Sperre umgehen; anschließend müssen jedoch innerhalb von vierundzwanzig (24) Stunden ein vollständiger Pipeline-Lauf und eine Überprüfung nach dem Vorfall durchgeführt werden.

7. Backup und Notfallwiederherstellung

7.1 Automatisierte Backups. Amazon Aurora führt kontinuierliche, automatisierte Backups mit einer Aufbewahrungsfrist von sieben (7) Tagen durch. Die Backups werden mit denselben kundenseitig verwalteten KMS-Schlüsseln wie die Quelldatenbanken verschlüsselt.

7.2 Point-in-Time-Recovery. Aurora unterstützt die Wiederherstellung zu einem beliebigen Zeitpunkt innerhalb des Backup-Aufbewahrungszeitraums und ermöglicht so eine schnelle Wiederherstellung im Falle einer Datenbeschädigung oder versehentlichen Löschung.

7.3 S3-Dauerhaftigkeit und Versionierung. Datei-Uploads und Betriebsartefakte werden in Amazon S3 gespeichert, das eine Dauerhaftigkeit von 99,999999999 % (11 Neunen) bietet. Für den Upload-Bucket und die Ressourcen-Buckets ist die Versionierung aktiviert, um Wiederherstellungen und Rollbacks zu unterstützen. Website- und Frontend-Bereitstellungs-Buckets enthalten reproduzierbare Build-Artefakte und werden nicht als Backup-System behandelt. ProcessMind aktiviert derzeit keine regionsübergreifende S3-Replikation.

7.4 Geschäftskontinuität. Verfahren zur Notfallwiederherstellung sind dokumentiert und werden regelmäßig getestet. Eine Zusammenfassung ist im Dokument Notfallwiederherstellung, Geschäftskontinuität und Reaktion auf Vorfälle verfügbar. Die Architektur stützt sich auf von AWS verwaltete Dienste innerhalb der eu-central-1-Region, die AWS über mehrere Availability Zones hinweg betreibt; der Aurora-Cluster verwendet derzeit eine einzelne Writer-Instanz. Daher stützt sich die Datenbankwiederherstellung auf automatisierte Sicherungen und eine Wiederherstellung zu einem bestimmten Zeitpunkt statt auf eine Standby-Instanz innerhalb der Region. Aurora-Sicherungen, die Beständigkeit von S3, Dead-Letter-Queues und statische Assets, die aus der Quelle neu erstellt werden können, sind Teil der Wiederherstellungsstrategie.

8. Reaktion auf Sicherheitsvorfälle

8.1 Benachrichtigung über Sicherheitsvorfälle. Im Falle eines Sicherheitsvorfalls (wie im DPA definiert) benachrichtigt ProcessMind betroffene Kunden unverzüglich und, soweit möglich, innerhalb von zweiundsiebzig (72) Stunden, nachdem ProcessMind Kenntnis von dem Vorfall erlangt hat.

8.2 Umgang mit Vorfällen. ProcessMind unterhält dokumentierte Verfahren zur Reaktion auf Vorfälle, die Identifizierung, Eindämmung, Beseitigung, Wiederherstellung und Überprüfung nach einem Vorfall abdecken. Eine Zusammenfassung ist im Dokument Notfallwiederherstellung, Geschäftskontinuität und Reaktion auf Vorfälle verfügbar. Aus Vorfällen gewonnene Erkenntnisse fließen in Sicherheitskontrollen und -prozesse ein.

8.3 Kommunikation. Benachrichtigungen über Sicherheitsvorfälle enthalten Angaben zu Art und Umfang des Vorfalls, den betroffenen Datenkategorien, den zur Eindämmung des Vorfalls ergriffenen Maßnahmen und den dem Kunden empfohlenen Maßnahmen.

9. Organisatorische Maßnahmen

9.1 Informationssicherheitsmanagement. ProcessMind unterhält ein Informationssicherheitsmanagementsystem, das an den Grundsätzen der ISO 27001 ausgerichtet ist. ProcessMind hat den Zertifizierungspfad für die Zertifizierung nach ISO 27001 und die SOC-2-Type-II-Bescheinigung ausgewählt; das formelle Zertifizierungsverfahren hat noch nicht begonnen.

9.2 Sicherheitsbewusstsein. Alle Personen mit Zugriff auf Kundendaten erhalten eine Schulung zum Sicherheitsbewusstsein. Bewährte Sicherheitspraktiken sind in die Einarbeitung, Entwicklungsabläufe und Betriebsverfahren eingebettet.

9.3 Verwaltung von Anbietern und Unterauftragsverarbeitern. Unterauftragsverarbeiter sind vertraglich an Datenschutzstandards gebunden, die den in diesem Dokument beschriebenen Standards gleichwertig sind. ProcessMind führt eine öffentliche Liste der Unterauftragsverarbeiter und kündigt die Beauftragung eines neuen Unterauftragsverarbeiters mindestens dreißig (30) Tage im Voraus an. Unterauftragsverarbeiter werden jährlich auf ihre Einhaltung der Vorschriften überprüft.

9.4 Vertraulichkeit. Alle Personen, die zur Verarbeitung von Kundendaten befugt sind, sind durch schriftliche Vertraulichkeitsverpflichtungen gebunden.

10. Compliance und Zertifizierungen

Rahmenwerk / Standard Status
DSGVO (Datenschutz-Grundverordnung der EU) Eingehalten
Datenresidenz in der EU (Frankfurt, Deutschland) Durchgesetzt
AWS-Infrastrukturzertifizierungen (ISO 27001, SOC 2, PCI DSS) Über AWS übernommen
ISO 27001 (ProcessMind) Geplant — Zertifizierungspfad ausgewählt; formeller Prozess noch nicht begonnen
SOC 2 Type II (ProcessMind) Geplant — Zertifizierungspfad ausgewählt; formeller Prozess noch nicht begonnen
Automatisierte Validierung von Infrastrukturkontrollen (cdk-nag über AWS Solutions, HIPAA Security, NIST 800-53 R4/R5, PCI DSS 3.2.1, Serverless) Als Validierung technischer Kontrollen implementiert, keine Zertifizierung
Standardvertragsklauseln (SCCs) für internationale Übermittlungen Implementiert (siehe DPA)
Nachtrag zur Auftragsverarbeitung (DPA) Öffentlich verfügbar

Die Verwendung von cdk-nag Regelpaketen bedeutet nicht, dass ProcessMind formell zertifiziert oder unabhängig auf die Einhaltung von HIPAA, NIST oder PCI DSS geprüft wurde. Diese Regelpakete dienen als technische Leitplanken zur Validierung des Infrastrukturentwurfs und zur ausdrücklichen Erfassung von Lücken.

Bei Fragen zu Sicherheit oder Compliance oder zur Anforderung von Unterlagen wie Prüfberichten oder ausgefüllten Sicherheitsfragebögen wenden Sie sich an support@processmind.com.