The middle of an incident is the worst time to discover you do not have a plan. I have been the person called in after that discovery happens — when a company is 36 hours into a breach, the CEO and board are asking questions nobody can answer, engineers are running on adrenaline and tribal memory, and the legal team is asking for documentation that does not exist. That situation is preventable. What prevents it is not a sophisticated security programme — it is a single well-maintained document and the discipline to test it before you need it.
Why Playbooks Fail Before They Are Even Used
Most companies that claim to have an incident response plan have a document that was written once, approved, filed, and never opened again. I have seen "incident response plans" that reference a Slack workspace that no longer exists, list a CISO who left two years ago, and cite a third-party forensics retainer that was not renewed. That document will not help you at 2 a.m. when your monitoring fires.
The other failure mode is a plan that exists but is not understood by the people who need to execute it. Incident response is a high-stress, time-compressed activity. When people are under pressure, they do not read documents carefully — they execute muscle memory. If the playbook has never been rehearsed, you do not have muscle memory. You have a PDF.
The third failure mode is scope confusion. Who declares an incident? What threshold triggers the plan? Who calls the board, and when? I have seen companies spend four hours of an incident debating whether something was actually an incident — while the clock on regulatory notification was running.
A working playbook resolves all three failures before the incident starts.
What a Working Playbook Actually Contains
This is not about length or compliance theatre. A playbook that works is specific, role-assigned, and executable by someone who has not read it before.
Section 1: Severity tiers and declaration criteria
Before anything else, define what constitutes an incident and at what level. The taxonomy I use across engagements:
| Severity | Definition | Example | Response Timeframe |
|---|---|---|---|
| P1 — Critical | Active data exfiltration, confirmed ransomware, production systems inaccessible | Live breach of customer PII, complete service outage | Immediate — all hands, board notified within 4 hrs |
| P2 — High | Confirmed compromise without confirmed exfiltration, significant service degradation | Suspicious access patterns, partial outage | Within 2 hours — response team activated |
| P3 — Medium | Potential compromise under investigation, single non-critical system affected | Phishing credential exposure, isolated endpoint compromise | Within 8 hours — security team assessment |
| P4 — Low | Anomaly detected, no confirmed impact | Failed brute force, unusual but non-malicious access pattern | Within 24 hours — logged and monitored |
The severity tiers solve the "is this an incident" debate. Define the criteria in advance. Someone with authority is empowered to declare based on those criteria, and the declaration triggers the appropriate response.
Section 2: The first-hour checklist
The first hour of an incident determines how the rest unfolds. Decisions made in hour one — particularly around containment vs. evidence preservation, and around notification timing — are difficult to reverse. The checklist for hour one should be on one page, role-assigned, and executable without needing to read anything else.
One named person — typically the on-call security lead or CTO — reviews the trigger, applies the severity criteria, and makes a declaration. This ends the debate. The clock starts from the moment of declaration.
Role-based, not person-based. "The CISO" is wrong — what if the CISO is on a flight? "The on-call security lead (primary: [name], backup: [name])" is correct. Every role in the response has a named primary and backup. Activation is a single group message to a pre-configured incident channel.
This is where improvised responses make their biggest mistake. The instinct is to shut everything down immediately. That destroys evidence. Take memory images and full packet captures before isolation. Snapshot affected instances. Only then isolate. If you have a forensics retainer, call them now — even if you end up not needing them.
One dedicated incident channel. One person managing communications — not the technical lead. All external communication goes through counsel. No one talks to the press, posts on social media, or sends customer-facing messages without approval. This sounds obvious. In a real incident, under pressure, it is not obvious unless it is written down.
Identify which notification obligations apply. GDPR is 72 hours from awareness. NIS2 has 24-hour early warning and 72-hour notification requirements. Financial services regulations may be faster. If you process EU personal data, legal counsel needs to be in the war room from hour one. The notification window does not wait for the technical investigation to conclude.
The first-hour sequence in practice looks like this:
Section 3: Role assignments and the "backup of backup" rule
The playbook names every role explicitly. Not job titles — named individuals, with a backup, and a backup's backup. In a major incident, key people will be unavailable, sick, or unreachable. The playbook accounts for that.
The roles that must be assigned:
- Incident Commander — coordinates the overall response, makes containment and communication decisions
- Technical Lead — owns the investigation, containment, and remediation
- Communications Lead — manages all internal and external messaging, single point of contact for press and customer communication
- Legal/Regulatory Lead — advises on notification obligations, counsel and regulatory liaison
- Board/Executive Liaison — one person who briefs the CEO and board, not a rotating cast
The legal privilege question matters from hour one
Forensic reports and incident documentation can be discoverable in litigation. Work with your legal counsel before an incident to establish the appropriate engagement structure — communications between counsel and technical teams may be protected under legal privilege in ways that direct technical documentation is not. This is not an abstract concern; it has material implications for how you document your investigation.
Section 4: Regulatory notification matrix
Every company I work with that processes EU personal data needs a completed notification matrix before an incident happens. The matrix maps incident types to notification obligations, timelines, and the specific supervisory authority relevant to your operations.
| Obligation | Regulation | Timeline | Trigger | Authority |
|---|---|---|---|---|
| Supervisory authority notification | GDPR Art. 33 | 72 hrs from awareness | Personal data breach affecting rights/freedoms | Lead DPA in your EU establishment |
| Data subject notification | GDPR Art. 34 | "Without undue delay" | High risk to individuals' rights | N/A — direct to affected individuals |
| Early warning | NIS2 | 24 hrs from awareness | Significant incident affecting essential/important entity | National NIS2 authority |
| NIS2 full notification | NIS2 | 72 hrs from awareness | As above | National NIS2 authority |
| Financial regulator | Sector-specific | Often 24–72 hrs | Varies by license type | BaFin, FCA, CSSF, etc. |
Populate this matrix for your specific regulatory context. "We think we have 72 hours" is not a sufficient posture when you are actually subject to four overlapping notification regimes.
The Board Conversation You Need to Have Before the Incident
The board does not want to manage your incident. They want to know that you can manage it — and that they will not be surprised. Two things typically surprise boards during an incident: the notification (they hear about it from someone else before the CTO tells them) and the scope (the CTO initially says "contained" and then it expands).
The pre-incident conversation with the board needs to cover three things:
1. The notification protocol. The board chair (and potentially audit committee chair) gets a call at P1, not an email. They need to know this in advance so they are not offended that a junior comms person sent them a formatted brief at 3 a.m. instead of calling. Define who makes the call, what the call contains, and what decisions they are being asked to make vs. simply being informed about.
2. The board's role during an incident. The board does not run the incident. Their role is governance oversight and specific decision authority — for example, approving ransom payment decisions (if that is in scope), approving public disclosure language, or authorising significant remediation expenditure. Defining this in advance prevents boards from over-reaching during an incident and CTOs from under-communicating.
3. The exercise cadence. A playbook that is never tested is a document, not a capability. The board should be aware that the company runs tabletop exercises — ideally at least annually, preferably twice a year for organisations in high-risk sectors — and that the CTO will report findings from those exercises to the audit committee.
The tabletop exercise always finds something
Every tabletop exercise I have run — no matter how well-prepared the organisation — surfaces at least one material gap. Usually it is a communication assumption that falls apart when tested ("everyone knows to call Sarah" — except Sarah is not in the exercise and the team discovers nobody has her personal mobile). Run the exercise. Fix what it finds. Repeat.
The Retainer Decision
A meaningful part of incident response readiness is the external forensics and legal retainer question. Mid-market companies often defer this as an unnecessary expense until they need it. When they need it, they discover that the leading forensics firms are engaged 3–8 weeks out on major incidents, and the "emergency" rate for an unretained engagement is 40–60% higher than a pre-negotiated retainer.
The decision framework I use with clients:
| Company Profile | Recommendation |
|---|---|
| Processes EU personal data at any scale | Retain external forensics and a cyber-incident legal counsel now |
| Operates in financial services, healthcare, or critical infrastructure | Retain forensics with an SLA for 4-hour response — not just "we'll get to you" |
| Sub-50 employees, limited regulatory exposure | Ensure your cyber insurance policy includes incident response services from a named provider |
| Has had a previous incident | Retain forensics regardless of size. Second incidents go worse without external support. |
The retainer conversation with your board should include the cost (typically €15,000–€40,000/year for a forensics retainer, depending on scope and SLA) against the cost of improvised response. That arithmetic is not ambiguous.
What Good Looks Like After an Incident
A well-handled incident produces a post-incident review (PIR) within 72 hours of resolution — not a blame exercise, a structured analysis of what happened, why, what was done, and what changes. The PIR feeds directly into three places: the playbook (updated with what you learned), the board (a written briefing covering timeline, scope, remediation, and control improvements), and the regulatory file (documentation that demonstrates you have a functioning improvement process).
The companies that handle incidents well are not companies where nothing goes wrong. They are companies where, when something goes wrong, the response is fast, organised, and produces a measurable improvement to the control environment. That is what your board actually wants to see — not perfection, but competence and transparency.
If you do not have a tested incident response playbook, or if you have one that has not been exercised in the last 12 months, you are carrying more risk than your board thinks you are. Let's talk — book a 30-minute discovery call and I'll tell you honestly whether your current posture would hold in a real incident.