nexarch/docs/INCIDENT-RESPONSE-PLAN.md

NEXARCH Incident-Response-Plan (inkl. DSGVO-Meldefristen)

Kachel: Core OPS-04 | Stand: 2026-08-28 | Geltungsbereich: NEXARCH Core und alle Fachmodule (DMS, Mail, Archive, Workflow, AI, Connect)

Dieses Dokument ist eine auszufüllende Vorlage. Felder in eckigen Klammern ([AUSZUFÜLLEN: ...]) müssen vom jeweiligen Betreiber (SaaS-Anbieter oder On-Premise-Kunde, siehe SAAS-BETRIEBSMODELL.md) mit echten Namen, Telefonnummern und E-Mail-Adressen befüllt werden, bevor der Plan betrieblich wirksam ist. Ohne befüllte Kontaktliste (Abschnitt 7) ist dieser Plan nicht einsatzbereit — siehe Prüfung 3.

1. Zweck

Ablaufplan für Sicherheitsvorfälle (Datenleck, kompromittiertes Service-Credential, kompromittierter Core-Signaturschlüssel, unbefugter Zugriff, Ransomware, Ausfall mit Datenverlust): Erkennung, Klassifizierung, Eskalation, Sofortmaßnahmen, DSGVO-Meldefristen, Kommunikation, Nachbereitung. Ergänzt SICHERHEITSKONZEPT.md (dort: präventive Architekturentscheidungen) um den reaktiven Ablauf im Ernstfall.

2. Erkennung — technische Quellen

Ein Vorfall wird über eine oder mehrere dieser Quellen bemerkt:

Quelle	Was sie zeigt	Code-Anknüpfung
Zentrale Statusseite	Ausfall/Fehlverhalten eines Moduls	Core OPS-02
Metrics-Aggregation	Anomale Kennzahlen (z.B. Anstieg von 401/403, ungewöhnliche Zugriffszahlen)	Core OPS-03
Health-/Readiness-Endpunkte	Abhängigkeitsausfall (DB, Queue)	Core OPS-01 (internal/health)
Audit-Log	Wer hat wann was getan — die primäre forensische Quelle für JEDEN Vorfall mit Personenbezug oder Rechteänderung	Core AUD-01 (internal/audit/audit.go, Log.Record), Export/Filter über AUD-03 (internal/audit/export.go, StreamCSV/StreamJSON nach Zeitraum/Akteur/Aktion/Tenant)
Aufbewahrungs-/Löschprotokoll	Ungewöhnliche oder unautorisierte Löschvorgänge	Archive RET-03/CMP-06 (geplant, noch nicht gebaut)
Meldung durch Dritte	Kunde, Mitarbeiter, externer Sicherheitsforscher meldet einen Verdacht	—

Das Audit-Log (AUD-01) ist laut SICHERHEITSKONZEPT.md append-only (AUD-02, DB-Trigger-Schutz gegen UPDATE/DELETE) — es ist damit die vertrauenswürdigste Quelle für die Rekonstruktion eines Vorfalls, weil ein Angreifer es nicht nachträglich manipulieren kann.

3. Klassifizierung

Schweregrad	Beispiel	Meldepflichtig nach Art. 33 DSGVO?
Kritisch	Personenbezogene Daten mehrerer Mandanten abgeflossen; Master-Key (API-10) kompromittiert	Ja, mit hoher Wahrscheinlichkeit
Hoch	Ein Mandant betroffen, personenbezogene Daten eingesehen/exfiltriert	Ja, sofern Risiko für Betroffene nicht auszuschließen ist
Mittel	Kompromittiertes Service-Credential (API-02) ohne nachweisbaren Datenzugriff	Einzelfallprüfung durch Datenschutzbeauftragten
Niedrig	Fehlkonfiguration ohne Datenzugriff, rechtzeitig erkannt	Nein, aber intern dokumentieren

Die Einstufung "meldepflichtig" ist IMMER eine rechtliche Bewertung durch den Datenschutzbeauftragten (Rolle, siehe Abschnitt 7) — diese Tabelle ist eine Ersteinschätzungshilfe für die technische Eskalation, kein Ersatz für die rechtliche Prüfung.

4. Eskalationskette (Rollen)

Rolle	Verantwortlich für	Wird informiert
Incident Commander	Koordiniert die gesamte Reaktion, trifft operative Entscheidungen	Sofort bei Erkennung (Schweregrad Mittel/Hoch/Kritisch)
Technischer Verantwortlicher	Eindämmung, Beweissicherung (Audit-Log-Export), technische Ursachenanalyse	Sofort bei Erkennung
Datenschutzbeauftragter (DSB)	Rechtliche Einstufung, DSGVO-Meldung an Aufsichtsbehörde, Betroffenen-Benachrichtigung (Art. 34)	Innerhalb 1 Stunde ab Schweregrad Mittel
Geschäftsführung/Betreiber	Externe Kommunikation, Kundenbenachrichtigung, AVV-Pflichten (siehe SAAS-BETRIEBSMODELL.md)	Innerhalb 4 Stunden ab Schweregrad Hoch/Kritisch

Jede dieser Rollen benötigt Stellvertretung (Urlaub/Krankheit) — siehe Kontaktliste Abschnitt 7.

5. Sofortmaßnahmen (Eindämmung)

1. Betroffene Zugänge/Credentials sperren (Service-Credential-Widerruf, API-02; Session-Widerruf, IAM-12; bei kompromittiertem Core-Signaturschlüssel: sofortige Schlüsselrotation ohne Ausfallzeit, API-05/API-09/API-10 — alle drei unterstützen rotationsfähige Schlüssel/Zertifikate ohne Downtime).
2. Beweissicherung: Audit-Log-Export für den betroffenen Zeitraum/Tenant/ Akteur vor jeder Aufräumaktion (internal/audit.Log.StreamCSV/ StreamJSON, AUD-03) — unveränderlich, daher jederzeit nachträglich exportierbar.
3. Betroffenen Mandanten identifizieren (Tenant-Registry, TEN-01) — dank physischer Modell-C-Trennung ist ein Vorfall bei einem Mandanten technisch strukturell auf diesen einen begrenzt (siehe SICHERHEITSKONZEPT.md Abschnitt zu TEN-01).
4. Zeitpunkt der Kenntniserlangung dokumentieren (Startpunkt der 72-Stunden-Frist, siehe Abschnitt 6).

6. DSGVO-Meldefrist-Prozess (Art. 33/34 DSGVO)

1. Start der Frist: Zeitpunkt, an dem der Betreiber (nicht der Entdecker im technischen Team) hinreichend sichere Kenntnis vom Vorfall hat — dokumentiert vom Incident Commander.
2. Verantwortlich für die Meldung: Datenschutzbeauftragter.
3. Frist: 72 Stunden ab Kenntniserlangung, an die zuständige Aufsichtsbehörde — auch wenn die Untersuchung noch nicht abgeschlossen ist (Art. 33 Abs. 4 erlaubt eine gestaffelte Meldung).
4. Inhalt der Meldung (Art. 33 Abs. 3): Art der Verletzung, betroffene Kategorien/ungefähre Anzahl Betroffener und Datensätze, Kontakt des DSB, wahrscheinliche Folgen, ergriffene/vorgeschlagene Maßnahmen.
5. Betroffenen-Benachrichtigung (Art. 34): zusätzlich erforderlich, wenn ein VORAUSSICHTLICH HOHES Risiko für die Rechte der betroffenen Personen besteht — Entscheidung durch DSB, unverzüglich.
6. Keine Meldung nötig: nur wenn nachweislich kein Risiko für Betroffene besteht (z.B. Daten waren durch API-10-Envelope-Encryption wirksam verschlüsselt und der Schlüssel selbst nicht kompromittiert) — diese Einschätzung UND ihre Begründung wird dennoch dokumentiert (Art. 33 Abs. 5: Dokumentationspflicht besteht unabhängig von der Meldepflicht).
7. Vertragliche Ebene: bei SaaS-/Private-Cloud-Betrieb regelt der AVV (Art. 28 DSGVO) zusätzlich, in welcher (kürzeren) Frist der Auftragsverarbeiter den Verantwortlichen (Kunde) informieren muss, BEVOR die 72-Stunden-Frist gegenüber der Behörde zu laufen beginnt — siehe SAAS-BETRIEBSMODELL.md.

7. Kontaktliste (auszufüllen vom Betreiber)

Rolle	Name	Telefon	E-Mail	Stellvertretung
Incident Commander	[AUSZUFÜLLEN]	[AUSZUFÜLLEN]	[AUSZUFÜLLEN]	[AUSZUFÜLLEN]
Technischer Verantwortlicher	[AUSZUFÜLLEN]	[AUSZUFÜLLEN]	[AUSZUFÜLLEN]	[AUSZUFÜLLEN]
Datenschutzbeauftragter	[AUSZUFÜLLEN]	[AUSZUFÜLLEN]	[AUSZUFÜLLEN]	[AUSZUFÜLLEN]
Geschäftsführung/Betreiber	[AUSZUFÜLLEN]	[AUSZUFÜLLEN]	[AUSZUFÜLLEN]	[AUSZUFÜLLEN]
Zuständige Aufsichtsbehörde	[AUSZUFÜLLEN, abhängig vom Sitz des Betreibers]	—	[AUSZUFÜLLEN]	—

Zuletzt bestätigt (Erreichbarkeitstest durchgeführt am): [AUSZUFÜLLEN — noch nicht durchgeführt, siehe Prüfung 3]

8. Kommunikation

• Intern: Eskalationskette (Abschnitt 4) zuerst, keine Information nach außen vor Freigabe durch Geschäftsführung.
• Extern (Kunden): bei SaaS-/Private-Cloud-Betrieb gemäß AVV-Frist, spätestens mit/vor der Behördenmeldung.
• Extern (Betroffene): nur bei hohem Risiko, siehe Abschnitt 6.5, Text in verständlicher, nicht-technischer Sprache.
• Presse/Öffentlichkeit: ausschließlich durch Geschäftsführung.

9. Nachbereitung

1. Lessons-Learned-Sitzung mit allen beteiligten Rollen (spätestens 2 Wochen nach Abschluss).
2. Vollständige Audit-Log-Auswertung des Vorfallszeitraums archivieren (separat vom laufenden Audit-Log, als Vorfallsakte).
3. Prüfen, ob eine Schlüssel-Notfallrotation nötig ist/war (API-05 JWT- Signaturschlüssel, API-09 mTLS-Zertifikate, API-10 Master-/ Tenant-KEK) — alle drei sind so gebaut, dass Rotation ohne Ausfallzeit möglich ist.
4. Diesen Plan aktualisieren, wenn die Übung/der echte Vorfall eine Lücke aufgezeigt hat.

10. Durchgeführte Prüfungen

Prüfung 1 — Simulierte Vorfallsübung (Tabletop), durchgeführt 2026-08-28

Szenario: Ein kompromittiertes Service-Credential des DMS-Moduls wird festgestellt (ungewöhnliche Anfragemuster in der Metrics-Aggregation, OPS-03).

Durchgespielter Ablauf:

1. Erkennung: Anomalie fällt in der Metrics-Aggregation auf (Abschnitt 2) → Technischer Verantwortlicher prüft das Audit-Log für den betroffenen Zeitraum (AUD-03-Export, gefiltert nach actor = Service-Credential des DMS-Moduls).
2. Klassifizierung: Kompromittiertes Service-Credential ohne nachgewiesenen Datenzugriff → Schweregrad Mittel (Abschnitt 3).
3. Eskalation: Incident Commander + Technischer Verantwortlicher sofort, DSB innerhalb 1 Stunde (Abschnitt 4).
4. Sofortmaßnahme: Service-Credential des DMS-Moduls über API-02 widerrufen und neu provisioniert; betroffene Tenant-Verbindungen (TEN-01) identifiziert.
5. Beweissicherung: Vollständiger Audit-Log-Export für den Zeitraum vor dem Widerruf (AUD-03).
6. DSGVO-Bewertung: DSB prüft anhand des Audit-Log-Exports, ob tatsächlich personenbezogene Daten abgerufen wurden. Ergebnis im simulierten Szenario: kein nachweisbarer Datenzugriff über die normale Nutzung des Moduls hinaus → keine Meldepflicht, aber Dokumentation gemäß Art. 33 Abs. 5.
7. Nachbereitung: Ursache (wie kam das Credential abhanden) klären, Rotationsintervall für Service-Credentials als offenen Punkt vermerkt.

Ergebnis: Der Ablauf war anhand des Dokuments ohne Lücke durchspielbar — jeder Schritt hatte eine konkrete technische Anknüpfung. PASS.

Prüfung 2 — Meldefrist-Prozess auf Vollständigkeit geprüft, 2026-08-28

Abgleich von Abschnitt 6 gegen Art. 33/34 DSGVO, Punkt für Punkt:

Anforderung (Art. 33/34)	Im Plan enthalten?
Fristbeginn = Kenntniserlangung, nicht Entdeckung durch Einzelperson	Ja (6.1)
72-Stunden-Frist an Aufsichtsbehörde	Ja (6.3)
Gestaffelte Meldung erlaubt	Ja (6.3)
Pflichtinhalt der Meldung	Ja (6.4)
Betroffenen-Benachrichtigung bei hohem Risiko	Ja (6.5)
Dokumentationspflicht auch ohne Meldepflicht	Ja (6.6)
Verantwortliche Rolle benannt	Ja (6.2, DSB)
Vertragliche AVV-Frist ggü. Kunde vor Behördenfrist	Ja (6.7)

Ergebnis: vollständig. PASS.

Prüfung 3 — Kontaktliste aktuell und erreichbar bestätigt

Status: OFFEN. Abschnitt 7 enthält ausschließlich Platzhalter ([AUSZUFÜLLEN]), da dieses Projekt noch keine reale Betreiber-Organisation mit benannten Personen/Telefonnummern hat. Diese Prüfung kann nicht durch Code oder Dokumentation allein bestanden werden — sie erfordert, dass der tatsächliche Betreiber Abschnitt 7 mit echten Kontakten befüllt UND einen Erreichbarkeitstest durchführt (z.B. Testanruf/Test-E-Mail an jede Rolle). Bleibt nicht durchgeführt, bis diese Angaben vorliegen — wird hier transparent als offen dokumentiert statt fälschlich als erledigt markiert.