What a personal data breach is

A personal data breach is a security incident that leads to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. Breaches can be technical (hacking), operational (misdirected email), or physical (lost device).

Common real-world breach examples

• Credentials stolen → attacker exports customer data.
• Misconfigured cloud storage → personal files become publicly accessible.
• Email sent to the wrong distribution list → HR data disclosed.
• Lost laptop without encryption → customer or employee data exposed.

First 60 minutes: contain, preserve, coordinate

The first hour determines whether you limit impact—or expand it. Focus on containment, evidence preservation, and coordination. Avoid uncoordinated changes that destroy logs or obscure what happened.

Immediate actions (practical)

• Escalate fast: trigger your incident channel and assign an incident lead.
• Contain: revoke tokens, rotate keys, disable exposed shares, isolate affected systems.
• Preserve evidence: snapshot logs, keep timestamps, record actions taken and by whom.
• Stop the bleeding: block suspicious IPs, enforce MFA resets, disable compromised accounts.
• Coordinate communications: one spokesperson; avoid speculation in writing.

Triage: scope, data types, and impact

Your triage goal is to answer: What happened? What data was affected? How many people? What is the likely risk? Perfect answers can come later—early decisions need a defensible risk assessment.

When you must notify regulators and individuals

Notification decisions depend on risk to individuals. Under the GDPR, controllers generally notify the supervisory authority within 72 hours of becoming aware of a reportable breach (Article 33). If the breach is likely to result in a high risk to individuals, you also notify affected individuals without undue delay (Article 34).

A simple decision model

Documentation & evidence (the breach file)

Even when a breach is not reportable, you should keep a breach file (incident record) that documents facts, decisions, and actions. This record is what protects you later—during audits, insurance claims, and post-incident reviews.

What to capture in your breach file

• Timeline: detection time, “awareness” time, containment actions, key decisions.
• Systems affected: environments, accounts, endpoints, vendors.
• Data involved: categories, volume, individuals affected, encryption status.
• Risk assessment: reasoning for notification decisions (and mitigations).
• Notifications: regulator submission, communications to individuals, templates used.
• Remediation: patches, rotations, access reviews, monitoring improvements.

A practical breach response playbook

A good playbook turns panic into steps. Keep it short, role-based, and tested. The goal is consistent execution—even with a small team.

Core roles (typical for SMEs)

• Incident Lead: coordinates, assigns tasks, owns the timeline.
• Technical Lead: containment, forensics coordination, remediation.
• Privacy/Compliance Lead: risk assessment, notification decision, documentation.
• Comms Lead: internal/external messaging and customer support guidance.
• Executive Sponsor: decisions on business impact, budget, and escalation.

Playbook steps (repeatable)

1. Detect & declare: confirm incident, open incident ticket/channel, assign leads.
2. Contain: stop exposure, rotate secrets, isolate systems.
3. Preserve evidence: snapshots, logs, hashes, access logs.
4. Assess: data categories, individuals, encryption, attacker access, likely impacts.
5. Decide notifications: regulator + individual notification based on risk.
6. Communicate: provide factual updates, mitigation advice, support scripts.
7. Remediate: fixes, monitoring, access reviews, vendor actions.
8. Review: post-incident review and control improvements (and update RoPA/data map if needed).

Vendors, processors, and “who reports what”

Many breaches involve vendors (processors). Your contracts and internal workflow should define who notifies whom and how quickly. In practice, you need a vendor contact list, escalation paths, and evidence-sharing rules.

Operational controls for vendor-related breaches

• Vendor notification clause: clear timelines (e.g., “without undue delay”).
• Security contacts: named mailbox/phone number for incidents.
• Shared facts: what happened, data categories, scope, mitigations, timeline.
• Decision trail: controller decides regulator/individual notification based on risk.

Data breach checklist (copy/paste)

Use this checklist to respond to and document breaches consistently.

• We declared the incident and opened a single incident ticket/channel with an incident lead.
• We contained exposure (revoked access, rotated keys, isolated systems) and preserved evidence.
• We identified whether personal data was involved and which categories were affected.
• We estimated scope (systems, individuals, volume) and assessed likely impact/risk.
• We documented mitigations (encryption, access controls, containment actions) and decision reasoning.
• We decided whether regulator notification is required (and captured the “awareness” time).
• We decided whether individual notification is required and prepared clear, factual messaging.
• We coordinated vendor communications and tracked their actions and evidence.
• We completed remediation and ran a post-incident review with control improvements.

Sources & further reading

Use primary legal texts and regulator guidance for breach reporting obligations in your specific context.

1. GDPR (Regulation (EU) 2016/679) – EUR-Lex
2. European Data Protection Board (EDPB) – Guidelines & resources
3. ICO – Personal data breaches guidance (practical)
4. Swiss Federal Act on Data Protection (FADP) – Fedlex
5. NIST Privacy Framework (program design)

Last updated: February 22, 2026 • Version: 1.0