Data breach response plan: the first 72 hours and a template

When a data breach happens, several clocks start at once — regulators, customers, insurers, sometimes investors. The organisations that come through well are rarely the ones with the best technology; they are the ones that knew who decides what, had the phone numbers ready and wrote down every decision. This guide gives you that plan.

By Alex Martyushin, founder & risk consultant · Updated 30 October 2026 · 17 min read

What counts as a data breach?

Under UK and EU GDPR, a personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. That definition is wide. It covers:

• Confidentiality breaches — hacking, a phished mailbox, data stolen in a ransomware attack, a spreadsheet emailed to the wrong customer, a misconfigured cloud storage bucket.
• Integrity breaches — records altered without authorisation, such as changed bank details in payroll.
• Availability breaches — personal data lost or inaccessible, for example encrypted by ransomware with no usable backup, or a lost unencrypted laptop.

US state breach laws are generally narrower: most define a breach as unauthorised acquisition of (or, in some states, access to) specific categories of personal information, such as a name combined with a Social Security number, driver’s licence number, financial account number with access code, or in many states medical, biometric or online account credentials. Encrypted data is usually exempt if the key was not also compromised.

Not every security incident is a data breach, and not every data breach must be reported. That is exactly why the plan needs a structured assessment step instead of a gut call.

Incident response plan or data breach response plan?

An incident response plan covers any security incident — malware on a test machine, a denial-of-service attack, a website defacement. A data breach response plan adds what happens when personal or confidential data is involved: legal assessment, notification decisions and communication with affected people. Most small and mid-sized organisations should keep one incident response plan with a clear breach section, rather than two documents that drift apart. NIST SP 800-61 Revision 3, published in April 2025, takes the same view: it treats incident response as part of overall cyber risk management, organised around the six functions of the NIST Cybersecurity Framework 2.0.

Common causes of data breaches

A response plan limits the damage; preventing the breach in the first place is cheaper. Most breaches in small and mid-size organisations come from a short list of causes, each with a well-known control:

The first 72 hours, step by step

Timings below are a guide. The point is the order: stabilise and preserve first, understand second, decide and communicate third — with the decision log running from minute one.

Hour 0–1: confirm, contain, convene

1. Log the discovery. Who found what, when, and how. The time you became aware matters for GDPR’s 72-hour clock and for every other deadline.
2. Contain without destroying evidence. Disconnect affected devices from the network rather than wiping or powering them off; disable compromised accounts; revoke sessions and tokens; block the malicious sender or IP. For a misdirected email, ask the recipient to delete it and confirm in writing.
3. Call the incident lead (or the deputy) and open a dedicated channel that does not rely on possibly compromised systems — a phone bridge or a messaging group on personal devices.
4. Call your insurer’s incident line if you have cyber cover. Many policies require prompt notice and the use of their approved forensic and legal firms; acting first and telling them later can affect what is covered.

Hours 1–24: understand the scope

5. Engage specialist help as needed: forensic investigators, breach counsel, your IT provider. Where possible, instruct forensic investigators through lawyers — in some jurisdictions this can help protect the confidentiality of their findings; take legal advice on this.
6. Preserve evidence: logs (email, sign-in, firewall, endpoint), copies of ransom notes or phishing emails, affected disk images. Check log retention so evidence is not overwritten.
7. Establish what data is involved: which systems, which data categories (contact details, financial, health, children’s data, credentials), how many records and people, and which countries or US states they live in.
8. Establish what happened to it: viewed, copied, altered, deleted, encrypted? Is it now public? Is the attacker still present?
9. Assess risk to individuals: what could realistically happen to them — fraud, identity theft, discrimination, distress, physical harm? This drives the notification decision.

Hours 24–72: decide, notify, communicate

10. Make the notification decisions using the matrix below, with legal advice. Record each decision, including decisions not to notify and the reasons.
11. File regulator notifications that are due. Under GDPR you may notify in phases: send what you know within 72 hours and follow up as the investigation progresses.
12. Prepare communications to affected individuals, customers, staff and, if needed, the media. Be accurate, do not speculate, tell people what to do to protect themselves, and give a contact point.
13. Notify contractual parties — customers for whom you process data as a processor usually need to hear from you quickly so they can meet their own deadlines, and many contracts set specific notice periods.
14. Brief the board or owners with facts, decisions taken, decisions pending and the next update time.
15. Report to law enforcement where a crime is involved — Action Fraud or the NCSC in the UK, the FBI or CISA in the US.

Notification duties: who, when and to whom

The table summarises the main regimes a small or mid-sized organisation is likely to meet. It is a starting point, not legal advice — thresholds, definitions and deadlines have detail that matters, and several regimes may apply to the same incident.

Three points catch organisations out. First, US state laws are triggered by where the affected people live, not where you are based, so a single breach can involve many states. Second, the SEC’s four-day clock runs from the materiality determination, not from discovery — but you cannot delay that determination, for example to wait for a board meeting. Third, the GDPR requires you to document every personal data breach, including those you decide not to report, with the facts, effects and remedial action. For a wider view of these obligations, see our GDPR compliance checklist and HIPAA compliance guide.

What to tell affected individuals

A breach notice is read by worried people, often on a phone. Regulators set minimum contents — under GDPR Article 34, for example, a clear description of the breach, the likely consequences, the measures taken, and a contact point — and US state laws add their own requirements. In practice a good notice covers:

• What happened and when, in plain language, without speculation.
• What information was involved — be specific (“name, email address and order history; no card details”).
• What you are doing to contain it and prevent a repeat.
• What they can do — change passwords, watch for targeted phishing, contact their bank; in the US, place a fraud alert or credit freeze, and use any credit monitoring you offer.
• How to contact you — a dedicated email address or phone line staffed by people with a script and an escalation route.

Send it from a channel people recognise, and warn them that criminals sometimes send fake breach notices — your genuine notice should never ask for passwords or payment.

Incident response plan template

The best incident response plan template is short enough to read in a crisis. Aim for a few pages, printed and stored offline as well as online. These are the sections that matter.

1. Roles and deputies

Name a deputy for every role. Breaches have a habit of starting on the first day of someone’s holiday.

2. Contact list

Keep it out of band — printed, and on phones — because email and the intranet may be down or compromised. Include:

• Response team members and deputies, with mobile numbers.
• Cyber insurer incident line and policy number.
• Breach counsel and forensic firm (insurer panel firms if applicable).
• IT provider and key SaaS vendors’ security contacts.
• Bank fraud team, for payment-related incidents.
• Regulators: data protection authority, sector regulators, and the online reporting forms you would use.
• Law enforcement reporting routes.
• Key customers or partners with contractual notification rights, and the clause that applies.

3. Severity levels

Define three or four levels so the response is proportionate. For example: low — contained, no personal data; medium — limited personal data, low risk to individuals; high — sensitive data, many people or ongoing attacker access; critical — business operations stopped or a regulator, media or investor disclosure likely. Each level should state who must be told and how fast.

4. Decision log

The decision log is your evidence that the organisation acted reasonably. Regulators, insurers and courts will ask what you knew and when. Keep it simple:

5. Playbooks, templates and review

• One-page playbooks for your most likely scenarios: compromised mailbox, ransomware, lost device, misdirected email, supplier breach.
• A notification matrix like the table above, tailored to where your customers and staff are.
• Draft notices for regulators, individuals and customers, with gaps to fill.
• A post-incident review: what happened, what worked, what to change, which register entries to update.
• An annual tabletop exercise — two hours, one realistic scenario, the real decision-makers in the room.

Testing the plan with a tabletop exercise

A data breach response plan that has never been rehearsed usually fails on small things: an out-of-date phone number, a deputy who did not know they were one, nobody sure who decides on notification. A two-hour tabletop exercise, once a year and after major changes, finds those gaps cheaply:

1. Pick a realistic scenario from your register — a compromised finance mailbox, ransomware with data theft, a supplier breach.
2. Bring the real decision-makers and their deputies, with the printed plan.
3. Release information in stages (“injects”): the first alert, then the scope, then a journalist’s call, then the 72-hour deadline.
4. Ask at each stage: who decides, using what information, and what do we record in the decision log?
5. Finish with a short list of fixes, each with an owner and date, and update the plan and register.

Data breach insurance

Data breach insurance usually comes as part of a cyber insurance policy. Policies differ, so read the wording, but cover is often split into:

• First-party costs: forensic investigation, legal advice, notifying individuals, call centres, credit or identity monitoring, data restoration, business interruption and, in some policies, cyber extortion.
• Third-party liability: claims from affected individuals or business customers, regulatory investigation costs and, where the law allows them to be insured, some fines or penalties.

Check the conditions as carefully as the limits: how quickly you must notify the insurer, whether you must use panel firms, what requires the insurer’s prior consent, and which security controls you declared at inception. A policy that assumed MFA on all remote access may respond differently if it was not in place. Insurance transfers part of the financial impact; it does not reduce the likelihood, and it cannot restore customer trust.

Breach-related risks to keep in your register

A response plan reduces impact. The risk register is where you track whether that reduction is real, alongside the causes of breaches. Examples with illustrative residual scores on a 5×5 risk matrix — the method is explained in our guide to the risk register:

Supplier-caused breaches belong in your third-party risk assessment as well.

Indicators that the plan works

See key risk indicators for how to choose and tune thresholds.

Common mistakes

• Wiping before investigating. Rebuilding a machine straight away removes the evidence you need to know what was taken.
• Waiting for the full picture before notifying. Notify on what you know and update.
• Plans stored only on the network that has just been encrypted.
• No record of decisions not to notify. They need justifying just as much as notifications do.
• Speculative public statements — “no evidence of data theft” on day one, contradicted on day five.
• Forgetting contracts. Customers, partners and insurers may have shorter notice periods than regulators.
• No follow-through. Lessons learned that never reach the risk register will be learned again.