How to build an incident response plan

An incident response plan is the document that defines, in advance, how an organization reacts when a security incident hits: who decides, who is notified, how the attack is contained, and how systems are restored. It exists for one reason. During a live breach, time is short and stress is high, and that is the worst possible moment to decide who is in charge, which lawyer to call, or whether you are even allowed to pull a server offline. The plan moves all of those decisions to a calm room, weeks or months before the attack, so the people responding can execute instead of improvise.

For a regulated company the stakes are higher than downtime. A bank under DORA, a hospital or energy operator under NIS2, and any company processing personal data under GDPR all face legal reporting deadlines that start counting from the moment an incident is detected. A response plan is not a nice-to-have governance artifact. It is the operational machinery that lets you contain the damage and meet those deadlines at the same time, while you are also fielding calls from customers, executives, and possibly the press. This guide explains how to build the plan, the phases it covers, the team it needs, the reporting clocks it has to beat, and why a plan that lives only on paper fails the day you need it.

This guide is part of our detection and response work. We build and rehearse response capability through incident response.

Why the plan is built before the attack, not during it

Every incident creates the same pressure. Systems are behaving strangely, alerts are firing, and nobody is sure yet whether this is ransomware, a misconfiguration, or a false alarm. If that is the moment you start asking who has authority to isolate a production system, which outside firm to call, and whether legal needs to be in the room, you have already lost hours. Attackers move fast. Ransomware operators often go from initial access to encryption in under a day, sometimes in a few hours.

A prepared plan removes that hesitation. The roles are assigned, the contacts are current, the decision thresholds are written down, and the team has walked the scenario before. Containment starts in minutes instead of after a chain of phone calls. This is also where most damage is either avoided or multiplied. An unprepared team often makes the situation worse by wiping infected machines that held the only evidence, or by rebooting systems and tipping off the attacker that they have been spotted. The plan exists to make the right move automatic when thinking clearly is hardest.

The plan does not make the incident smaller. It makes your response faster than the attacker.

The six NIST phases as a process

A credible incident response plan follows recognizable phases. The most widely used model comes from NIST SP 800-61, the Computer Security Incident Handling Guide, which a large share of frameworks and regulators map back to.¹ The phases are not bureaucracy. Each one answers a specific question the team will face in order, and skipping any of them is how incidents drag on or recur.

1. 01
   Preparation

   Define roles, contacts, tools, runbooks, and decision authority before anything happens, then rehearse them. This is the phase that decides whether the other five work.
2. 02
   Detection and analysis

   Identify that an incident is real, scope what is affected, and classify its severity. This is where your detection capability, often a SOC or MDR service, feeds the plan.
3. 03
   Containment

   Stop the spread by isolating affected systems and accounts, without destroying the forensic evidence you will need later.
4. 04
   Eradication

   Remove the root cause, close the entry point, revoke compromised credentials, and confirm the attacker is genuinely out and not dormant.
5. 05
   Recovery

   Restore systems from verified clean backups, bring services back in a controlled order, and monitor closely for signs the attacker returns.
6. 06
   Lessons learned

   Run a post-incident review within days while memory is fresh, fix the gaps that let it happen, and feed the findings back into preparation.

Detection and analysis is the phase most companies underestimate. You cannot respond to what you cannot see, which is why the plan depends on a working detection layer underneath it. For most regulated companies that means a security operations center or an outsourced managed detection and response service that watches around the clock and escalates real incidents to the response team.

The team and the roles

An incident is not handled by IT alone. The single most common structural failure is treating a breach as a technical problem when it is also a legal, regulatory, and communications problem within the first hours. A real plan names the roles in advance and the specific people who fill them, with named backups, because the primary person is often on holiday or unreachable when it matters.

• The incident lead owns the response, makes the call on containment and escalation, and is the single point of authority so the team does not fragment under pressure.
• The technical responders investigate, contain, eradicate, and recover the affected systems, and they preserve evidence as they go.
• Legal counsel decides what must be reported, to whom, and by when, and manages privilege, contracts, and liability exposure.
• Communications handles messaging to employees, customers, regulators, and where needed the public, so a chaotic internal response does not become a public one.
• Management and the executive sponsor approve major decisions such as paying or refusing a ransom, taking systems offline, or disclosing publicly, and they own the business risk.

For companies without a 24/7 internal team, these roles are often filled through an external incident response retainer. The point is the same: every role has a name attached before the incident, and everyone knows who they answer to during it.

Regulatory reporting deadlines and why they break unprepared teams

Reporting clocks are where unprepared organizations fail most visibly, because the deadline is fixed and starts the moment you become aware of the incident. You are expected to file an accurate report while the incident is still active and the facts are incomplete. That is only survivable if the reporting workflow, the templates, and the named contacts at the authority are already in the plan.²

The pattern is the same across all three. The first deadline lands within hours, long before you have the full picture, and it demands an initial notification rather than a complete forensic account. A prepared team treats the early warning as a known step with a ready template and a known recipient. An unprepared team spends those hours arguing about whether the threshold is even met, and misses the window. Missing the deadline turns a security incident into a compliance failure on top of it. If you are scoping NIS2 specifically, our NIS2 explained guide and the NIS2 compliance page break down the obligations in detail.

Runbooks and classification

A plan that says contain the incident is useless under pressure. What the team needs is a set of runbooks: specific, step-by-step procedures for the incident types you are most likely to face, written so a tired responder can follow them at 3am. A ransomware runbook looks nothing like a business email compromise runbook or a data exfiltration runbook, and trying to handle all three with one generic checklist is how steps get missed.

Classification is the trigger that selects the runbook and the reporting path. Before the incident, you define severity tiers and the criteria that put an event in each tier, for example the systems affected, whether personal data is involved, and the business impact. Classification is what tells you in minutes whether this is a low-severity event the on-call engineer closes alone, or a major incident that wakes the executive sponsor and starts the regulatory clock. Our ransomware guide walks through one of the most common high-severity scenarios a runbook has to cover.

Tabletop exercises and why they matter

A plan nobody has tested almost certainly does not work the way you expect. Documents written in calm conditions hide assumptions that only surface under stress: the contact list is six months out of date, the backup admin left the company, the legal lead has never seen the reporting template, and nobody is sure who actually has authority to take payment systems offline. You want to discover those gaps in a meeting room, not during a real breach.

A tabletop exercise is that meeting room. The team walks through a realistic scenario, makes the decisions they would make for real, and the facilitator injects complications. Within an hour or two you find the broken links in the plan. The exercise is worth running at least annually, after major changes to your systems or team, and ideally as a regular cadence. In our experience the first tabletop a company runs always exposes problems they were certain were handled, though the exact findings depend on how mature the program already is.

Preparedness and retainers

Building a plan is the start, not the finish. Real preparedness means the plan is current, the team is rehearsed, the detection layer underneath it works, and you know who you call when the incident exceeds your internal capacity. Most regulated companies cannot staff a full forensic and response capability in-house, so they pair their internal plan with an external incident response retainer. A retainer secures a defined response team, agreed response times, and people who already know your environment before the day you need them.

The alternative, finding and onboarding an incident response firm while the breach is live, costs days you do not have and negotiating leverage you will not get. Preparedness is what turns the plan from a document into a capability you can actually invoke.

How Raptoric helps

We help regulated companies build, rehearse, and retain an incident response capability that fits their NIS2, DORA, and GDPR deadlines, through incident response. That includes writing runbooks, defining roles and classification, running tabletop exercises, and standing behind it with a response retainer. Book a scoping call.