How to Write an Incident Response Plan for a Data Breach

An incident response plan is the document a company reads on the worst day of its year, so it only does its job if it was written before that day arrived. The common failure mode is not having no plan at all. It is having a plan that names a “security team” with no actual people attached, skips the containment steps because they seemed obvious when someone was drafting calmly at a desk, and never states a notification deadline because nobody checked which law applied. None of that surfaces until an incident is actually underway and someone is trying to follow a document that does not answer the questions being asked of it in real time.

A workable plan is built from five parts: a response team with named roles, a severity classification scheme, a sequence of response phases from detection through recovery, a notification section that states the actual legal deadlines that apply to the business, and a post-incident review process. Here is what belongs in each one.

Build the Incident Response Team

The team section names roles, not just a department. At minimum, a plan needs an Incident Commander (the person with authority to declare an incident and direct the response), a technical lead (the person who actually contains and remediates), and a communications lead (the person who drafts notifications and talks to affected parties, counsel, and if needed the press). Smaller organizations often collapse these into two people rather than three, and that is fine, but every role still needs a named owner and a phone number, not a generic “IT” or “legal” placeholder.

The table should list each role next to a name, an email, and a phone number, plus a backup for each in case the primary is unreachable or is the person who caused the incident. A plan that says “the security team will be notified” without naming who is on it is not actionable at 2am on a Saturday, which is a genuinely common time for a breach to be discovered, since automated monitoring and attacker activity both run around the clock while staffing does not.

Classify Severity Before an Incident, Not During One

A severity scale (commonly four levels: critical, high, medium, low, or P1 through P4) tells the team how hard to respond without a debate happening in the middle of the incident about whether this is a big deal. A critical incident might be defined as active unauthorized access to production systems or personal data currently being exfiltrated; a low incident might be a phishing email that was reported and blocked before anyone clicked it. The classification decides which parts of the plan activate: a low-severity incident may not need the communications lead or a client notification at all, while a critical incident triggers the full team, forensic preservation, and the notification section.

The Four Response Phases

Every incident moves through the same sequence regardless of what caused it: detection, containment, eradication and recovery, with forensic preservation sitting between containment and eradication whenever the incident might end up as a legal or insurance matter.

Containment comes first and on purpose, before anyone has fully diagnosed the root cause, because the priority is stopping the incident from getting worse while investigation continues in parallel. Short-term containment usually means isolating the affected system from the network, revoking any credentials that may be compromised, and blocking the IP addresses or domains involved, actions a team can take within minutes without yet knowing exactly what happened. Forensic preservation, when it applies, has to happen before eradication starts, because wiping or patching a compromised system destroys the evidence a later investigation, insurance claim, or regulator inquiry might need. Recovery is not finished at the point systems come back online; the plan should call for closer-than-normal monitoring of restored systems for a defined window (72 hours is a common baseline) in case the same weakness gets exploited again immediately.

Write Down the Actual Notification Deadlines

This is the section most first-draft plans get wrong, usually by describing notification in vague terms (“authorities will be notified as required by law”) instead of naming the specific deadline that applies to the business. Which laws apply depends on where the affected individuals live and what kind of data was involved, and more than one can apply to the same incident.

GDPR’s 72-hour clock starts running from the moment the organization becomes aware of the breach, not from when the investigation concludes, which is why the notification to the supervisory authority is allowed to be preliminary and updated later as more facts come in. US state breach notification laws are not uniform: most states require notification “without unreasonable delay,” and a growing number now attach a specific outer limit, commonly somewhere between 30 and 72 hours for the outer bound depending on the state, so a business operating nationally needs to know which states its affected individuals live in before it can state a single deadline. HIPAA’s 60-day window is far more forgiving on paper than GDPR’s 72 hours, but it applies to a narrower category of organizations, those handling protected health information as a covered entity or business associate.

The plan should also state who decides to engage breach counsel and at what point, since counsel typically needs to be involved before any external notification goes out, and for a business with obligations under more than one of these regimes, before the notification language itself is drafted so it holds up the same way across every jurisdiction it gets sent to. Whether a breach notification duty exists at all for a given incident is a downstream question of what personal data your privacy policy commits you to protecting in the first place. See GDPR Privacy Policy Requirements for how those disclosure commitments are usually structured, since an incident response plan and a privacy policy should describe the same data-handling reality rather than being drafted independently of each other.

Post-Incident Review and Retention

Once an incident is closed, the plan should require a review meeting within a defined window, commonly five to ten business days, that produces a written report: root cause, a timeline of what happened and when, an honest assessment of how well the response actually went, and specific changes to controls or procedures coming out of it. Skipping this step is how the same gap in monitoring or the same missing multi-factor authentication requirement causes a second incident eighteen months later.

The plan should also state a retention period for incident records, logs, and reports, commonly several years, since a regulator investigating a breach can ask for documentation well after the incident is closed, and a business that already deleted its own incident report has nothing to show that its response was adequate.

Test the Plan Before You Need It

A plan that has never been rehearsed reads differently on the page than it plays out in a real incident, which is why most mature plans call for an annual tabletop exercise, walking the response team through a simulated scenario end to end without touching production systems. The exercise usually surfaces the same kinds of gaps every time: a contact whose phone number is out of date, a role nobody actually agreed to own, a notification deadline the team did not realize applied to them. Finding those gaps in a tabletop exercise is inexpensive. Finding them during an actual breach is not.

If a data breach happens, an incident response plan works alongside the privacy policy and any Data Processing Agreements the business has in place with vendors, since a breach that originates at a subprocessor still triggers the primary business’s own notification obligations to its own customers. Our incident response plan generator builds the team roster, classification levels, response phases, and the notification sections for GDPR, US state law, and HIPAA from a short set of questions, so the deadlines in the document match the jurisdictions the business actually operates in rather than a generic template. For the vendor side of that same picture, see Do You Need a Data Processing Agreement for when a signed DPA, and the breach notification clause inside it, is required with a third-party tool that touches personal data.