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

An event is any observable occurrence in a system or network, such as a login, a firewall alert, or a failed scan. 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. Examples include a confirmed account compromise or a ransomware infection. The detection and analysis phase of your plan exists to separate the two. That way 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.

How fast do I have to report a data breach?

It depends 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. Where feasible, that is within 72 hours of becoming aware of it. Under HIPAA, affected individuals must be notified without unreasonable delay and no later than 60 days. Breaches of 500 or more individuals also require prompt notice to HHS and the media. US state laws and customer contracts add their own deadlines. Identify your specific obligations in advance and confirm current requirements with counsel.

How to Write a Security Incident Response Plan

A security incident response plan turns a chaotic event into a rehearsed procedure. This guide shows how to build one. It covers the NIST SP 800-61 lifecycle, roles, severity tiers, notification, evidence handling, and testing.

Updated June 24, 2026

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. The trigger might be a ransomware hit, a compromised account, a lost laptop, or a database left open to the internet. The plan's job is to replace improvisation under pressure with a sequence people have read in advance. During a real event, you execute a plan instead of 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. So a good plan is short enough to use in a crisis. It is specific enough to remove guesswork. And it is 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. It 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. Revision 3 realigns incident response to the NIST Cybersecurity Framework (CSF) 2.0 Functions rather than a fixed lifecycle.

The four-phase model is still a clear, broadly recognized way to organize a plan. So the rest of this article walks through those phases and the supporting elements: roles, severity, notification, evidence, and testing. It also shows how the same plan supports an ISO 27001, SOC 2, or HIPAA program. This is general information, not legal advice. Confirm the specifics for your jurisdiction and contracts with qualified counsel.

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

The four-phase lifecycle from NIST SP 800-61 Revision 2 is still a strong way to organize an IRP. The same activities carry over to the CSF 2.0-aligned approach in Revision 3. Preparation is the work you do before anything happens. You stand up the response team, define what counts as an incident, and deploy logging and detection. You also maintain contact lists, an out-of-band communication channel, and the runbooks 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 means recognizing that an event is actually an incident and understanding its scope. Your plan should describe how incidents are reported. Sources include monitoring alerts, a staff report, a customer tip, or a vendor disclosure. The plan should also cover how incidents are triaged and validated, and how an initial severity is assigned. Accurate, early analysis lets you respond proportionately. You avoid both over-reacting to noise and under-reacting to a real breach.

Containment, eradication, and recovery is the operational core. Containment limits the damage by isolating a host, disabling a credential, or blocking an address. Do this before you wipe anything, so evidence survives. Eradication removes the root cause, such as malware, a backdoor, or the exploited vulnerability. Recovery restores systems from known-good backups. You then confirm through monitoring that the threat is genuinely gone, not just dormant.

Post-incident activity is the lessons-learned phase, and it closes the loop. Within a defined window after the incident, the team reviews what happened and how the response went. It then decides what to change: a control to add, a detection gap to fix, a runbook to update, or a training need to address. This is the step organizations most often skip. It is also 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, assign clear ownership for these jobs:

An incident commander, with the authority to make decisions and coordinate the response.
Technical investigation and containment.
Internal and external communications.
Legal and regulatory analysis.

Define how the team is activated and who can declare an incident. Keep an up-to-date contact roster, including after-hours coverage. Add an out-of-band way to reach people if your primary systems are the thing that is down.

Severity classification 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. Write plain criteria for each tier. Base them 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 outside 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. An analyst can map symptoms to a defined level. The plan already states what that level triggers. So 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. It is also 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. It defines who tells leadership, legal, and affected business units, and when. Customer and partner notification covers your contractual commitments. Contracts often specify a window, such as 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 on what data was involved and where the affected people are. The rules genuinely differ, so the plan should point to the obligations that apply to you. Do not 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. Where feasible, that is no later than 72 hours after becoming aware of it. Notification to affected individuals is also 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. 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.

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

Evidence handling and testing the plan

How you handle evidence during an incident decides what you can do later. It determines whether you can understand what happened, support an insurance claim, satisfy a regulator, or pursue legal action. So build evidence preservation into the response itself. Capture and protect relevant logs, disk and memory images, and records before containment or rebuilding destroys them. 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.

Keep a contemporaneous incident timeline as you go, because reconstructing one later 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 only a hypothesis. Testing is what turns it into a capability. It is also what auditors and regulators increasingly expect to see. The most accessible method is a tabletop exercise. Gather the response team and walk through a realistic scenario. For example: an employee reports their laptop was stolen and it held client files. Or: a vendor notifies us of a breach affecting our data. 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 of these are 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. Control 5.28 covers the collection of evidence. 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 covering how you detect, respond to, and recover from security events (the CC7 series). A service auditor will look for a documented IRP. In a Type II examination, they will also look for 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). The separate Breach Notification Rule governs what you must do when protected health information is compromised. Across all three frameworks, 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. That 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. It gives you a structured, framework-aligned draft to tailor to how your organization actually detects, escalates, and reports incidents. You start from a working document rather than 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. 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. 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, such as a login, a firewall alert, or a failed scan. 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. Examples include a confirmed account compromise or a ransomware infection. The detection and analysis phase of your plan exists to separate the two. That way 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. Revision 3 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. It also 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.
How fast do I have to report a data breach?: It depends 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. Where feasible, that is within 72 hours of becoming aware of it. Under HIPAA, affected individuals must be notified without unreasonable delay and no later than 60 days. Breaches of 500 or more individuals also require prompt notice to HHS and the media. US state laws and customer contracts add their own deadlines. 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. 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. It 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. You 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. 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. That work is only yours to do.

Related guides: ISO/IEC 27001 · SOC 2