# 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.**