Incident response plans: What most companies get wrong
Key Takeaways
- An incident response plan filed in a SharePoint folder is a statement of intent, not a response capability — tabletop exercises at least twice a year are required for genuine readiness
- Unclear roles and responsibilities are the most common cause of delays during an actual incident — who decides, who communicates, who coordinates must be defined in advance and in writing
- Communication is consistently neglected: templates for internal and external messaging, plus defined escalation paths, must be part of the plan
- A severity model with three to four levels provides the basis for proportionate decisions — not every incident warrants a full crisis response
- Lessons learned without a binding implementation process are wasted: a responsible person, a timeframe, and follow-up tracking are required
Having an incident response plan and having an effective incident response plan are two fundamentally different things. Most organisations we advise possess a document labelled as a response plan. In practice, when a real incident occurs, that document frequently proves inadequate.
This is rarely due to a lack of intent. It is due to systematic mistakes that can be avoided.
Mistake 1: The plan is a document, not a process
An incident response plan that is written once and then filed in a SharePoint folder is not a plan. It is a statement of intent. Effective response capability comes from regular practice, clear role assignments, and processes that function under pressure.
In concrete terms: tabletop exercises should be conducted at least twice a year, during which the involved teams work through a simulated incident. Not as a compliance exercise, but as serious training that reveals weaknesses in the process.
Mistake 2: Roles and responsibilities are unclear
Who decides whether a security incident has occurred? Who informs senior management? Who coordinates the technical analysis? Who handles external communication?
In many organisations, these questions are not clearly answered. This leads to delays, duplicated effort, and communication breakdowns during an actual incident. An effective plan defines clear responsibilities for each phase of the incident — and names deputies.
Mistake 3: Communication is neglected
The technical response to a security incident is only part of the task. At least equally important is communication: internally to employees and leadership, externally to customers, partners, regulators, and potentially the public.
Many plans contain no communication templates, no defined escalation paths, and no coordination with the legal department. This becomes problematic when messages must be drafted under time pressure.
Mistake 4: No defined severity model
Not every incident requires the same response. A phishing attempt that was detected and blocked is not a crisis. A compromised administrator account is. Without a clear severity model, there is no basis for proportionate decisions.
A pragmatic model distinguishes three to four levels, defining for each level the expected response time, the people to be informed, and the required actions.
Mistake 5: Lessons learned are not implemented
After an incident, most organisations conduct a review. The results are documented, distributed — and then nothing happens. The identified improvements are not implemented because day-to-day operations take priority.
An effective plan includes a binding process for implementing findings. This requires a responsible person, a timeframe, and follow-up tracking.
The pragmatic approach
A good incident response plan does not need to be a hundred pages long. It needs to be clear, current, and practised. The essential elements: a defined severity model, clear roles with deputies, communication templates, escalation paths, and a binding exercise schedule.
If you would like to review your existing plan or build a new one, we are happy to assist.
Frequently Asked Questions
How long should an incident response plan be?
An effective plan does not need to be a hundred pages. It needs to be clear, current, and practised. Core elements include: severity model, roles with deputies, communication templates, escalation paths, and exercise schedule. Ten to twenty pages is sufficient for most mid-sized organisations. Clarity and usability under pressure matter more than comprehensiveness.
What is a tabletop exercise and how does it work?
A tabletop exercise is a facilitated walkthrough of a simulated security incident — without real system actions, but with real decision-making. A moderator presents a scenario (e.g. ransomware attack discovered at 7pm on a Friday), and participants discuss what they would do at each step. This exposes gaps in processes, role clarity, and communication paths before a real incident makes them costly.
Who must be notified when a security incident occurs?
This depends on severity. Internally: IT leadership, senior management, data protection officer. Externally: if personal data is involved, potentially the data protection supervisory authority under GDPR (within 72 hours); if subject to NIS2, the relevant national authority; and customers or partners if their data or systems are affected. The plan must define these escalation paths in advance.
What is the difference between a security event and a security incident?
A security event is any observable occurrence that may be security-relevant — a failed login attempt, an alert in the SIEM. A security incident is an event that has or could have a negative impact on the organisation. The severity model defines the threshold at which an event is classified as an incident and what response that classification triggers.