How to Write a Security Incident Response Plan

A security incident response plan turns a chaotic event into a rehearsed procedure. Here is how to build one around the NIST SP 800-61 lifecycle, assign roles, classify severity, handle notification and evidence, and prove it works through testing.

What a security incident response plan is — and why a document is only the start

A security incident response plan (IRP) is the written procedure your organization follows when something goes wrong with the confidentiality, integrity, or availability of your systems or data — a ransomware hit, a compromised account, a lost laptop, a misconfigured database left open to the internet. Its job is to replace improvisation under pressure with a sequence people have read in advance, so that during a real event you are executing a plan rather than inventing one.

The distinction that matters most is between having the document and operating it. An IRP that sits unread in a shared drive does nothing; auditors, regulators, and your own incident commander care whether the plan is staffed, understood, rehearsed, and actually invoked when an incident occurs. A good plan is therefore short enough to be usable in a crisis, specific enough to remove guesswork, and maintained as your systems and team change.

A widely used reference for structuring an IRP is NIST's computer security incident handling guidance, SP 800-61, which frames response as a repeatable lifecycle. The four-phase lifecycle most teams know comes from SP 800-61 Revision 2; in April 2025 NIST superseded Revision 2 with Revision 3, which realigns incident response to the NIST Cybersecurity Framework (CSF) 2.0 Functions rather than centering a fixed lifecycle. The four-phase model remains a clear, broadly recognized way to organize a plan, so the rest of this article walks those phases and the supporting elements — roles, severity, notification, evidence, and testing — and shows how the same plan supports an ISO 27001, SOC 2, or HIPAA program. This is general information, not legal advice; confirm specifics for your jurisdiction and contracts with qualified counsel.

The incident response lifecycle (aligned to NIST SP 800-61)

The four-phase incident response lifecycle from NIST SP 800-61 Revision 2 remains a strong way to organize an IRP, and the same activities carry over to the CSF 2.0-aligned approach in Revision 3. Preparation is the work you do before anything happens: standing up the response team, defining what counts as an incident, deploying logging and detection, maintaining contact lists and an out-of-band communication channel, and building the runbooks and checklists you will reach for. Most of the difference between a smooth response and a painful one is decided here, long before an alert fires.

Detection and analysis is recognizing that an event is actually an incident and understanding its scope. Your plan should describe how incidents are reported (monitoring alerts, a staff report, a customer tip, a vendor disclosure), how they are triaged and validated, and how an initial severity is assigned. Accurate, early analysis is what lets you respond proportionately instead of either over-reacting to noise or under-reacting to a real breach.

Containment, eradication, and recovery is the operational core. Containment limits the damage — isolating a host, disabling a credential, blocking an address — ideally before you wipe anything, so evidence survives. Eradication removes the root cause, such as malware, a backdoor, or the exploited vulnerability. Recovery restores systems to normal from known-good backups and confirms, through monitoring, that the threat is genuinely gone rather than dormant.

Post-incident activity — the lessons-learned phase — closes the loop. Within a defined window after the incident, the team reviews what happened, how the response went, and what to change: a control to add, a detection gap to fix, a runbook to update, a training need to address. This is the step organizations most often skip and the one that turns a single painful incident into a permanently stronger program. (Revision 3 reframes this as continuous improvement woven throughout the response, not only a closing review.)

Roles, responsibilities, and severity classification

A plan no one owns will not run, so name the roles before an incident, not during one. At minimum, designate an incident commander who has the authority to make decisions and coordinate the response, plus clear responsibilities for technical investigation and containment, internal and external communications, and legal and regulatory analysis. Define how the team is activated and who can declare an incident, and keep an up-to-date contact roster — including after-hours coverage and an out-of-band way to reach people if your primary systems are the thing that is down.

Severity classification is what makes the response proportionate and the escalation predictable. Define a small number of tiers — many organizations use three or four, from a minor, contained event up to a critical incident such as a confirmed data breach or a major outage — and write plain criteria for each based on factors like the sensitivity and volume of data involved, the number of systems or customers affected, and the operational and reputational impact. Tie each tier to concrete actions: who must be notified, how fast, whether executives or legal counsel are engaged, and when external help such as a forensics firm or your cyber-insurance carrier is brought in.

The value of severity tiers is that they remove debate at the worst possible moment. When an analyst can map symptoms to a defined level and the plan already states what that level triggers, the team escalates and communicates correctly under stress instead of arguing about whether something is "serious enough" to wake the CISO.

Notification: internal, customer, and regulatory

Notification is where incident response meets the law, and it is the part most likely to create liability if handled badly. Your plan should separate three audiences. Internal notification is the escalation path inside the company — who tells leadership, legal, and affected business units, and when. Customer and partner notification covers contractual commitments, which often specify a window (for example, notifying affected customers within a stated number of hours or days of confirming a breach), so your plan should reference those obligations rather than leave them to memory.

Regulatory notification depends entirely on what data was involved and where the affected people are, and the rules genuinely differ, so the plan should point to the obligations that apply to you rather than assume one timeline fits all. Under the EU/UK GDPR, a personal-data breach that meets the risk threshold must be reported to the supervisory authority without undue delay and, where feasible, no later than 72 hours after becoming aware of it, with notification to affected individuals required when the risk to them is high. Under HIPAA's Breach Notification Rule (45 CFR 164.400–414), covered entities must notify affected individuals without unreasonable delay and no later than 60 days; breaches affecting 500 or more individuals also require contemporaneous notice to HHS and, in the affected area, the media, while smaller breaches are logged and reported to HHS annually. US state breach-notification laws add their own triggers and deadlines, and many other sectors and regions have rules of their own.

Because these timelines are short and the wording is consequential, build the notification decision into the plan in advance: a documented assessment of whether a reportable breach occurred, a list of the regulators, customers, and authorities you may need to contact, and pre-reviewed templates. The clock often starts at awareness, not at full understanding, so knowing the path beforehand is what keeps you inside the window.

Evidence handling and testing the plan

How you handle evidence during an incident determines whether you can later understand what happened, support an insurance claim, satisfy a regulator, or pursue legal action. Build evidence preservation into the response itself: capture and protect relevant logs, disk and memory images, and records before containment or rebuilding destroys them, and favor containment steps that isolate rather than wipe. Maintain a basic chain of custody — what was collected, by whom, when, and where it is stored — and keep a contemporaneous incident timeline as you go, because reconstructing one afterward from memory is unreliable. For anything that may become a legal matter, involve counsel early, since they may direct how evidence is gathered and preserved.

A plan you have never exercised is a hypothesis. Testing is what turns it into a capability, and it is also what auditors and regulators increasingly expect to see. The most accessible method is a tabletop exercise: gather the response team, walk through a realistic scenario ("an employee reports their laptop was stolen and it held client files," or "a vendor notifies us of a breach affecting our data"), and talk through each decision against the plan. Tabletops routinely expose stale contact details, unclear ownership, missing log sources, and notification steps no one had thought through — all far cheaper to find in a conference room than during a live incident.

Run these exercises on a regular cadence and after any significant change to your systems or team, capture the findings, and feed them back into the plan exactly as the lessons-learned phase prescribes. A plan that is tested, revised, and tested again is the difference between a document and a working capability.

How the plan supports ISO 27001, SOC 2, and HIPAA

A well-run incident response capability is not a compliance side-quest; it is a control that multiple frameworks require, so one good plan does triple duty. ISO/IEC 27001:2022 addresses information security incident management directly in Annex A — controls 5.24 through 5.27 cover planning, assessment, response, and learning from incidents, and 5.28 covers the collection of evidence — and the standard expects you to operate and improve these as part of a working management system. For SOC 2, the Common Criteria include a dedicated set of criteria (the CC7 series) covering how you detect, respond to, and recover from security events; a service auditor will look for a documented IRP and, in a Type II examination, evidence that you actually followed it.

HIPAA makes incident response a named requirement of the Security Rule: covered entities and business associates must have "Security Incident Procedures" under 45 CFR 164.308(a)(6), and the separate Breach Notification Rule governs what you must do when protected health information is compromised. Across all three, the pattern is identical — having the procedure documented is necessary but not sufficient. The frameworks want the plan operated, the incidents logged, and the lessons applied, which is exactly what the lifecycle in this article produces.

This is where an editable starting point earns its keep. ComplianceDocs ISO 27001 and SOC 2 toolkits include an incident response procedure alongside the rest of the policy set, giving you a structured, framework-aligned draft to tailor to how your organization actually detects, escalates, and reports incidents — rather than writing one from a blank page under deadline. Be clear about what that does and does not do: a template is the documentation layer that speeds readiness. It does not make you certified or attested, and it does not, by itself, make you compliant. ISO 27001 certification comes from an accredited body, a SOC 2 report comes only from a licensed CPA firm, and HIPAA compliance comes from operating the controls — including running, testing, and improving the very plan the template helps you write.

Frequently asked questions

What is the difference between a security event and a security incident?

An event is any observable occurrence in a system or network — a login, a firewall alert, a failed scan — and most events are routine noise. An incident is an event (or series of events) that actually threatens the confidentiality, integrity, or availability of your systems or data and warrants a response, such as a confirmed account compromise or a ransomware infection. The detection and analysis phase of your plan exists precisely to separate the two, so you respond to real incidents without drowning in benign events. Your plan should define, in plain terms, what crosses the line from event to incident in your environment.

Which lifecycle should I base my incident response plan on?

The most widely referenced model is the four-phase lifecycle from NIST SP 800-61 Revision 2 — preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. In April 2025 NIST superseded Revision 2 with Revision 3, which realigns incident response to the NIST Cybersecurity Framework (CSF) 2.0 Functions rather than a fixed lifecycle; if you are aligning to CSF 2.0, work from Revision 3. Either way, organizing a plan around the familiar phases keeps it logical and complete, and it maps cleanly onto what ISO 27001, SOC 2, and HIPAA expect. You do not have to copy NIST's wording, but its structure is a sound, broadly recognized backbone that auditors and responders will find familiar.

How fast do I have to report a data breach?

It depends entirely on the data and the people affected, and the deadlines genuinely differ, so your plan should reference the rules that apply to you rather than assume one timeline. Under the GDPR, a qualifying personal-data breach must be reported to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it. Under HIPAA, affected individuals must be notified without unreasonable delay and no later than 60 days, with breaches of 500 or more individuals also requiring prompt notice to HHS and the media. US state laws and customer contracts add their own deadlines, so identify your specific obligations in advance and confirm current requirements with counsel.

What is a tabletop exercise and how often should we run one?

A tabletop exercise is a discussion-based drill in which the incident response team walks through a realistic scenario and talks through each decision against the plan, without touching production systems. It is the cheapest, fastest way to test an IRP and reliably surfaces stale contact lists, unclear ownership, missing log sources, and notification gaps before a real incident does. A common practice is to run one at least annually and after any major change to your systems or team, then feed the findings back into the plan. Auditors and regulators increasingly expect to see evidence that you test your plan, not just that you have one.

Does buying an incident response procedure template make us compliant or audit-ready?

No. A template is the documentation layer — it gives you a structured, framework-aligned starting point you tailor to your organization, which removes the slowest part of the work. But no document by itself makes you compliant, certified, or attested. ISO 27001 certification comes from an accredited body, a SOC 2 report comes only from a licensed CPA firm, and HIPAA compliance comes from operating the controls. What makes an incident response plan real is staffing it, testing it through exercises, invoking it during actual incidents, and improving it afterward — work only your organization can do.

Related guides: ISO/IEC 27001 · SOC 2

Toolkits that help

← All articles