Incident- & Breach-Prozess
Sicherheitsvorfälle und DSGVO-Meldekette
1. Normativer Rahmen
Diese Seite dient als technische Dokumentation zur Compliance-Transparenz und ist nicht Teil der Vertragsdokumente. Sie enthält keine eigenständige Leistungszusage und keine Garantie (maßgeblich: AGB und einbezogene Vertragsdokumente).
Bei Widersprüchen zwischen dieser Seite und den Vertragsdokumenten gehen die Vertragsdokumente vor.
Der Incident- und Breach-Prozess richtet sich an Art. 32 DSGVO (Sicherheit der Verarbeitung), Art. 33 DSGVO (Meldung von Verletzungen an die Aufsichtsbehörde) und Art. 34 DSGVO (Benachrichtigung der betroffenen Personen).
Er gilt für alle Sicherheitsereignisse, die die Vertraulichkeit, Integrität oder Verfügbarkeit personenbezogener Daten innerhalb der prokodo Marketplace-Plattform beeinträchtigen oder beeinträchtigen könnten.
Dieser Abschnitt stellt einen technischen Compliance-Rahmen dar. Interner Validierungshinweis (ohne vertragliche Zusage): Abgleich mit der unternehmensweiten Incident-Response-Policy und ggf. sektorspezifischen Anforderungen erfolgt intern.
Stand: 16. Februar 2026. Änderungen vorbehalten.
2. Geltungsbereich und Definitionen
Folgende Begriffe werden in diesem Prozess verwendet:
- Sicherheitsvorfall (Incident): Jedes Ereignis, das die Sicherheit informationstechnischer Systeme oder personenbezogener Daten potenziell beeinträchtigt — einschließlich unbefugter Zugriffe, Datenverluste, Verfügbarkeitsstörungen und Konfigurationsfehler
- Datenschutzverletzung (Breach): Ein Sicherheitsvorfall, der zu einer Verletzung des Schutzes personenbezogener Daten führt (Art. 4 Nr. 12 DSGVO) — Vernichtung, Verlust, Veränderung, unbefugte Offenlegung oder unbefugter Zugang
- CIA-Auswirkung: Bewertung der betroffenen Schutzziele — Vertraulichkeit (Confidentiality), Integrität (Integrity), Verfügbarkeit (Availability)
- Schweregrad: Einstufung nach Auswirkung auf betroffene Personen und Systeme. Interner Validierungshinweis (ohne vertragliche Zusage): Formale Schweregrad-Klassifizierung (z. B. P1/P2/P3/P4) wird intern definiert und dokumentiert.
3. Verfahrensphasen (Mandatory Lifecycle)
Jeder Sicherheitsvorfall ist nach den folgenden Pflichtphasen zu behandeln. Das Überspringen einer Phase ist nur mit dokumentierter Begründung und Freigabe durch die 2nd Line zulässig.
- Phase 1 — Detection & Triage: Ersterfassung, Klassifikation (Incident vs. Breach), Scope-Ermittlung, betroffene Datenkategorien und Systeme, initiale Risikoeinschätzung. Infrastrukturseitig stehen Monitoring-Alerts bereit (Typesense: Uptime, CPU, Memory, Disk; Verification: Stuck Detection, Queue Backlog, Failure Ratio, Worker Silent; Cloud Monitoring Dashboard)
- Phase 2 — Containment: Technische Sofortmaßnahmen zur Risikobegrenzung (z. B. Zugriffsentzug, Service-Isolation, Credential-Rotation). Dokumentation der ergriffenen Maßnahmen und deren Wirksamkeit
- Phase 3 — Forensik: Sicherung und integritätsbewahrende Aufbereitung relevanter Nachweise (Protokolle, Konfigurationsstände, Audit-Events). Kein Löschen oder Verändern potenziell beweisrelevanter Daten. VPC Flow Logs und Cloud Logging sind als Forensik-Quellen vorgesehen
- Phase 4 — Legal Assessment: Rechtliche Bewertung der Meldepflicht gegenüber Aufsichtsbehörde (Art. 33) und betroffenen Personen (Art. 34). Entscheidung wird dokumentiert, einschließlich Nicht-Meldepflicht-Entscheidungen. Keine externe Kommunikation ohne rechtliche Freigabe
- Phase 5 — Recovery & Closure: Wiederherstellung des regulären Betriebs. Korrekturmaßnahmen (Ursachenbeseitigung) und Präventionsmaßnahmen (Wiederholungsvermeidung). Abschlussbericht mit Maßnahmenplan, Ownern und Fristen. Wirksamkeitsprüfung der Maßnahmen
4. Fristen, Meldepfade und Eskalation
Regulatorische Fristen sind, soweit im konkreten Fall rechtlich einschlägig, zu beachten. Interne Fristen dienen als Prozessrahmen und können je Vorfalllage angepasst werden, solange die rechtlichen Pflichten gewahrt bleiben.
- Interne Ersterfassung: zeitnah nach Bekanntwerden des Vorfalls (prozessualer Richtwert)
- Interne Eskalation: zeitnah an die verantwortliche Sicherheits- und Datenschutzrolle. Interner Validierungshinweis (ohne vertragliche Zusage): Eskalationskanäle und Bereitschaftsabdeckung (z. B. On-Call-Rotation, Eskalationsverteiler) werden intern bestätigt.
- Rechtliche Erstbewertung: zeitnah nach Triage-Abschluss (prozessualer Richtwert)
- Art. 33 DSGVO — Aufsichtsbehördenmeldung: bei meldepflichtiger Verletzung grundsätzlich binnen 72 Stunden nach Bekanntwerden; Nachmeldung ist zulässig, wenn Details nachträglich verfügbar werden
- Art. 34 DSGVO — Betroffeneninformation: bei hohem Risiko grundsätzlich ohne unangemessene Verzögerung
- Entscheidungsprotokoll (Decision Log): Jede Entscheidung zur Meldung/Nicht-Meldung ist mit Begründung, Verantwortlichem und Zeitstempel zu dokumentieren
- Abschlussbericht: Zielwert 14 Tage nach Vorfallabschluss; je nach Komplexität sind abweichende Zeitfenster möglich. Interner Validierungshinweis (ohne vertragliche Zusage): finale Fristvorgaben werden intern bestätigt.
5. Evidenz- und Dokumentationspflichten
Jeder Vorfall ist vollständig zu dokumentieren. Die Dokumentation dient als Compliance-Nachweis und als Grundlage für Verbesserungsmaßnahmen.
- Eindeutige Incident-ID und vollständige Zeitleiste (Erkennung, Triage, Containment, Forensik, Assessment, Recovery, Closure)
- Betroffene Systeme und Datendomänen (z. B. Nutzerprofile, Zahlungsdaten, Audit-Protokolle)
- Betroffene Datenkategorien und geschätzte Anzahl betroffener Personen (soweit ermittelbar)
- Entscheidungsprotokoll: Meldepflicht, Nicht-Meldepflicht oder Nachmeldung — jeweils mit Begründung
- Maßnahmenliste mit Wirksamkeitsprüfung und Verantwortlichem
- Verweis auf gesicherte Audit-Evidenzen (Audit-Events, Cloud Logging, VPC Flow Logs)
- Aufbewahrungsfrist der Incident-Dokumentation. Interner Validierungshinweis (ohne vertragliche Zusage): Mindestaufbewahrungsfrist für Incident-Akten wird intern definiert.
6. Verbindung zu Legal Hold, Löschung und Retention
Soweit ein Incident Löschverfahren beeinflusst (z. B. Legal Hold während einer Untersuchung), gelten folgende Regeln:
- Legal-Hold-Blockgründe im Erasure-Workflow: LEGAL_HOLD, OPEN_DISPUTE, FRAUD_REVIEW. Jeder Blockgrund muss auditierbar erfasst werden mit: Grund, Verantwortlicher, Zeitstempel, Begründungscodes
- In blockiertem Zustand dürfen nur rechtlich erforderliche Mindestdaten aufbewahrt werden; keine diskretionäre Profilanreicherung
- Retention-basierte Systeme (Backups, Log-Streams, Monitoring-Telemetrie): Löschung erfolgt nicht als Einzelobjektdelete, sondern über dokumentierte Ablauf- und Rotationsregeln
- Firestore-Backups: 14 Wochen Retention (konfiguriert). Cloud Logging und Fehlertelemetrie: gemäß Provider-/Senkeneinstellung
- Incident-bedingte Aufbewahrungsverlängerungen sind separat zu dokumentieren und nach Abschluss der Untersuchung aufzuheben
7. Kommunikationsregeln
Für die interne und externe Kommunikation bei Sicherheitsvorfällen gelten folgende Grundregeln; ergänzende Verantwortlichkeiten ergeben sich aus DPA / SCC / TIA und der Subprozessoren-Dokumentation.
- Keine Nutzer- oder Kundenkommunikation vor rechtlicher Freigabe (Phase 4 — Legal Assessment)
- Interne Kommunikation auf Need-to-know-Basis; keine Verbreitung über nicht gesicherte Kanäle
- Vorlagen für Aufsichtsbehördenmeldung und Betroffeneninformation sind vorzubereiten. Interner Validierungshinweis (ohne vertragliche Zusage): Meldungsvorlagen werden intern erstellt und gepflegt.
- Presseanfragen oder öffentliche Kommunikation nur über autorisierte Stellen
- Bei Subprozessor-Involvement: koordinierte Kommunikation mit dem betroffenen Verarbeiter gemäß DPA-Incident-Klauseln
