Threat Detection & ResponseJun 16, 2026 · 12 min read

How to build an incident response plan

A plan you write for the first time during an attack is worthless. Here is how to build an incident response plan, the phases it covers, and why it has to be rehearsed before you need it.
A team running an incident response planning session, sketching a response flow on a glass board.
Written by
R
Raptoric Threat Detection & Response
Share
LinkedInX / TwitterCopy link

An incident response plan is the document that defines, in advance, how an organization reacts to a security incident: who decides, who is notified, how the attack is contained, and how systems are restored. The worst time to write that plan is during an attack. A prepared and rehearsed plan is the difference between a controlled response and the chaos that multiplies the damage. This post explains how to build the plan, the phases it covers, and why it has to be exercised regularly.

This is part of our detection and response overview. We build response capability through threat detection and response.

Why the plan must exist in advance

During an incident, time is critical and stress is high. If that is when you decide who is in charge and who to call, you lose precious hours. Regulations also demand fast reporting: GDPR requires notifying a personal data breach within 72 hours, and NIS2 requires reporting a significant incident in staged windows starting at 24 hours. You cannot meet those deadlines by improvising.

The phases of incident response

A good plan follows recognizable phases, aligned with established frameworks.1

  1. 01
    Preparation
    Define roles, contacts, tools, and procedures before an incident, and rehearse them.
  2. 02
    Detection and analysis
    Identify the incident, assess its scope, and classify severity.
  3. 03
    Containment
    Stop the spread by isolating affected systems, without destroying evidence.
  4. 04
    Eradication
    Remove the cause, close the entry point, and confirm the attacker is truly out.
  5. 05
    Recovery
    Restore systems from verified backups and watch for recurrence.
  6. 06
    Lessons learned
    Run a post-incident review and close the gap so it does not happen again.

What the plan must contain

A plan is only useful if it is concrete and easy to apply under pressure.

  • Clearly defined roles and responsibilities, including who makes the key decisions.
  • A contact list, including management, legal, the external team, and the relevant authorities.
  • Criteria for classifying an incident and the threshold for reporting.
  • Steps for isolation, recovery, and communication.
  • Reporting procedures to the regulator and authorities within the required windows.
  • A communication plan for employees, customers, and the public.

Rehearsing the plan

A plan nobody has tested almost certainly does not work the way it is expected to. That is why tabletop exercises matter: the team walks through a realistic scenario and finds the gaps before a real attack does. The exercise is worth repeating at least annually and after major changes.

How Raptoric helps

We help companies build and rehearse a response plan that fits regulatory deadlines, through threat detection and response. Book a scoping call.

Frequently asked questions

Why do we need an incident response plan in advance?
Because there is no time to improvise during an incident, and regulations demand fast reporting: GDPR within 72 hours, NIS2 from 24 hours. A plan prepared in advance is the difference between a controlled response and chaos that multiplies the damage.
What phases does incident response cover?
Preparation, detection and analysis, containment, eradication, recovery, and lessons learned. These phases align with established frameworks and form a repeatable process rather than improvisation.
Do we need to rehearse the plan?
Yes. A plan nobody has tested almost certainly does not work the way you think. Tabletop exercises surface gaps before a real attack, and they are worth repeating at least annually.
How does the plan relate to NIS2 and GDPR?
Both require reporting incidents within tight windows. The plan defines who reports, how, and when, so it is a precondition for meeting those deadlines and demonstrating diligence to a regulator.

Sources

  1. 1NIST. SP 800-61: Computer Security Incident Handling Guide. National Institute of Standards and Technology, 2012. Link
  2. 2ENISA. ENISA Threat Landscape. European Union Agency for Cybersecurity, 2024. Link
Want this tested on your own systems?
Our team will scope it with you on a 30-minute call.
Book a scoping call