The Plan That Was Never Tested
Everyone has an incident response plan. It sits in a shared document somewhere, perhaps last updated during last year’s audit. It contains flowcharts, role descriptions and contact lists. On paper, it looks complete.
Then something happens. At 03:14 on a Friday night, the monitoring system triggers an alert. Ransomware is spreading through the network. And suddenly the organisation faces questions the plan never answered: Who makes the decision to shut down production systems? Who calls the board chair? Who speaks to the media? Where are the offsite backups — and do they work?
Reality Check: Organisations with a tested and practiced incident plan save an average of £2.3M per incident compared to those that don’t practice. The difference isn’t about having a plan — it’s about the plan working under pressure.
Four Components of Preparedness That Works
An effective incident response plan isn’t about having a perfect document. It’s about everyone involved knowing what to do without needing to read the document during an ongoing crisis.
Who is contacted for which type of incident? Who decides to escalate from IT incident to business crisis? Define clear thresholds: at X contact CISO, at Y contact CEO, at Z activate crisis team. No vague formulations — concrete names and numbers.
Incident commander, technical lead, communications lead, legal contact, external authority liaison. Each role needs a primary person and a backup. Roles should be assigned based on competence and availability — not organisational position.
During a crisis there's no time to write messages from scratch. Prepare templates for internal communication to staff, external communication to customers, authority reporting to national competent authorities/CSIRT, and media statements. Adapt the details during the incident — not the structure.
How do you isolate affected systems quickly without bringing down the entire business? Which network segments can be shut off? Where are the kill switches? Have you prepared segmentation strategies that can be activated manually if automation fails?
Practice: The Step Everyone Skips
Most organisations stop at documentation. The plan is written, approved by management and archived. Practice? “There’s no time for it.” “It’s too complicated to organise.” “We know what to do anyway.”
No, you don’t. Not under stress, not in the middle of the night, not when systems are burning and the phone is ringing constantly.
Tabletop Exercises: Start Here
A tabletop exercise requires no technology. Gather the team, present a scenario, and discuss step by step: what do we do first? Who do we contact? What information do we need? Where do we find it?
Example Tabletop Scenario:
It’s Friday at 16:30. A staff member reports they cannot access the file server. IT investigates and finds encrypted files with a ransom message. The encryption is actively spreading. You have 24 hours to report to national authorities.
Discuss:
- What decisions are made in the first 15 minutes?
- Who is informed and in what order?
- How do you communicate internally if the email system is affected?
- Which systems can you shut down, and which must continue running?
- Who writes the report to authorities — and what should it contain?
Tabletop exercises reveal gaps that no document analysis can find: that the contact list is outdated, that the backup manager left three months ago, that nobody knows who has the root password to the production server.
Full-Scale Exercises: Next Level
When tabletop exercises work well, expand to full-scale simulations where you actually activate your processes. This tests not just decision-making but also technical capacity: does backup restoration work? Can communication channels handle the load? Can you actually isolate network segments as planned?
Common Mistakes in Incident Preparedness
- The plan is too complicated A 50-page incident response plan that nobody has read through won't be used during a crisis. Make it short, concrete and action-oriented. Detailed procedures can exist as appendices — but the core plan should fit on two pages.
- Unclear mandates If the incident commander doesn't have authority to make critical decisions — shut down systems, escalate to CEO, engage external help — decision-making will get stuck. Mandates should be documented and approved by management in advance.
- No Plan B for communication If email, Slack and the internal network are affected by the incident — how do you communicate? Prepare alternative communication channels: mobile phones with pre-loaded contact lists, an external chat service, or even physical meeting points.
- Never practiced authority reporting The 24-hour deadline under NIS2 starts ticking at discovery. Do you have forms prepared? Does the reporting lead know what information national authorities require in the early warning? Practice the administrative part too.
The Connection to NIS2 Reporting Requirements
Incident preparedness and incident reporting are connected but not the same thing. Preparedness is about handling the incident operationally. Reporting is about fulfilling legal requirements towards authorities.
You can’t build the reporting process while the incident is ongoing. Templates, contact details for national competent authorities/CSIRT and a designated reporting lead should be in place before the incident occurs. See our guide on incident reporting timelines for exact time requirements.
Start with What Matters Most
You don’t need a perfect plan. You need a plan that works. Start with a tabletop exercise based on your most likely scenario. This will reveal your most important gaps and give you concrete improvement actions.
Securapilot’s incident response module helps you document, practice and follow up on your incident preparedness — with ready-made templates adapted to NIS2 reporting requirements.
Frequently asked questions
What's the difference between incident response and incident reporting?
Incident response is the entire process — detecting, analysing, containing, remedying and learning from an incident. Incident reporting is the specific obligation to notify authorities (national competent authorities/CSIRT) within the timeframes that NIS2 requires.
How often should incident exercises be conducted?
Tabletop exercises should be conducted at least bi-annually. Full-scale exercises at least annually. Each exercise should be followed by an evaluation and plan update based on lessons learned.
What is a tabletop exercise?
A tabletop exercise is a discussion-based exercise where the team works through a fictional incident scenario step by step. No technology needs to be activated — focus is on testing decision-making, communication and collaboration.
Do we need a SOC to handle incidents?
Not necessarily. What's most important is that you have defined roles, documented processes and practiced procedures. How you organise capacity — internal, outsourced or hybrid — depends on your size and maturity.
