Data Breach Response Checklist
Personal data has been accessed or taken. Work through 34 steps in order — confirm and preserve, contain the exfiltration path, identify the data and the people, assess harm, decide each notification against its own deadline, communicate and close out — and keep the record regulators will ask for.
Template & sample only — a structured starting point with sample content, not legal, audit, certification or investment advice.Customise it with your own details for free; exporting the generated document is part of Pro.
A working checklist for a personal-data breach, from the first alert to the post-incident review: confirm and scope, preserve evidence, contain the exfiltration path, identify the data and the people, assess harm, decide each notification against its own deadline, communicate, and close out. The sample shows a fictional retailer two days into a customer-database breach — replace it with your own incident. The generated record doubles as your breach log.
Your context
Incident summary
1. Confirm, scope and preserve evidence
Decide quickly whether this is a breach, write down when you became aware, and keep the evidence that will answer "what was taken" later.
Record the exact date and time the organisation became aware, who raised it and how — this starts several regulatory clocksGDPR Art. 33material
Declare an incident, assign an incident commander and open a single incident channel and logNIST SP 800-61r3material
Engage legal counsel (internal and, if needed, external breach counsel) and decide whether the investigation runs under privilegematerial
Notify the cyber insurer and check panel-vendor and consent requirements before engaging forensics, PR or notification vendors
Preserve evidence before changing anything: database and application logs, cloud audit logs, VPN/IdP sign-ins, memory and disk images of affected hostsNIST CSF RS.ANmaterial
Write the working hypothesis: entry point, account used, systems touched, time window — and what would disprove it
2. Contain the exfiltration path
Stop more data leaving without destroying what you need to prove scope.
Disable or rotate the credentials, keys and tokens used in the breach, safely: new credential first, verify, then revoke the old onematerial
Block the exfiltration route: attacker IPs and domains, unexpected outbound transfers, public storage links, exposed endpointsmaterial
Hunt for persistence: new accounts, keys, OAuth grants, scheduled jobs, web shells and database users created in the window
Put heightened monitoring on the affected data stores and accounts for re-entry and further bulk reads
Monitor leak sites, forums and paste sites for the data, and keep any sample you obtain under evidence handling
3. Identify the data: types, records, people and jurisdictions
Notification decisions turn on what data, about whom, and where those people live.
List every table, bucket, file share or system the attacker accessed or could have accessed, with row countsmaterial
Classify the data categories: contact, government ID numbers, financial and card data, health, credentials, children's data, special category datamaterial
De-duplicate to estimate unique individuals, and split by country or state of residence
Confirm whether the data was encrypted or hashed, how, and whether keys or salts were also exposed
Affected data sources
One row per system or table. Feeds the scoping estimate and the notification decisions.
4. Assess the harm
Assess the likely harm to individuals (identity theft, fraud, discrimination, physical safety, distress) and record the reasoningGDPR Art. 34material
Identify vulnerable groups in the data: children, patients, people at risk of harm if their address is disclosed
Check for evidence of misuse: data on leak sites, fraud reports, credential stuffing against your login
Keep a breach record (facts, effects, remedial action) even for breaches you decide not to notifyGDPR Art. 33(5)
5. Notification decisions
Decide each notification deliberately, against its own trigger and deadline. Use the table below as the decision log.
Calculate every applicable deadline from the awareness time and put them in the incident log, with an owner for eachmaterial
Notify the lead supervisory authority and other regulators on time, in phases if facts are incompleteGDPR Art. 33material
If listed in the US, run the materiality assessment without unreasonable delay and record the date materiality was determinedSEC Form 8-K Item 1.05
Decide whether and when to notify individuals, and which channel (email, letter, substitute notice)GDPR Art. 34material
Check customer, partner and payment-card contracts for notice duties and deadlines (often 24 to 72 hours)
Decide on a report to law enforcement, and whether they have asked for a notification delay (get any request in writing)
Notification decision log
One row per recipient. Record the decision even when it is "not required", with the reason.
If you host or process the data for customers
Hosting providers, SaaS platforms and outsourcers usually process data on behalf of their customers. Those customers are the controllers and carry their own notification duties, which only start once you tell them. Skip this section if the data is yours alone.
Tell each affected customer without undue delay once you are aware, even before the investigation is completeGDPR Art. 33(2)material
Call each affected customer's named security or privacy contact first, then follow up in writing with what is known, what is not yet known and the next update time
Give customers the specific actions they must take (rotate API keys, reset integration credentials, warn their own users) and the evidence they will need for their own assessmentmaterial
Decide whether customers who were not affected also need a notice or a public knowledge-base article, so they hear it from you first
Check each customer contract for notice periods, required content, cooperation and audit rights, and cost allocation
Give customers one named contact and a dedicated channel for the incident, not only a shared support mailbox
6. Communications and support for affected people
Prepare a holding statement and a single spokesperson before anything is publicmaterial
Keep regulator notices, customer notices, press statements and staff briefings consistent with each other
Stand up a call centre or support page with an FAQ, and brief support staff before notices go out
Decide on credit or identity monitoring: who is offered it, for how long, and why (some US states require it for SSN exposure)
Brief staff on what to say, where to route questions, and the phishing risk to themselves
7. Post-incident
Fix the root cause and verify the fix (for example, remove standing database credentials from reporting services)material
Hold a blameless post-incident review within two weeks and track actions to closure
Send follow-up and final reports to regulators and close out each notification in the log
Review data minimisation and retention: could less data have been exposed?
Reporting contacts
Agencies change names and numbers: verify every row when the plan is reviewed, and add your sector regulators and national CSIRT.
What this template gives you
- Seven phases: confirm and preserve evidence; contain the exfiltration path; identify data, records and jurisdictions; assess harm; notification decisions; communications and support; post-incident.
- The first step is writing down when you became aware — that timestamp starts the GDPR 72-hour clock and several others.
- A notification decision log records every recipient (regulators, individuals, contract counterparties, insurer) with its basis, deadline and decision, including "not required" with the reason.
- Sample content shows a fictional retailer two days into a customer-database breach, so the page is useful before you type anything.
Frequently asked questions
What should you do first after a data breach?
Record when you became aware, declare an incident with one commander, bring in counsel, and preserve evidence before you change anything. Then contain the path the data left by — the credential, the exposed endpoint, the transfer route — without wiping the systems you need to investigate.
Do we have to notify every breach?
No. Most regimes notify on a risk or harm threshold: GDPR requires a regulator notice unless the breach is unlikely to result in a risk to people, and individual notice only for high risk; Australia's scheme turns on likely serious harm; US state laws depend on the data elements involved. Whatever you decide, record the reasoning. Confirm the decision with counsel.
Should we offer credit monitoring?
It helps when government ID numbers or financial account data are exposed, and some US states require it for Social Security number breaches. For contact details and hashed passwords, forced password resets and clear phishing guidance protect people more.
Is this a finished document I can rely on?
No. Every tool in this suite is a template with sample content. It gives you a structured, editable starting point and generates a document from your own answers, but it is not legal, audit, certification, investment or professional advice. Review and adapt the output, and have it checked by the appropriate specialist before you rely on it.
Who can use it?
Anyone. Using it and customising it with your own details is free, and your work is saved in your own browser. Exporting the generated document (Word, PDF, Markdown, CSV) is part of any PlayCISO paid plan.
More free security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.