Data Breach
Datenpanne
Structured response for confirmed or suspected data breaches — from early detection and containment through scope assessment, evidence preservation, GDPR-oriented notification and post-incident review.
Strukturiertes Reaktions-Playbook für bestätigte oder vermutete Datenpannen — von früher Erkennung und Eindämmung über Umfangsermittlung und Beweissicherung bis zur DSGVO-orientierten Meldebewertung und Nachbereitung.
Detect
Contain
Assess
Notify
Recover
Review
Erkennen
Eindämmen
Bewerten
Melden
Beheben
Nachbereitung
Use this playbook when one or more of the following are present:
- Sensitive data was accessed by an unauthorized party.
- Personal data may have been exposed, copied, lost, altered, or disclosed.
- Confidential business data was sent to the wrong recipient.
- A mailbox, file share, database, cloud storage location, or collaboration platform was exposed.
- Data was published accidentally or intentionally.
- Systems containing personal, confidential, or regulated data were compromised.
- A third party reports leaked, stolen, or exposed company data.
- Ransomware actors claim to have stolen data.
- Logs indicate unusual downloads, exports, database queries, or file access.
- Backup media, laptops, mobile devices, or removable storage containing sensitive data were lost or stolen.
- Access permissions were misconfigured and exposed data to unauthorized users.
- Credentials, tokens, API keys, or secrets were exposed and may have enabled data access.
Default severity: High. Escalate to Critical if: personal, regulated, financial, health, or credential data is involved; public exposure occurred; exfiltration is confirmed or strongly suspected; privileged access was involved; legal notification deadlines apply; ransomware-related data theft is involved; or the exposure may create high risk to the rights and freedoms of natural persons.
Core response principles: Preserve volatile evidence before destructive remediation. Separate confirmed facts from hypotheses. Engage privacy and legal stakeholders early if personal data may be involved. Do not assume that lack of confirmed exfiltration means no breach occurred. Track the time the organization became aware of the possible breach. Keep a single authoritative incident timeline and decision log.
Data & Exposure Focus
- Mailbox exposure or accidental email disclosure.
- Misconfigured cloud storage and public sharing links.
- Unauthorized file share or collaboration platform access.
- Database export, query, or dump activity.
- Lost or stolen devices containing sensitive data.
- Insider theft or misuse.
- Third-party / supplier compromise.
- Credentials, tokens, or secrets enabling data access.
Roles & Responsibilities
- Incident Commander: overall coordination, timeline, decision log, escalation.
- Technical Lead: infrastructure, cloud, identity, endpoint, database response.
- Forensics / Security Analyst: evidence, logs, telemetry, access records.
- Data Owner / Business Owner: data sensitivity, affected datasets, business context.
- Privacy / DPO: privacy impact, breach status, notification requirements.
- Legal: regulatory, contractual, litigation implications.
- Communications Lead: internal and external messaging.
Verwenden Sie dieses Playbook, wenn einer oder mehrere der folgenden Punkte vorliegen:
- Sensible Daten wurden von einer unautorisierten Partei eingesehen.
- Personenbezogene Daten könnten offengelegt, kopiert, verloren, verändert oder weitergegeben worden sein.
- Vertrauliche Geschäftsdaten wurden an den falschen Empfänger gesendet.
- Eine Mailbox, Dateifreigabe, Datenbank, ein Cloud-Speicherort oder eine Kollaborationsplattform wurde exponiert.
- Daten wurden versehentlich oder absichtlich veröffentlicht.
- Systeme mit personenbezogenen, vertraulichen oder regulierten Daten wurden kompromittiert.
- Eine Drittpartei meldet geleakte, gestohlene oder offengelegte Unternehmensdaten.
- Ransomware-Akteure behaupten, Daten gestohlen zu haben.
- Logs zeigen ungewöhnliche Downloads, Exporte, Datenbankabfragen oder Dateizugriffe.
- Backup-Medien, Laptops, mobile Geräte oder Wechseldatenträger mit sensiblen Daten gingen verloren oder wurden gestohlen.
- Zugriffsrechte wurden fehlerhaft konfiguriert und haben Daten unautorisierten Benutzern zugänglich gemacht.
- Zugangsdaten, Tokens, API-Keys oder Secrets wurden offengelegt und könnten den Zugriff auf Daten ermöglicht haben.
Standard-Schweregrad: Hoch. Auf Kritisch eskalieren, wenn: personenbezogene, regulierte, Finanz-, Gesundheits- oder Zugangsdaten betroffen sind; eine öffentliche Exposition stattfand; Exfiltration bestätigt oder stark vermutet wird; privilegierter Zugriff beteiligt war; rechtliche Meldefristen gelten; ransomware-bezogener Datendiebstahl vorliegt; oder die Exposition ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen darstellen könnte.
Zentrale Reaktionsprinzipien: Volatile Beweise vor destruktiver Remediation sichern. Bestätigte Fakten von Hypothesen trennen. Datenschutz- und Rechtsstakeholder früh einbinden. Nicht annehmen, dass das Ausbleiben bestätigter Exfiltration bedeutet, dass keine Datenpanne vorliegt. Den Zeitpunkt dokumentieren, zu dem die Organisation von der möglichen Datenpanne Kenntnis erlangt hat. Eine einzige autoritative Incident-Timeline und ein Entscheidungsprotokoll führen.
Daten- & Expositionsfokus
- Mailbox-Exposition oder versehentliche E-Mail-Offenlegung.
- Fehlkonfigurierte Cloud-Speicher und öffentliche Sharing-Links.
- Unautorisierter Zugriff auf File Shares oder Kollaborationsplattformen.
- Datenbank-Exporte, Abfragen oder Dumps.
- Verlorene oder gestohlene Geräte mit sensiblen Daten.
- Insider-Diebstahl oder -Missbrauch.
- Drittanbieter- / Lieferantenkompromittierung.
- Zugangsdaten, Tokens oder Secrets als Datenzugangspfad.
Rollen & Verantwortlichkeiten
- Incident Commander: Gesamtkoordination, Timeline, Entscheidungsprotokoll.
- Technische Leitung: Infrastruktur, Cloud, Identity, Endpoint, Datenbank.
- Forensik / Security Analyst: Beweise, Logs, Telemetrie, Zugriffsrecords.
- Data Owner / Business Owner: Datensensibilität, betroffene Datasets.
- Datenschutzbeauftragter / Privacy: Datenschutzrisiken, Breach-Status, Meldepflichten.
- Legal: regulatorische, vertragliche, haftungsrechtliche Aspekte.
- Kommunikationsleitung: interne und externe Kommunikation.
▶ Act immediately
- Activate the Incident Response Lead / Incident Commander.
- Start an incident timeline and decision log.
- Record who discovered the issue and when — and when the organization became aware of the possible breach.
- Identify the affected system, dataset, mailbox, file share, database, application, cloud storage, or third-party service.
- Determine whether exposure is still active.
- Identify whether personal data, regulated data, or confidential business data may be involved.
- Preserve logs, audit trails, alerts, screenshots, permissions, and access records immediately.
- Stop ongoing unauthorized access without destroying evidence.
- Restrict access, disable public links, or revoke compromised sessions where appropriate.
- Notify privacy and legal stakeholders immediately if personal data may be involved.
- Avoid deleting files, emails, logs, or artifacts before preservation.
- Start an initial incident classification: false positive · security event · suspected breach · confirmed breach.
Do not
- Delete exposed data before documenting and preserving evidence.
- Modify affected systems unnecessarily before logs and artifacts are collected.
- Notify external parties before facts are validated and legal/privacy stakeholders are involved.
- Make unsupported statements about the number of affected individuals or records.
- Assume that the absence of confirmed exfiltration means no breach occurred.
- Delay escalation to privacy/legal teams while waiting for perfect technical certainty.
▶ Sofort handeln
- Den Incident-Response-Lead / Incident Commander aktivieren.
- Eine Incident-Timeline und ein Entscheidungsprotokoll starten.
- Dokumentieren, wer das Problem entdeckt hat und wann — sowie wann die Organisation von der möglichen Datenpanne Kenntnis erlangt hat.
- Das betroffene System, Dataset, Konto, die Mailbox, Dateifreigabe, Datenbank, Anwendung, den Cloud-Speicherort oder Drittanbieterdienst identifizieren.
- Feststellen, ob die Exposition noch aktiv ist.
- Identifizieren, ob personenbezogene Daten, regulierte Daten oder vertrauliche Geschäftsdaten betroffen sein könnten.
- Logs, Audit-Trails, Alerts, Screenshots, Berechtigungen und Zugriffsaufzeichnungen sofort sichern.
- Laufenden unautorisierten Zugriff stoppen, ohne Beweise zu zerstören.
- Zugriffe einschränken, öffentliche Links deaktivieren oder kompromittierte Sessions widerrufen, wo angemessen.
- Datenschutz- und Rechtsstakeholder sofort benachrichtigen, wenn personenbezogene Daten betroffen sein könnten.
- Dateien, E-Mails, Logs oder Artefakte nicht löschen, bevor sie gesichert wurden.
- Eine erste Incident-Klassifizierung starten: False Positive · Security Event · Vermutete Panne · Bestätigte Panne.
Nicht tun
- Exponierte Daten löschen, bevor Beweise dokumentiert und gesichert wurden.
- Betroffene Systeme unnötig verändern, bevor Logs und Artefakte gesammelt wurden.
- Externe Parteien benachrichtigen, bevor Fakten validiert und Datenschutz-/Rechtsstakeholder eingebunden sind.
- Unbelegte Aussagen zur Anzahl betroffener Personen oder Datensätze machen.
- Annehmen, dass das Ausbleiben bestätigter Exfiltration bedeutet, dass keine Datenpanne vorliegt.
- Die Eskalation an Datenschutz-/Rechts-Teams verzögern, während auf perfekte technische Gewissheit gewartet wird.
Rule 1 — Security incident or data breach? Treat as a breach candidate if any of the following are true:
■ Breach candidate if
- Personal data may have been accessed, disclosed, lost, altered, or destroyed.
- Confidential or regulated data was exposed to an unauthorized party.
- Data was sent to the wrong recipient.
- A public link or public storage exposure existed.
- Access logs show unusual downloads, exports, or queries.
- Credentials, tokens, or secrets may have enabled access to sensitive data.
▲ Rule 2 — Is exposure still ongoing?
Consider ongoing if:
- Public links are still active.
- Unauthorized accounts still have access.
- Sessions, tokens, or API keys remain valid.
- Misconfigured permissions are still in place.
- Malicious activity is still visible in logs.
Rule 3 — Enough evidence to assess scope?
▸ If evidence is insufficient
- Preserve logs and snapshots immediately before any changes.
- Avoid destructive containment until baseline evidence is collected.
- Collect system, access, and audit records before rotating or rebuilding anything.
- Identify the data owner and begin data classification now.
Rules 4 & 5 — Notification and recovery gates:
■ Rule 4 — Engage privacy/legal immediately if
- Personal data may be involved.
- Regulated or special-category data is involved.
- Credentials, financial, health, or identity data are exposed.
- The breach may create risk to rights and freedoms of natural persons.
- Legal or regulatory deadlines may apply.
■ Rule 5 — Recovery only when
- The exposure path is understood.
- Unauthorized access has been removed.
- Evidence is preserved.
- Notification assessment has been initiated.
- Monitoring and follow-up controls are in place.
Regel 1 — Security Incident oder Datenpanne? Als Datenpannen-Kandidat behandeln, wenn einer der folgenden Punkte zutrifft:
■ Datenpannen-Kandidat, wenn
- Personenbezogene Daten könnten eingesehen, offengelegt, verloren, verändert oder zerstört worden sein.
- Vertrauliche oder regulierte Daten wurden einer unautorisierten Partei zugänglich gemacht.
- Daten wurden an den falschen Empfänger gesendet.
- Ein öffentlicher Link oder eine öffentliche Speicherexposition war aktiv.
- Zugriffslogs zeigen ungewöhnliche Downloads, Exporte oder Abfragen.
- Zugangsdaten, Tokens oder Secrets könnten den Zugriff auf sensible Daten ermöglicht haben.
▲ Regel 2 — Läuft die Exposition noch?
Als weiterhin aktiv betrachten, wenn:
- Öffentliche Links noch aktiv sind.
- Unautorisierte Konten weiterhin Zugriff haben.
- Sessions, Tokens oder API-Keys noch gültig sind.
- Fehlkonfigurierte Berechtigungen weiterhin bestehen.
- Bösartige Aktivitäten in Logs weiterhin sichtbar sind.
Regel 3 — Genug Beweise für die Umfangsbewertung?
▸ Wenn Beweise unzureichend sind
- Logs und Snapshots sofort sichern, bevor Änderungen vorgenommen werden.
- Destruktive Eindämmungsmaßnahmen vermeiden, bis Basisbeweise gesichert sind.
- System-, Zugriffs- und Audit-Records sammeln, bevor etwas rotiert oder neu aufgebaut wird.
- Den Data Owner identifizieren und sofort mit der Datenklassifizierung beginnen.
Regeln 4 & 5 — Melde- und Recovery-Gates:
■ Regel 4 — Datenschutz/Recht sofort einbinden, wenn
- Personenbezogene Daten betroffen sein könnten.
- Regulierte oder besondere Kategorien personenbezogener Daten betroffen sind.
- Zugangsdaten, Finanz-, Gesundheits- oder Identitätsdaten offengelegt wurden.
- Die Panne ein Risiko für die Rechte und Freiheiten natürlicher Personen darstellen könnte.
- Rechtliche oder regulatorische Fristen gelten könnten.
■ Regel 5 — Recovery nur, wenn
- Der Expositionspfad verstanden ist.
- Unautorisierter Zugriff entfernt wurde.
- Beweise gesichert sind.
- Die Meldebewertung begonnen hat.
- Monitoring und Folgekontrollen eingerichtet sind.
Confirm breach type
Active exposure?
Initial scope
Preserve evidence
- Collect the initial report, alert, or discovery details.
- Record who discovered the issue and when the organization became aware.
- Identify the affected system, application, mailbox, database, file share, cloud service, or third-party platform.
- Identify the data owner or business owner.
- Determine whether access is still possible by unauthorized parties.
- Determine whether data was viewed, copied, downloaded, altered, deleted, published, or sent to unauthorized recipients.
- Determine whether personal data, special-category data, credentials, financial, health, or confidential business data is involved.
- Estimate the number of affected records, files, mailboxes, systems, and individuals.
- Preserve screenshots, URLs, sharing links, permissions, and exposed content metadata.
- Preserve relevant logs before rotation or deletion.
- Create an initial incident timeline and assign an initial severity and classification.
Exit criteria
- Incident type validated.
- Initial scope identified and potentially affected data flagged.
- Evidence preservation started.
- Privacy/legal stakeholders notified if personal data may be involved.
Typ bestätigen
Exposition aktiv?
Anfangs-Umfang
Beweise sichern
- Die Erstmeldung, den Alert oder die Entdeckungsdetails sammeln.
- Dokumentieren, wer das Problem entdeckt hat und wann die Organisation davon Kenntnis erlangt hat.
- Das betroffene System, die Anwendung, Mailbox, Datenbank, Dateifreigabe, Cloud-Umgebung oder Drittanbieterplattform identifizieren.
- Den Data Owner oder Business Owner identifizieren.
- Feststellen, ob unautorisierte Parteien noch Zugriff haben.
- Feststellen, ob Daten eingesehen, kopiert, heruntergeladen, verändert, gelöscht, veröffentlicht oder an unautorisierte Empfänger gesendet wurden.
- Feststellen, ob personenbezogene, besondere Kategorien, Zugangsdaten, Finanz-, Gesundheits- oder vertrauliche Geschäftsdaten betroffen sind.
- Die ungefähre Anzahl betroffener Datensätze, Dateien, Mailboxen, Systeme und Personen schätzen.
- Screenshots, URLs, Sharing-Links, Berechtigungen und Metadaten exponierter Inhalte sichern.
- Relevante Logs vor Rotation oder Löschung sichern.
- Eine erste Incident-Timeline erstellen und Schweregrad sowie Klassifizierung zuweisen.
Exit-Kriterien
- Vorfallsart validiert.
- Anfangs-Umfang identifiziert und potenziell betroffene Daten markiert.
- Beweissicherung begonnen.
- Datenschutz-/Rechtsstakeholder benachrichtigt, wenn personenbezogene Daten betroffen sein könnten.
Stop ongoing exposure
Preserve evidence
Business continuity
- Remove public access to exposed storage, files, databases, applications, or URLs.
- Disable or restrict affected accounts if compromise is suspected.
- Revoke active sessions and access tokens.
- Disable exposed API keys, access keys, or secrets.
- Remove unauthorized sharing links.
- Correct misconfigured permissions.
- Block malicious IP addresses, domains, or accounts where attacker activity is observed.
- Disable affected integrations or third-party access where needed.
- Quarantine affected endpoints if malware or credential theft is involved.
- Suspend data synchronization if it could propagate unauthorized disclosure.
- Preserve access logs, object logs, mailbox logs, database logs, and cloud audit logs.
- Preserve configuration snapshots before making changes where feasible.
- Coordinate containment with legal/privacy where evidence or notification requirements may be affected.
▸ Cloud Storage Exposure
- Disable public access immediately and remove anonymous links and external sharing.
- Capture screenshots of exposed configuration and export access/object logs.
- Identify all objects exposed during the relevant period and whether they were accessed or downloaded.
- Rotate access keys, SAS tokens, API credentials, or service account credentials if exposed.
- Validate tenant-wide external sharing policies.
▸ Compromised Mailbox
- Revoke sessions and reset credentials after session revocation.
- Review and remove suspicious mailbox rules and forwarding; review delegated access.
- Preserve mailbox audit logs; review sent, deleted, and accessed messages.
- Determine whether sensitive attachments or personal data were accessed.
- Determine whether malicious emails were sent to additional victims.
▸ Database or Application Exposure
- Disable exposed endpoint or restrict access; rotate database credentials and API secrets.
- Preserve application, database, web server, and WAF logs.
- Determine whether queries, exports, or dumps occurred.
- Identify affected tables, fields, and records; validate whether exploitation was automated or targeted.
Do not
- Delete or overwrite exposed data or configurations before evidence is preserved.
- Rotate credentials or rebuild systems in a way that destroys forensic artifacts.
- Take destructive containment steps without first notifying privacy/legal if personal data is involved.
Exit criteria
- Ongoing exposure reduced or stopped.
- Compromised accounts, links, permissions, or endpoints secured.
- Evidence preserved; legal/privacy informed where needed.
Exposition stoppen
Beweise sichern
Geschäftskontinuität
- Öffentlichen Zugriff auf exponierte Speicher, Dateien, Datenbanken, Anwendungen oder URLs entfernen.
- Betroffene Konten deaktivieren oder einschränken, wenn eine Kompromittierung vermutet wird.
- Aktive Sessions und Access Tokens widerrufen.
- Offengelegte API-Keys, Access Keys oder Secrets deaktivieren.
- Unautorisierte Sharing-Links entfernen und fehlkonfigurierte Berechtigungen korrigieren.
- Bösartige IP-Adressen, Domains oder Konten blockieren, wenn Angreiferaktivität beobachtet wird.
- Betroffene Integrationen oder Drittanbieterzugriffe bei Bedarf deaktivieren.
- Betroffene Endpunkte isolieren, wenn Malware oder Credential Theft beteiligt ist.
- Datensynchronisation aussetzen, wenn sie unautorisierte Offenlegung propagieren könnte.
- Zugriffslogs, Objekt-Logs, Mailbox-Logs, Datenbank-Logs und Cloud-Audit-Logs sichern.
- Konfigurations-Snapshots vor Änderungen sichern, wo möglich.
- Eindämmungsschritte mit Datenschutz-/Rechtsstakeholdern abstimmen, wenn Beweis- oder Meldeanforderungen betroffen sind.
▸ Exponierter Cloud-Speicher
- Öffentlichen Zugriff sofort deaktivieren, anonyme Links und externe Freigaben entfernen.
- Screenshots der exponierten Konfiguration sichern; Zugriffs- und Objektzugriffsrecords exportieren.
- Alle exponierten Objekte identifizieren und prüfen, ob sie eingesehen oder heruntergeladen wurden.
- Access Keys, SAS Tokens, API-Zugangsdaten oder Service-Account-Zugangsdaten rotieren, wenn sie offengelegt wurden.
- Tenantweite Richtlinien für externe Freigaben validieren.
▸ Kompromittierte Mailbox
- Sessions widerrufen und Zugangsdaten nach Session-Widerruf zurücksetzen.
- Verdächtige Mailbox-Regeln und Weiterleitungen prüfen und entfernen; delegierten Zugriff prüfen.
- Mailbox-Audit-Logs sichern; gesendete, gelöschte und eingesehene Nachrichten prüfen.
- Feststellen, ob sensible Anhänge oder personenbezogene Daten eingesehen wurden.
- Feststellen, ob bösartige E-Mails an weitere Opfer gesendet wurden.
▸ Datenbank- oder Anwendungs-Exposition
- Exponierten Endpunkt deaktivieren oder einschränken; Datenbank-Zugangsdaten und API-Secrets rotieren.
- Anwendungs-, Datenbank-, Webserver- und WAF-Logs sichern.
- Feststellen, ob Abfragen, Exporte oder Dumps stattgefunden haben.
- Betroffene Tabellen, Felder und Datensätze identifizieren; validieren, ob die Ausnutzung automatisiert oder gezielt erfolgte.
Nicht tun
- Exponierte Daten oder Konfigurationen löschen oder überschreiben, bevor Beweise gesichert sind.
- Zugangsdaten rotieren oder Systeme neu aufbauen, wenn dabei forensische Artefakte verloren gehen.
- Destruktive Eindämmungsmaßnahmen ergreifen, ohne vorher Datenschutz/Recht zu benachrichtigen, wenn personenbezogene Daten betroffen sind.
Exit-Kriterien
- Laufende Exposition reduziert oder gestoppt.
- Kompromittierte Konten, Links, Berechtigungen oder Endpunkte gesichert.
- Beweise gesichert; Datenschutz/Recht informiert, wo erforderlich.
What happened
Data affected
Who was affected
Notification obligations
Technical Investigation
- Review authentication and authorization logs; cloud audit logs; file, mailbox, and database access logs.
- Review application, web server, proxy, firewall, DNS, WAF, VPN, and remote access logs.
- Review endpoint telemetry, DLP alerts, and SIEM correlation events.
- Review administrative activity and third-party access records.
- Identify source IPs, user agents, accounts, access tokens, and devices involved.
- Determine whether access was authenticated or anonymous, internal or external, automated, bulk, targeted, or accidental.
- Determine whether logs are sufficient to support conclusions.
▸ Data Assessment
- Identify categories of data involved and categories of affected individuals.
- Estimate the number of affected individuals and records.
- Determine whether special-category personal data, children, or vulnerable individuals are involved.
- Determine whether credentials, financial, payment, tax, health, biometric, or identity data are involved.
- Determine whether the data was encrypted, pseudonymized, or protected by access controls.
- Determine whether the exposed data can be misused for identity theft, fraud, phishing, discrimination, or financial loss.
▸ Risk Assessment — Key Factors
- Sensitivity and volume of the affected data.
- Whether data was downloaded or only exposed; whether it is already public.
- Whether encryption or pseudonymization was effective.
- Whether credentials or secrets were exposed enabling further access.
- Whether financial fraud, identity theft, or phishing is possible.
- Whether affected individuals may suffer physical, material, or non-material harm.
- Whether regulatory, contractual, or business impact is likely.
Exit criteria
- What happened is sufficiently understood.
- Data types and affected parties identified.
- Risk level has been assessed.
- Notification decision-making can proceed.
Was ist passiert
Betroffene Daten
Betroffene Personen
Meldepflichten
Technische Untersuchung
- Authentifizierungs- und Autorisierungs-Logs, Cloud-Audit-Logs, Datei-, Mailbox- und Datenbank-Zugriffslogs prüfen.
- Anwendungs-, Webserver-, Proxy-, Firewall-, DNS-, WAF-, VPN- und Remote-Access-Logs prüfen.
- Endpoint-Telemetrie, DLP-Alerts und SIEM-Korrelationen prüfen.
- Administrative Aktivitäten und Drittanbieter-Zugriffsrecords prüfen.
- Quell-IP-Adressen, User Agents, Konten, Zugangstokens und Geräte identifizieren.
- Feststellen, ob der Zugriff authentifiziert oder anonym, intern oder extern, automatisiert, massenhaft, gezielt oder versehentlich war.
- Feststellen, ob Logs ausreichend vollständig sind, um Schlussfolgerungen zu stützen.
▸ Datenbewertung
- Kategorien der betroffenen Daten und betroffenen Personen identifizieren.
- Ungefähre Anzahl betroffener Personen und Datensätze bestimmen.
- Feststellen, ob besondere Kategorien personenbezogener Daten, Kinder oder vulnerable Personen betroffen sind.
- Feststellen, ob Zugangsdaten, Finanz-, Zahlungs-, Steuer-, Gesundheits-, biometrische oder Identitätsdaten betroffen sind.
- Feststellen, ob die Daten verschlüsselt, pseudonymisiert oder durch Zugriffskontrollen geschützt waren.
- Feststellen, ob die exponierten Daten für Identitätsdiebstahl, Betrug, Phishing, Diskriminierung oder finanziellen Verlust missbraucht werden könnten.
▸ Risikobewertung — Schlüsselfaktoren
- Sensibilität und Umfang der betroffenen Daten.
- Ob Daten heruntergeladen oder nur exponiert wurden; ob sie bereits öffentlich sind.
- Ob Verschlüsselung oder Pseudonymisierung wirksam war.
- Ob Zugangsdaten oder Secrets offengelegt wurden, die weiteren Zugriff ermöglichen.
- Ob finanzieller Betrug, Identitätsdiebstahl oder Phishing möglich ist.
- Ob betroffene Personen körperlichen, materiellen oder immateriellen Schaden erleiden könnten.
- Ob regulatorische, vertragliche oder geschäftliche Auswirkungen wahrscheinlich sind.
Exit-Kriterien
- Was passiert ist, hinreichend verstanden.
- Datenarten und betroffene Parteien identifiziert.
- Risikoniveau bewertet.
- Entscheidungsfindung zur Meldung kann erfolgen.
Legal obligations
Accurate communication
Protect affected parties
Internal Escalation
- Notify executive management if severity is High or Critical.
- Notify legal/privacy stakeholders immediately if personal data may be involved.
- Notify data owners and affected business units.
- Notify IT, security, communications, and customer support teams.
- Notify procurement/vendor management if a third party is involved.
- Notify cyber insurance contact if policy requirements apply.
- Notify law enforcement where appropriate and approved.
▶ GDPR Regulatory Assessment — 72-Hour Window
- Determine whether the incident is unlikely to result in a risk to the rights and freedoms of natural persons.
- If risk is likely, prepare notification to the competent supervisory authority.
- Track the 72-hour notification window from the point of awareness.
- If notification cannot be completed within 72 hours, document the reasons for delay — submit initial notification and provide additional information in phases.
- If the breach is likely to result in high risk to affected individuals, prepare communication to those individuals without undue delay.
- Document the reasoning for notification or non-notification.
Supervisory Authority Notification — Required Content
- Nature of the personal data breach.
- Categories and approximate number of affected individuals and records.
- Name and contact details of the DPO or relevant contact point.
- Likely consequences of the breach.
- Measures taken or proposed to address and mitigate the breach.
- Timeline of discovery, awareness, containment, and investigation.
Communication to Affected Individuals — where required, include:
- What happened and when it was discovered.
- What data may be affected and what risks may result.
- What the organization has done and what affected individuals can do to protect themselves.
- Contact information for further questions.
- Avoid speculation about attacker identity, exact scope, or impact unless confirmed.
Exit criteria
- Internal escalation completed.
- Supervisory authority notification submitted or documented as not required.
- Affected individual communication prepared or sent where applicable.
- All notification decisions and reasoning documented.
Rechtliche Pflichten
Korrekte Kommunikation
Betroffene schützen
Interne Eskalation
- Executive Management benachrichtigen, wenn der Schweregrad Hoch oder Kritisch ist.
- Datenschutz-/Rechtsstakeholder sofort benachrichtigen, wenn personenbezogene Daten betroffen sein könnten.
- Data Owner und betroffene Geschäftsbereiche benachrichtigen.
- IT, Security, Kommunikation und Customer Support benachrichtigen.
- Lieferanten-/Vendor-Management benachrichtigen, wenn eine Drittpartei beteiligt ist.
- Versicherungskontakt benachrichtigen, wenn Policen-Anforderungen dies verlangen.
- Strafverfolgung benachrichtigen, wo angemessen und genehmigt.
▶ DSGVO-Meldebewertung — 72-Stunden-Fenster
- Feststellen, ob der Vorfall wahrscheinlich kein Risiko für die Rechte und Freiheiten natürlicher Personen darstellt.
- Wenn ein Risiko wahrscheinlich ist, eine Meldung an die zuständige Aufsichtsbehörde vorbereiten.
- Die 72-Stunden-Meldefrist ab dem Zeitpunkt der Kenntnisnahme verfolgen.
- Wenn die Meldung nicht innerhalb von 72 Stunden abgeschlossen werden kann, die Gründe für die Verzögerung dokumentieren — Erstmeldung einreichen und weitere Informationen phasenweise nachreichen.
- Wenn die Panne voraussichtlich ein hohes Risiko für Betroffene darstellt, unverzüglich eine Benachrichtigung der Betroffenen vorbereiten.
- Die Gründe für Meldung oder Nichtmeldung dokumentieren.
Inhalt der Meldung an die Aufsichtsbehörde
- Art der personenbezogenen Datenpanne.
- Kategorien und ungefähre Anzahl betroffener Personen und Datensätze.
- Name und Kontaktdaten des Datenschutzbeauftragten oder relevanten Ansprechpartners.
- Wahrscheinliche Folgen der Panne.
- Getroffene oder geplante Maßnahmen zur Behebung und Minderung der Panne.
- Timeline von Entdeckung, Kenntnisnahme, Eindämmung und Untersuchung.
Kommunikation an betroffene Personen — wo erforderlich, enthalten:
- Was passiert ist und wann es entdeckt wurde.
- Welche Daten möglicherweise betroffen sind und welche Risiken entstehen könnten.
- Was die Organisation unternommen hat und was Betroffene tun können, um sich zu schützen.
- Kontaktdaten für Rückfragen.
- Spekulationen über Identität des Angreifers, exakten Umfang oder Impact vermeiden, sofern nicht bestätigt.
Exit-Kriterien
- Interne Eskalation abgeschlossen.
- Meldung an Aufsichtsbehörde eingereicht oder als nicht erforderlich dokumentiert.
- Kommunikation an Betroffene vorbereitet oder versendet, wo anwendbar.
- Alle Meldungsentscheidungen und deren Begründung dokumentiert.
Remove root cause
Restore secure operations
Prevent recurrence
Technical Remediation
- Correct access control misconfigurations.
- Remove unauthorized accounts, sessions, tokens, and permissions.
- Rotate exposed credentials, API keys, certificates, and secrets.
- Patch exploited vulnerabilities.
- Harden affected applications, databases, mailboxes, or cloud services.
- Implement or improve encryption at rest and in transit.
- Implement least privilege access.
- Disable anonymous or public access where not required.
- Enable or improve audit logging and monitoring for high-risk data access.
- Implement DLP rules where appropriate.
- Validate backup integrity; restore altered or deleted data from clean backups if needed.
- Conduct targeted security testing after remediation.
▸ Organizational Remediation
- Update data handling procedures and access review processes.
- Update supplier management controls and incident escalation procedures.
- Update data classification and ownership records.
- Provide targeted user or administrator training.
- Review approval processes for data sharing, retention, and minimization practices.
- Review contracts and processor obligations where applicable.
Recovery Validation
- Confirm unauthorized access has ended and exposed links or permissions are removed.
- Confirm credentials and secrets have been rotated.
- Confirm affected systems are monitored and relevant logs are retained.
- Confirm notification obligations have been addressed.
- Confirm affected business processes can resume safely.
- Continue enhanced monitoring for at least 14–30 days.
Ursache beseitigen
Sicheren Betrieb wiederherstellen
Wiederholung verhindern
Technische Remediation
- Fehlkonfigurationen der Zugriffskontrolle korrigieren.
- Unautorisierte Konten, Sessions, Tokens und Berechtigungen entfernen.
- Offengelegte Zugangsdaten, API-Keys, Zertifikate und Secrets rotieren.
- Ausgenutzte Schwachstellen patchen.
- Betroffene Anwendungen, Datenbanken, Mailboxen oder Cloud-Services härten.
- Verschlüsselung im Ruhezustand und während der Übertragung einführen oder verbessern.
- Least-Privilege-Zugriff implementieren.
- Anonyme oder öffentliche Zugriffe deaktivieren, wo nicht erforderlich.
- Detailliertes Audit-Logging aktivieren und Monitoring für risikoreiche Datenzugriffe verbessern.
- DLP-Regeln dort implementieren, wo sinnvoll.
- Backup-Integrität prüfen; veränderte oder gelöschte Daten aus sauberen Backups wiederherstellen, falls erforderlich.
- Nach der Remediation gezielte Sicherheitstests durchführen.
▸ Organisatorische Remediation
- Verfahren für den Umgang mit Daten und Zugriffsprüfungsprozesse aktualisieren.
- Lieferantenmanagement-Kontrollen und Incident-Eskalationsverfahren aktualisieren.
- Datenklassifizierungs- und Ownership-Records aktualisieren.
- Zielgerichtete Schulungen für Benutzer oder Administratoren durchführen.
- Freigabeprozesse für Datenteilung, Aufbewahrungs- und Minimierungspraktiken prüfen.
- Verträge und Pflichten von Auftragsverarbeitern prüfen, sofern relevant.
Validierung der Wiederherstellung
- Bestätigen, dass unautorisierter Zugriff beendet und exponierte Links oder Berechtigungen entfernt wurden.
- Bestätigen, dass Zugangsdaten und Secrets rotiert wurden.
- Bestätigen, dass betroffene Systeme überwacht werden und relevante Logs aufbewahrt werden.
- Bestätigen, dass Meldepflichten adressiert wurden.
- Bestätigen, dass betroffene Geschäftsprozesse sicher wieder aufgenommen werden können.
- Für mindestens 14 bis 30 Tage verstärktes Monitoring fortsetzen.
Root cause
Control improvements
Track remediation
- Conduct a post-incident review within 5–10 business days.
- Finalize the incident timeline and document root cause.
- Document affected data, systems, users, and third parties.
- Document all containment, remediation, and communication actions.
- Document notification decisions and reasoning.
- Review whether logs were sufficient; whether data classification and ownership were clear.
- Review whether access controls followed least privilege and whether detection occurred early enough.
- Review whether escalation to legal/privacy was timely and notification deadlines were met.
- Update policies, procedures, playbooks, and training.
- Track all remediation actions to closure with named owners and due dates.
▸ Lessons Learned Questions
- Why was the data exposed or accessed? Was the root cause technical, procedural, human, or third-party related?
- Was the data properly classified? Was it still needed, or should it have been deleted earlier?
- Were permissions excessive? Were sharing links or public access controls misused?
- Were logs sufficient to determine access and impact?
- Did monitoring detect the issue or did a third party report it?
- Was legal/privacy escalation fast enough? Were notification deadlines met?
- Which controls would have prevented or reduced the impact?
Root Cause
Kontrollen verbessern
Remediation nachverfolgen
- Innerhalb von 5 bis 10 Geschäftstagen eine Post-Incident-Review durchführen.
- Die Incident-Timeline finalisieren und die Root Cause dokumentieren.
- Betroffene Daten, Systeme, Benutzer und Drittparteien dokumentieren.
- Alle Eindämmungs-, Remediation- und Kommunikationsmaßnahmen dokumentieren.
- Meldungsentscheidungen und deren Begründung dokumentieren.
- Prüfen, ob Logs ausreichend waren und Datenklassifizierung und Ownership klar waren.
- Prüfen, ob Zugriffskontrollen dem Least-Privilege-Prinzip entsprachen und die Erkennung früh genug erfolgte.
- Prüfen, ob die Eskalation an Datenschutz/Recht rechtzeitig erfolgte und Meldefristen eingehalten wurden.
- Richtlinien, Verfahren, Playbooks und Schulungen aktualisieren.
- Alle Remediation-Maßnahmen mit namentlichen Verantwortlichen und Abschlussdaten bis zum Abschluss nachverfolgen.
▸ Lessons-Learned-Fragen
- Warum wurden die Daten exponiert oder eingesehen? War die Root Cause technisch, prozessual, menschlich oder drittanbieterbedingt?
- Waren die Daten korrekt klassifiziert? Wurden sie noch benötigt oder hätten sie früher gelöscht werden sollen?
- Waren die Berechtigungen zu weit gefasst? Wurden Sharing-Links oder öffentliche Zugriffskontrollen missbraucht?
- Waren die Logs ausreichend, um Zugriff und Impact zu bestimmen?
- Hat Monitoring das Problem entdeckt oder hat eine Drittpartei es gemeldet?
- War die Eskalation an Datenschutz/Recht rechtzeitig? Wurden Meldefristen eingehalten?
- Welche Kontrollen hätten den Impact verhindert oder reduziert?
Evidence to preserve
- Initial report or alert; incident timeline and decision log.
- Screenshots of exposed data or configuration; URLs and access paths.
- File names, object names, database names, mailbox names.
- System and application configuration snapshots.
- Authentication and authorization logs; cloud audit logs.
- File access, database audit logs, and query history.
- Mailbox audit logs; web server, WAF, firewall, proxy, VPN, DNS logs.
- DLP alerts, SIEM events, EDR alerts, API gateway logs.
- Third-party platform logs.
- Categories of affected data and approximate record count.
- Data owner confirmation and data classification.
- Evidence of encryption, pseudonymization, or access control effectiveness.
- Evidence of access, download, export, deletion, alteration, or publication.
Communications checklist
- Notify incident response team, legal/privacy, data owner, management, and affected business units.
- Notify communications/customer support teams where external contact may occur.
- Notify supplier management if a third party is involved.
- Keep internal updates factual and version-controlled; maintain a single source of truth.
- Determine whether supervisory authority notification is required.
- Determine whether affected individuals must be informed.
- Prepare all external communications through legal/privacy and communications teams.
- Preserve all outgoing communications and approvals.
Internal holding statement: "A suspected data breach is currently under investigation. The incident response, legal/privacy, and technical teams are assessing scope, affected data, and notification obligations. Please do not speculate externally or delete any potentially relevant evidence."
Zu sichernde Beweise
- Erstmeldung oder Alert; Incident-Timeline und Entscheidungsprotokoll.
- Screenshots exponierter Daten oder Konfigurationen; URLs und Zugriffspfade.
- Dateinamen, Objektnamen, Datenbanknamen, Mailbox-Namen.
- System- und Anwendungs-Konfigurations-Snapshots.
- Authentifizierungs- und Autorisierungs-Logs; Cloud-Audit-Logs.
- Dateizugriffs-Logs, Datenbank-Audit-Logs und Query-History.
- Mailbox-Audit-Logs; Webserver-, WAF-, Firewall-, Proxy-, VPN-, DNS-Logs.
- DLP-Alerts, SIEM-Events, EDR-Alerts, API-Gateway-Logs.
- Logs von Drittanbieterplattformen.
- Kategorien betroffener Daten und ungefähre Datensatzanzahl.
- Bestätigung durch den Data Owner und Datenklassifizierung.
- Nachweise für Verschlüsselung, Pseudonymisierung oder Wirksamkeit der Zugriffskontrollen.
- Nachweise für Zugriff, Download, Export, Löschung, Veränderung oder Veröffentlichung.
Kommunikations-Checkliste
- Incident-Response-Team, Datenschutz/Recht, Data Owner, Management und betroffene Geschäftsbereiche benachrichtigen.
- Kommunikations-/Customer-Support-Teams benachrichtigen, wenn externer Kontakt möglich ist.
- Lieferantenmanagement benachrichtigen, wenn eine Drittpartei beteiligt ist.
- Interne Updates sachlich und versioniert halten; eine einzige Quelle der Wahrheit pflegen.
- Prüfen, ob eine Meldung an die Aufsichtsbehörde erforderlich ist.
- Prüfen, ob betroffene Personen informiert werden müssen.
- Alle externen Kommunikationen durch Datenschutz/Recht und Kommunikation vorbereiten.
- Alle ausgehenden Mitteilungen und Freigaben aufbewahren.
Interne Zwischenmeldung: „Eine vermutete Datenpanne wird derzeit untersucht. Das Incident-Response-, Datenschutz-/Rechts- und technische Team bewertet Umfang, betroffene Daten und mögliche Meldepflichten. Bitte nicht extern spekulieren und keine potenziell relevanten Beweise löschen."
Immediate Response
Scope
Containment
Assessment
Notification
Remediation
Recovery
Sofortreaktion
Umfang
Eindämmung
Bewertung
Meldung
Remediation
Wiederherstellung
Threat Sentinel IR Playbook Library · CC BY 4.0