Data Breach Response Checklist
A data breach response checklist for small teams: contain the incident, assess the risk to people, meet notification deadlines and keep a defensible record.
- Typical schedule per incident
- The checklist 4 sections, 20 items
- Variables
{{incident_id}}
Start this checklist as soon as you suspect that personal data was lost, exposed, changed or accessed without permission. Typical cases are an email sent to the wrong list, a public storage bucket, a stolen laptop or a compromised account. Under the GDPR the clock for notifying the supervisory authority starts when you become aware of the breach, not when the investigation ends, so start the run early.
Who owns it
Appoint one incident lead who makes decisions and keeps the timeline. Pull in technical staff for containment, and your privacy contact or Data Protection Officer for the notification decision. Adapt this to your jurisdiction and contracts; it is a practical checklist, not legal advice. Involve a lawyer for serious breaches.
Common pitfalls
- Waiting for certainty. You can notify the authority with the facts you have and add details later. Waiting for a full picture risks missing the deadline.
- Destroying evidence while fixing. Wiping a server or resetting a mailbox before saving logs makes it impossible to know what was taken.
- Deciding "no risk" without writing it down. Even breaches you do not notify must be documented with your reasoning.
- Forgetting your customers' contracts. If you are a processor, your customers usually expect to be told quickly so they can meet their own duties.
A Runbook run timestamps every step, which gives you the timeline the authority may ask for.
The checklist: Data breach response {{incident_id}}
Confirm and contain
-
Record the time the breach was discovered and who reported it
This time matters for notification deadlines. Write it down before anything else.
-
Appoint an incident lead and open a private channel for
{{incident_id}} -
Stop the exposure: revoke access, rotate credentials, close the bucket or recall the message
-
Preserve evidence: export logs, take snapshots and save the affected messages before changing systems
-
Confirm whether the breach is still ongoing
Assess the risk
-
Identify which personal data categories are affected
-
Estimate how many people and records are affected
-
Note whether special category, financial or identity data is involved
-
Note whether the data was encrypted and the key was not exposed
-
Assess the likely consequences for the people affected and record the risk level
Notify
-
Decide whether the supervisory authority must be notified and record the reasoning
Under the GDPR, notify without undue delay and where feasible within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to people. Other laws, such as the Swiss FADP, have their own rules.
-
Submit the notification to the supervisory authority, or record why it was not needed
-
Decide whether affected people must be informed and prepare a plain-language notice
-
Inform affected customers or controllers if you act as a processor
-
Notify your cyber insurer, if you have one optional
-
Inform the police if a crime is involved optional
Recover and learn
-
Confirm the root cause is fixed and access is fully restored to a safe state
-
Monitor for misuse of the exposed data or credentials
-
Add the breach to the breach register with facts, effects and actions taken
-
Hold a blameless review and create tickets for the follow-up actions
Checklist as Markdown
Frequently asked questions
When do I have to report a data breach under the GDPR?
A controller must report a personal data breach to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it. The exception is a breach that is unlikely to result in a risk to people's rights and freedoms. If the risk is high, you must also inform the people affected.
Do I need to document breaches I do not report?
Yes. The GDPR requires controllers to document all personal data breaches, including the facts, effects and remedial action. Record your reasoning for not notifying, so you can show the decision was considered.
What if we are a processor and our customer's data is affected?
A processor must inform the controller without undue delay after becoming aware of the breach. Your data processing agreement may set a tighter timeline. The controller then decides about notifying the authority and the people affected, so give them the facts quickly.
Updated