NIST spent thirteen years pointing incident responders at the same publication, then withdrew it in April 2025 and put revision 3 of SP 800-61 in its place. Much of the Spanish-language guidance still teaches the retired document's lifecycle, complete with the arrow diagram. Draft an incident response plan from that diagram today and you are building on a reference its own author has set aside.
The plan has also stopped being a purely technical artefact: NIS2, DORA, Spain's ENS and the GDPR have strapped deadlines to it, with mandatory notifications that start counting at four hours. Caseloads keep rising meanwhile: Spain's INCIBE handled 122,223 incidents in 2025, its highest figure ever and 26% up on 2024, with SMEs and the self-employed behind six in ten cases.
Below, regulation by regulation, is what that document needs to have decided before the first alert sounds.
What an incident response plan is, and what it is not
An incident response plan settles ahead of time who decides, who carries out what was decided and whose job it is to communicate, in that order, for the day the organisation suffers a cyber incident. It exists to remove improvisation. The decisions that would eat hours of mid-crisis meetings are already made, written down and signed off.
It often gets mixed up with the documents around it. Business continuity keeps the company trading while the incident lasts, which is a different job. Crisis communication, which we covered in our piece on the first 24 hours of communication, has a plan of its own, and the response plan should be what triggers it. A stack of loose playbooks falls short too, because each playbook goes deep on the technical detail of one scenario, while the plan sets owners and timings across the set.
The regulatory clocks: who makes you notify, and when
Here the plan moves from recommendation to obligation with a fine behind it. For a private company in Spain, these are the deadlines now in force:
- NIS2 (Article 23), for essential and important entities: an early warning within 24 hours of becoming aware of a significant incident, a full notification within 72 hours and a final report within a month.
- DORA, for financial entities: an initial notification within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it; an intermediate report 72 hours on from the initial notification and a final one within a month, under Implementing Regulation (EU) 2025/302 and the Bank of Spain's process guide.
- The ENS (Royal Decree 311/2022), for Spain's public sector and its suppliers: incidents with significant impact are reported to the CCN-CERT through the LUCIA platform, using the CCN-STIC 817 taxonomy.
- GDPR (Article 33): 72 hours to the data protection authority when personal data is affected, plus a duty to inform the individuals concerned when the risk to them is high.
- The Cyber Resilience Act, for manufacturers of products with digital elements: 24 hours for the first alert on an exploited vulnerability, as we covered in our analysis of the CRA's fast-track reporting.
Several of those deadlines can fire at once. Ransomware with data theft at a financial entity triggers DORA and the GDPR together, plus NIS2 where essential infrastructure is involved: a single incident with three regulators waiting, each holding its own form and its own countdown. That is why the plan must record in writing who covers each window, in a notification matrix agreed in advance; sorting it out live means putting the systems people onto paperwork instead of containment.
At Hard2bit we work the technical and the regulatory front together: our NIS2 and DORA readiness services include exactly that notification matrix and its fit inside the response plan.
The reference model has changed: from a phase cycle to risk
From 2012 onwards, revision 2 of SP 800-61 arranged response as a cycle: preparation; detection and analysis; containment, eradication and recovery; lessons learned. The scheme sits in thousands of plans, decks and syllabuses, and as a description of a single incident it works.
Revision 3 leaves that cycle behind and rests response on the six functions of CSF 2.0, NIST's own cybersecurity framework: govern, identify, protect, detect, respond and recover. As a result, preparation becomes permanent governance rather than a chapter written once, and what each incident teaches has to reach organisation-wide risk management instead of dying in the minutes of the follow-up meeting.
Put another way, a PDF of phases that sleeps between incidents belongs to the retired model. What is expected now is a living process, with an owner, dated reviews and a working connection to the risk assessment.
What a working plan contains
Plans tend to carry too much paper and too little precision: the necessary pieces are few. These are the ones to close in advance:
- The scope and the definition of an incident: what triggers the plan and what stays a fault or a dismissed alert.
- Roles with names, deputies and phone numbers held outside the corporate directory: incident lead, executive decision-maker, technical lead, legal and communications.
- Classification criteria by severity and impact, such as those in Spain's CCN-STIC 817 guide, so that the word 'critical' means the same at three in the afternoon and three in the morning.
- The notification matrix: which authority, which deadline, which channel and who fills in the form, regulation by regulation.
- Playbooks for the scenarios your business is actually likely to face: ransomware, email compromise, data theft, a breached supplier.
- Evidence preservation rules that apply before anything is restored, so that digital forensics remains possible and the evidence stands up in court or satisfies an insurer, together with the escalation points for the response provider, the insurer and law enforcement.
Format counts as well. Keep the reference copy outside the corporate domain, somewhere that stays reachable with the systems down. And keep it to twenty or twenty-five pages, because sixty will not get read while production is stopped.
How do you test a plan without waiting for an incident to strike?
Until it is tested, a plan is a hypothesis. The bare minimum is one tabletop a year: two hours, a believable scenario, and in the room the people who would decide if it came to it, senior management included. The gaps come out of that: the deputy who left, the supplier contract that lapsed, the notification deadline each person believed someone else was watching.
One step up sits the technical drill: restore a full backup, isolate a network segment, and time the gap between the first alert and the first executive decision. Time to decide and time to notify: those two measurements portray the plan better than most paper audits.
That leaves the question of who picks up the phone. With no internal on-call rota, the capacity gets bought ahead of time. Under an incident response retainer with agreed activation times, the forensics and response (DFIR) team arrives already knowing your network, instead of discovering it mid-crisis.
The failures we keep finding in other people's plans
At Hard2bit we have been at this since 2013, responding to incidents and reviewing plans, and the same failures keep coming round. Top of the list is the template downloaded as-is, with roles the organisation does not have. Stale contacts come next: verifying the list takes two minutes, and even so it is the first thing to fail in most of the plans that cross our desk past the one-year mark.
There is also the plan stored solely on the file server the ransomware will end up encrypting. And whether a ransom would be paid has almost never been discussed with management before it must be decided with the company at a standstill.
Another failure makes less noise: depending on one person. When the whole response lives in the head of the systems manager, what the organisation owns is not a plan; it is an employee with no right to a holiday. Writing down the deputies and drilling without the lead removes that single point of failure at minimal cost.
Where to start
Starting from zero, a sensible order is to pin down what counts as an incident for your business, name the five roles with their deputies, assemble the notification matrix that applies to you and write the two likeliest playbooks. That is enough to convene the first tabletop, and the rest of the plan will come out of what it uncovers. And if you would rather have that first exercise designed by people who have managed this kind of crisis, our incident response team will prepare and test it with you.
This article is informative and reflects the regulatory framework and technical references in force on 26 August 2026: NIST SP 800-61r3, the NIS2 Directive, DORA with its implementing rules, Spain's Royal Decree 311/2022 (ENS) and the GDPR. Deadlines and obligations may vary by sector, size and the applicable national transposition; check your own case with specialist advice before taking compliance decisions.
