Notfallwiederherstellung, Geschäftskontinuität und Reaktion auf Sicherheitsvorfälle
Notfallwiederherstellung, Geschäftskontinuität und Reaktion auf Sicherheitsvorfälle bei ProcessMind
Gültig ab: 14. September 2026
Dieses Dokument enthält eine allgemeine Zusammenfassung der Verfahren der ProcessMind B.V. zur Notfallwiederherstellung („DR“), zur Geschäftskontinuität („BCP“) und zur Reaktion auf Sicherheitsvorfälle für ihren Cloud-Dienst. Es ergänzt die Sicherheitsmaßnahmen, die SaaS-Hosting-Richtlinie, die Service-Level-Vereinbarung und den Nachtrag zur Auftragsverarbeitung.
Es erläutert unseren derzeitigen Ansatz und begründet keine gesonderten vertraglichen Wiederherstellungszeitziele, Wiederherstellungspunktziele, Garantien zur Datenbeständigkeit, Benachrichtigungsfristen, Service-Level oder Haftungsmaßstäbe, die über die ausdrücklich in der jeweils geltenden Vereinbarung, dem DPA oder dem SLA festgelegten Bestimmungen hinausgehen.
1. Ziele und Geltungsbereich
ProcessMind unterhält diese Verfahren, um:
- die Vertraulichkeit, Integrität und Verfügbarkeit von Kundendaten während eines Störungsereignisses zu schützen
- kritische Produktionsdienstkomponenten nach Ausfällen in von ProcessMind kontrollierten Systemen wiederherzustellen
- das Vorfallmanagement, die Kundenkommunikation und die operative Entscheidungsfindung während Dienstunterbrechungen fortzuführen
- Ausfälle der Infrastruktur, Bereitstellung, Anwendung oder Datenebene mithilfe dokumentierter Verfahren und versionsverwalteter Infrastrukturdefinitionen zu beheben
- Sicherheitsvorfälle zu erkennen und zu bewerten, Bedrohungen einzudämmen, Ursachen zu beseitigen, betroffene Systeme wiederherzustellen, erforderliche Mitteilungen vorzunehmen und Erkenntnisse festzuhalten
Diese Verfahren gelten für den produktiven Cloud-Dienst von ProcessMind und für Sicherheitsereignisse, an denen Unterauftragsverarbeiter oder Cloud-Dienste beteiligt sind, soweit sie den Dienst beeinträchtigen und innerhalb der angemessenen Möglichkeiten von ProcessMind untersucht und verwaltet werden können. Entwicklungs- und Testumgebungen sind getrennt und gelten nicht als Wiederherstellungsziele für Verpflichtungen hinsichtlich der kundenorientierten Produktionsumgebung.
2. Resilienzstrategie
2.1 Regionale Architektur. Produktionsdienste werden in AWS EU (Frankfurt, Deutschland, eu-central-1) gehostet. Die Architektur stützt sich auf verwaltete AWS-Dienste innerhalb dieser Region, die AWS über mehrere Availability Zones hinweg betreibt. Der Aurora-Cluster verwendet derzeit eine einzelne Writer-Instanz. Die Datenbankwiederherstellung stützt sich daher auf automatisierte Sicherungen und Point-in-Time-Recovery statt auf eine Standby-Instanz innerhalb der Region. ProcessMind betreibt derzeit keine zweite aktive Region für Kundendaten.
2.2 Verwaltete und serverlose Dienste. ProcessMind nutzt AWS Lambda, Amazon API Gateway, Amazon CloudFront, Amazon Aurora PostgreSQL, Amazon S3, Amazon SQS, Amazon SNS und Amazon CloudWatch. Dadurch wird die Abhängigkeit von dauerhaft laufenden, vom Kunden verwalteten Servern verringert und die Wiederherstellung von Anwendungen und statischen Komponenten aus dem Quellcode unterstützt.
2.3 Trennung der Umgebungen. Produktions- und Entwicklungsumgebungen werden in getrennten AWS-Konten mit separaten Datenbanken und Infrastruktur-Stacks betrieben. Dadurch wird das Risiko verringert, dass Entwicklungsaktivitäten die Wiederherstellung der Produktionsumgebung beeinträchtigen.
2.4 Überwachung und Erkennung. CloudWatch-Alarme, Dashboards, Warnmeldungen zu Dead-Letter-Queues, zentrale Protokollierung und synthetische Dienstüberwachung unterstützen die Erkennung, Erstbewertung und Eskalation von Vorfällen. Potenzielle Vorfälle können außerdem durch Supportanfragen, Meldungen von Mitarbeitern, Benachrichtigungen von Anbietern oder andere Auslöser für Untersuchungen erkannt werden.
3. Wiederherstellungsprioritäten
Bei einem schwerwiegenden Vorfall gelten für ProcessMind im Allgemeinen folgende Wiederherstellungsprioritäten:
- Die Integrität der Kundendaten schützen und weitere Schäden verhindern.
- Den Vorfall eindämmen und betroffene Systeme stabilisieren.
- Zentrale Zugangswege zur Produktionsumgebung und kritische Workflows wiederherstellen.
- Das Dienstverhalten, die Datenintegrität und die Überwachung überprüfen, bevor die Wiederherstellung als abgeschlossen erklärt wird.
- Statusaktualisierungen, Auswirkungen auf Kunden und Folgemaßnahmen kommunizieren.
Die genaue Reihenfolge kann je nach Art des Vorfalls variieren, insbesondere danach, ob die Datenintegrität, der Kundenzugang, die asynchrone Verarbeitung oder die unterstützende Infrastruktur betroffen ist.
4. Verfahren zur Notfallwiederherstellung
4.1 Erklärung und Koordination von Vorfällen. Wesentliche Dienstunterbrechungen und Sicherheitsvorfälle werden im Rahmen der Verfahren zur Reaktion auf Vorfälle einer Erstbewertung unterzogen. ProcessMind benennt eine für den Vorfall verantwortliche Person, beschränkt die Beteiligung an der Reaktion auf autorisiertes Personal, bewertet Schweregrad und Umfang, koordiniert die technischen Einsatzkräfte und verfolgt die Wiederherstellungsmaßnahmen, bis der Vorfall behoben oder herabgestuft ist.
4.2 Eindämmung. ProcessMind unternimmt wirtschaftlich angemessene Anstrengungen, um die laufenden Auswirkungen zu stoppen oder zu verringern, bevor mit einer umfassenderen Wiederherstellung begonnen wird. Je nach Art des Ausfalls können zu den Eindämmungsmaßnahmen gehören: das Zurücksetzen kürzlich vorgenommener Änderungen, das Deaktivieren betroffener Zugangswege, das Isolieren fehlerhafter Komponenten, das Anhalten der Hintergrundverarbeitung während Integritätsprüfungen, der Widerruf oder die Rotation von Zugangsdaten oder das Blockieren missbräuchlicher Aktivitäten.
4.3 Beseitigung der Ursache. Nachdem die unmittelbaren Auswirkungen stabilisiert wurden, arbeitet ProcessMind daran, die Ursache oder den beitragenden Umstand zu beseitigen. Dies kann die Anwendung von Code- oder Konfigurationskorrekturen, die Entfernung schädlicher Artefakte, die Rotation von Geheimnissen, die Wiederherstellung einer vertrauenswürdigen Konfiguration oder das Schließen offengelegter Zugangswege umfassen.
4.4 Datenbankwiederherstellung. Aurora PostgreSQL erstellt fortlaufend automatisierte Sicherungen mit einer Aufbewahrungsfrist von sieben (7) Tagen und unterstützt Point-in-Time-Recovery. Wenn ein Fehler auf Datenbankebene, ein Beschädigungsereignis oder eine versehentliche destruktive Änderung eine Wiederherstellung erforderlich macht, kann ProcessMind aus der letzten geeigneten Sicherung oder zu einem ausgewählten Zeitpunkt wiederherstellen, die wiederhergestellte Umgebung überprüfen und den Anwendungsverkehr wieder auf den wiederhergestellten Datenbankpfad leiten.
4.5 Wiederherstellung von Objekten und Artefakten. Von Kunden hochgeladene Dateien und betriebliche Artefakte werden in Amazon S3 gespeichert. Für den Upload-Bucket und die Ressourcen-Buckets ist die Versionierung aktiviert, um die Wiederherstellung nach versehentlichem Löschen oder Überschreiben zu unterstützen. Website- und Frontend-Bereitstellungs-Buckets werden als reproduzierbare Artefakte behandelt und können aus dem Quellcode neu erstellt werden, statt aus Sicherungen wiederhergestellt zu werden.
4.6 Wiederherstellung asynchroner Workloads. Bei asynchronen Verarbeitungspfaden werden Dead-Letter-Queues verwendet, um fehlgeschlagene Ereignisse zur Untersuchung aufzubewahren. Die Wiederherstellung kann das erneute Versenden fehlgeschlagener Nachrichten, die erneute Ausführung der Verarbeitungslogik oder die erneute Verarbeitung von Aufgaben umfassen, sofern der zugrunde liegende Workflow eine sichere Wiederverarbeitung unterstützt.
4.7 Neuaufbau von Anwendungen und Infrastruktur. Die Infrastruktur wird mithilfe versionsverwalteter Infrastructure-as-Code-Definitionen verwaltet. Wenn die Anwendungsinfrastruktur oder statische Ressourcen neu erstellt werden müssen, kann ProcessMind betroffene Komponenten anhand versionsverwalteter Definitionen und Build-Artefakte neu erstellen und bereitstellen.
4.8 Überprüfung vor der Wiederaufnahme des Dienstes. Vor dem Abschluss eines Vorfalls überprüft ProcessMind den Zustand des Dienstes anhand verfügbarer Überwachungsdaten, Protokolle, synthetischer Prüfungen und gezielter Funktionsprüfungen und stellt betroffene Funktionen mithilfe validierter Bereitstellungs-, Wiederherstellungs- und Infrastrukturverfahren wieder her. Wenn der Vorfall eine Datenwiederherstellung oder ein Risiko für die Datenintegrität betraf, kann eine zusätzliche Prüfung erfolgen.
5. Maßnahmen zur Geschäftskontinuität
5.1 Betriebskontinuität. ProcessMind unterhält dokumentierte Betriebsverfahren, damit das Vorfallmanagement, die Annahme von Supportanfragen, die Reaktion der Entwicklungsteams und die Entscheidungsfindung auch während Störungsereignissen fortgeführt werden können.
5.2 Kommunikation. Bei wesentlichen Vorfällen in der Produktionsumgebung unternimmt ProcessMind wirtschaftlich angemessene Anstrengungen, um über Supportkanäle für Kunden und gegebenenfalls über die öffentliche Statusseite unter processmind.com/status Aktualisierungen bereitzustellen.
5.3 Kontrolliertes Änderungsmanagement. Ein Softwareentwicklungslebenszyklus mit mehrschichtiger Verteidigung, mehreren unabhängigen automatisierten Validierungsebenen, kontrollierten Bereitstellungen, zentraler Überwachung und Überprüfungen nach Vorfällen wird eingesetzt, um vermeidbare Ausfälle zu verringern und die Kontinuität im Laufe der Zeit zu verbessern.
5.4 Sicherheit während der Wiederherstellung. Wiederherstellungsmaßnahmen werden unter Beachtung derselben allgemeinen Sicherheitsgrundsätze durchgeführt, die auch im Normalbetrieb gelten, einschließlich des Zugriffs nach dem Prinzip der geringsten Berechtigung, der Protokollierung betrieblicher Aktivitäten, soweit verfügbar, und des kontrollierten Zugriffs auf Produktionssysteme und -daten.
6. Zusammenfassung zu Backups und Datenschutz
6.1 Datenbank-Backups. Automatisierte Aurora-Backups sind verschlüsselt und werden sieben (7) Tage lang aufbewahrt; innerhalb dieses Aufbewahrungszeitraums ist eine Wiederherstellung zu einem bestimmten Zeitpunkt möglich.
6.2 S3-Schutzmaßnahmen. Amazon S3 bietet eine hohe Beständigkeit für gespeicherte Objekte. Veränderliche Buckets mit Kundendaten stützen sich auf die Beständigkeit und Versionierung innerhalb der primären Region. ProcessMind aktiviert derzeit keine regionsübergreifende S3-Replikation für diese Buckets.
6.3 Protokolle und Diagnosen. Zentralisierte Protokolle, Alarme und Telemetriedaten unterstützen die Untersuchung von Ausfällen und die Validierung der Wiederherstellung. Diese Mechanismen unterstützen den Kontinuitätsbetrieb, werden jedoch nicht als eigenständiges Backup-Produkt dargestellt.
7. Identifizierung und Ersteinschätzung von Vorfällen
7.1 Ersteinschätzung. Gemeldete Ereignisse werden einer Ersteinschätzung unterzogen, um festzustellen, ob sie der Definition eines Sicherheitsvorfalls entsprechen, welche Systeme oder Daten betroffen sein könnten, welchen wahrscheinlichen Umfang und Schweregrad der Vorfall hat und ob eine sofortige Eindämmung erforderlich ist. Beweise werden in einer der Art des Vorfalls und den betroffenen Systemen angemessenen Weise gesichert.
7.2 Bereitschaftsdienst und Eskalation. ProcessMind unterhält einen Bereitschaftsdienst für Produktionsvorfälle, einschließlich einer 24/7-Abdeckung für kritische Vorfälle (wie in der Service Level Agreement definiert), damit Vorfälle jederzeit bestätigt und einer Ersteinschätzung unterzogen werden können.
7.3 Dokumentation. ProcessMind dokumentiert wesentliche Untersuchungsergebnisse, Reaktionsmaßnahmen und Wiederherstellungsentscheidungen, damit der zeitliche Ablauf des Vorfalls und die daraus resultierenden Korrekturmaßnahmen im Nachhinein überprüft werden können.
8. Kommunikation und Benachrichtigung
8.1 Interne Kommunikation. ProcessMind koordiniert die Einsatzkräfte, Entscheidungsträger und Supportkanäle, damit die technische Reaktion und die Kundenkommunikation während des gesamten Lebenszyklus des Vorfalls aufeinander abgestimmt bleiben.
8.2 Benachrichtigung von Kunden. Im Falle eines Sicherheitsvorfalls, der eine Benachrichtigung gemäß dem DPA oder geltendem Recht erfordert, benachrichtigt ProcessMind die betroffenen Kunden unverzüglich und, soweit möglich, innerhalb von zweiundsiebzig (72) Stunden, nachdem ProcessMind Kenntnis von dem Vorfall erlangt hat. Benachrichtigungen enthalten in der Regel die Art und den Umfang des Vorfalls, sofern bekannt die betroffenen Datenkategorien, die zur Eindämmung und Behebung des Vorfalls ergriffenen Maßnahmen sowie gegebenenfalls empfohlene Maßnahmen für Kunden.
8.3 Laufende Aktualisierungen. Dauert der Vorfall an oder ändern sich wesentliche Tatsachen, stellt ProcessMind weitere Aktualisierungen bereit, sobald zusätzliche verifizierte Informationen verfügbar sind. Bei umfassenderen Störungen des Produktionsdienstes kann ProcessMind außerdem Kundensupportkanäle und gegebenenfalls die öffentliche Statusseite unter processmind.com/status nutzen.
9. Tests, Überprüfung und Wartung
ProcessMind überprüft diese Verfahren mindestens jährlich sowie nach wesentlichen Vorfällen oder erheblichen Architekturänderungen, erprobt regelmäßig relevante Elemente des Reaktions- und Wiederherstellungsansatzes (wie die Wiederherstellung von Backups, den Neuaufbau der Bereitstellung, Überwachung, Alarmierung und die Kommunikation bei Vorfällen) und berücksichtigt gewonnene Erkenntnisse in seinen Sicherheits-, Zuverlässigkeits- und Kontinuitätsverfahren.
10. Einschränkungen und vertragliche Grenzen
Dieses Dokument ist eine Zusammenfassung auf hoher Ebene und beschreibt nicht jedes interne Runbook, jeden Eskalationsweg, jede Untersuchungsmethode oder jeden Schritt der Beweismittelhandhabung im operativen Detail. Es verpflichtet ProcessMind weder zu einem separaten regionsübergreifenden Failover-Design noch zur unveränderlichen Speicherung aller veränderlichen Buckets oder zu unabhängigen RTO-/RPO-Garantien, die über die im anwendbaren Vertrag oder Auftrag ausdrücklich festgelegten hinausgehen.
Im Falle eines Widerspruchs zwischen diesem Dokument und dem anwendbaren Kundenvertrag, dem Auftragsverarbeitungszusatz, der Service Level Agreement oder zwingendem Recht sind diese maßgeblich.