Your organisation has an incident response plan. It's filed somewhere — maybe in SharePoint, maybe in a folder from that compliance project three years ago. It's comprehensive: 47 pages covering every conceivable scenario with detailed procedures.
There's just one problem: it won't work.
We've responded to hundreds of incidents. In nearly every case, the organisation had a plan. In most cases, that plan wasn't used — or couldn't be used — when the crisis hit. The plan was designed for auditors, not for the 2 AM phone call that changes everything.
This guide covers how to build an incident response plan that works in practice, not just on paper. It's based on what we've seen succeed (and fail) across 100+ real incidents.
Why Most Incident Response Plans Fail
Before building a better plan, understand why existing plans fail. The same patterns appear repeatedly:
Failure Mode 1: The plan is too long to use in a crisis
A 47-page document is a reference manual, not a response plan. When ransomware hits at 2 AM and the CEO is asking what's happening, nobody has time to read a novel. The plan sits unused while people improvise.
The fix: Create tiered documentation. A one-page immediate response card for the first 30 minutes. A 5-page playbook for the first 24 hours. Detailed procedures as reference material for specific scenarios.
Failure Mode 2: Contact information is outdated
The plan lists the CISO's mobile number from 2021. The external IR provider contact is for a firm you no longer use. The insurance broker changed roles. Half the escalation chain has left the company.
The fix: Quarterly contact validation as a calendar reminder. The first thing that fails in a crisis shouldn't be "who do we call."
Failure Mode 3: Roles aren't understood by role-holders
The plan assigns the CFO as "Crisis Communications Lead." The CFO has never seen this plan and has no idea what that means. When asked to execute, they freeze or delegate randomly.
The fix: Named roles need named training. If someone has responsibilities in your plan, they must know what those responsibilities are before an incident occurs.
Failure Mode 4: The plan assumes normal systems work
Step 3 says "notify team via email." Step 7 says "reference the shared drive for procedures." The ransomware has encrypted email servers and file shares. Now what?
The fix: Out-of-band communication channels established in advance. Printed hard copies of critical procedures. Plans must assume your IT environment is compromised or unavailable.
Failure Mode 5: The plan has never been tested
The plan was written for a compliance requirement. It was approved by legal and filed away. Nobody has ever walked through it. Nobody knows if the procedures actually work or how long they take.
The fix: Regular tabletop exercises that test decision-making. Technical exercises that test procedures. Annual full-scale simulations that test everything.
The Core Components of an Effective IR Plan
An effective IR plan has layers. Each layer serves a different purpose and is used at different times during an incident.
Component 1: Immediate Response Card (One Page)
This is what people actually use in the first 30 minutes. It should fit on a single laminated card and answer:
- Who do I call? (Primary and backup contacts for IR lead, external support, executive notification)
- What do I do immediately? (Isolate, preserve evidence, document)
- What do I NOT do? (Don't turn off systems, don't run AV, don't start restoring)
- Where do we communicate? (Out-of-band channel: Signal group, personal mobiles, specific conference line)
Format: Laminated card at every IT desk. Digital version on personal devices. Memorised by key personnel.
Component 2: First 24-Hour Playbook (5-10 Pages)
This guides the response team through the critical first day. It covers:
- Activation criteria: What constitutes an incident requiring this playbook?
- Role assignments: Who does what? (Incident Commander, Technical Lead, Communications Lead, etc.)
- Initial assessment: What questions need answering in the first hour?
- Escalation triggers: When do we wake up the CEO? Notify the board? Call external help?
- Communication cadence: When and how do we update stakeholders?
- External notifications: When do we notify insurers, regulators, customers?
Format: Printed copies in go-bags and at key locations. Digital copies on mobile devices (not company systems).
Component 3: Scenario-Specific Procedures (Detailed)
These are the detailed technical procedures for specific incident types. You need at minimum:
- Ransomware response: Containment, evidence preservation, negotiation decision framework, recovery
- Data breach/exfiltration: Scope assessment, notification requirements, legal coordination
- Business email compromise: Account securing, transaction review, financial recovery
- Insider threat: Evidence collection, legal coordination, HR involvement
- DDoS/availability attack: Mitigation, provider coordination, communication
Format: Digital reference documents. Updated as threats evolve. Used by technical staff during response.
Component 4: Contact Directory
A single authoritative source for all incident contacts:
- Internal escalation chain: Who to notify at each severity level
- External support: IR retainer provider, legal counsel, insurance broker
- Technology vendors: EDR support, cloud provider contacts, ISP NOC
- Regulatory bodies: ICO, sector-specific regulators
- Law enforcement: Action Fraud, NCSC, local police cybercrime unit
Format: Multiple copies — printed, mobile, personal devices. Quarterly validation required.
Component 5: Communication Templates
Pre-drafted templates for crisis communications:
- Internal notification: What to tell employees (and what not to)
- Board briefing: Executive summary format for rapid updates
- Customer notification: Templates for different breach scenarios
- Regulatory notification: ICO notification template, draft breach report
- Press holding statement: Basic statement while details are confirmed
Format: Editable documents pre-approved by legal. Ready to customise, not create from scratch.
The IR Team Structure That Works
Who responds to an incident matters as much as what they do. Define clear roles before you need them.
Core Roles
| Role | Responsibility | Typical Person | Backup Required? |
|---|---|---|---|
| Incident Commander | Overall response coordination, resource decisions, executive liaison | CISO, IT Director, or senior manager | Yes — 24/7 coverage needed |
| Technical Lead | Investigation, containment, recovery operations | Senior security engineer or IT lead | Yes — multiple shifts possible |
| Communications Lead | Internal and external communications, stakeholder updates | Comms/PR lead or senior executive | Yes — for extended incidents |
| Legal Coordinator | Legal privilege, regulatory requirements, liability management | General counsel or external breach counsel | External counsel as backup |
| Scribe | Documentation of all decisions, actions, and timelines | Any team member (rotating) | Yes — critical for evidence |
Extended Roles (for larger incidents)
- Business Continuity Lead: Manages workarounds, prioritises recovery, coordinates with business units
- External Liaison: Coordinates with insurers, external IR support, vendors
- Finance Coordinator: Tracks costs, manages emergency spending, supports insurance claims
- HR Coordinator: Employee communications, welfare, insider threat situations
Building the Decision Framework
The hardest part of incident response isn't technical — it's decision-making under pressure. Your plan should pre-answer the decisions that will otherwise cause paralysis.
Escalation Triggers
Define in advance what triggers escalation to the next level:
| Trigger | Escalate To | Timeframe |
|---|---|---|
| Confirmed malware on single endpoint | Security team lead | Within 30 minutes |
| Evidence of lateral movement | CISO / Incident Commander | Immediately |
| Ransomware encryption detected | Executive team, external IR, legal | Immediately |
| Data exfiltration confirmed | CEO, board notification prepared | Within 2 hours |
| Ransom demand received | Board, insurance broker, external negotiators | Within 1 hour |
| Personal data breach confirmed | Legal, DPO, ICO notification preparation | Immediately |
Pre-Authorisations
Some decisions shouldn't wait for approval during a crisis. Get these pre-authorised:
- Network isolation: Technical leads authorised to isolate systems without executive approval
- External support activation: IC authorised to engage IR retainer without additional approval
- Emergency spending: Define limits for IC to approve without finance sign-off
- Credential resets: Security team authorised to force enterprise-wide password resets
- Service shutdown: Define which services can be shut down and by whom
Payment Decision Framework
If ransomware involves a payment decision, the framework should be established in advance:
- Who can authorise payment? (Usually board-level decision above certain thresholds)
- What factors must be considered? (Backup availability, business impact, legal implications, sanctions status)
- Who executes the negotiation? (Almost always external specialists)
- What approval is needed from insurers? (Check policy requirements)
Read our detailed ransomware negotiation guide for more on this decision.
Communication Plans
Communication failures derail more incident responses than technical failures. Plan communications before you need them.
Internal Communication
Do
- Establish out-of-band channels (Signal group, personal mobiles)
- Define what employees should know at each stage
- Prepare holding statements for common questions
- Designate a single source of truth for updates
- Plan for communications when email is unavailable
Don't
- Use potentially compromised systems for sensitive communications
- Let multiple people send conflicting messages
- Share technical details employees don't need
- Leave employees wondering what's happening
- Assume everyone checks the same communication channel
External Communication
Different stakeholders need different information:
| Stakeholder | What They Need | When to Communicate |
|---|---|---|
| Board | Business impact, response status, key decisions needed | Within hours of significant incident |
| Cyber insurer | Notification, scope, response actions, approvals needed | Per policy requirements (usually 24-72 hours) |
| ICO | Nature of breach, data affected, actions taken | Within 72 hours of confirming personal data breach |
| Customers | What happened, what data was affected, what they should do | After scope is understood, per regulatory requirements |
| Media | Holding statement, then updates as appropriate | Reactive initially, proactive if significant breach |
Testing Your Plan
An untested plan is a hypothesis. Testing converts it into a reliable procedure.
Types of Testing
| Test Type | What It Tests | Frequency | Duration |
|---|---|---|---|
| Walkthrough | Do people understand their roles? Are documents accessible? | After any plan update | 1-2 hours |
| Tabletop exercise | Decision-making, communication, escalation | Quarterly | 2-4 hours |
| Technical drill | Specific procedures (e.g., isolation, evidence collection) | Semi-annually | Half day |
| Full simulation | End-to-end response including external parties | Annually | 1-2 days |
What to Measure
After each test, assess:
- Time to mobilise: How long from alert to assembled team?
- Decision velocity: How quickly were key decisions made?
- Communication effectiveness: Did the right people get the right information?
- Role clarity: Did everyone know what they were supposed to do?
- Resource availability: Were tools, documents, and contacts accessible?
- Gaps identified: What didn't we plan for?
Maintaining the Plan
A plan from 12 months ago is already outdated. Build maintenance into your rhythm.
Monthly
Quarterly
Annually
Common Questions
Do we need different plans for different incident types?
Yes and no. Your core plan (roles, communication, escalation) should be consistent. Scenario-specific procedures should be separate documents. Don't create completely separate plans that might conflict.
How detailed should procedures be?
Detailed enough that someone unfamiliar with the task could follow them, but not so detailed they're never updated. Assume the reader is competent but not expert.
Should we include specific tool instructions?
Reference tools by name and include version-agnostic procedures. Detailed button-click instructions belong in separate technical runbooks that are updated with tool changes.
How do we handle incidents that span scenarios?
Most real incidents span multiple scenarios (ransomware + data breach + BEC, for example). Your core plan handles coordination; specific procedures handle technical response. The IC manages the overlap.
What if key people are unavailable?
Every critical role needs a backup. Your plan should work if the CISO is on holiday, the IT Director is unreachable, and the external IR provider has a different analyst on call. Test this assumption.
Case Study: The Plan That Worked
Organisation: UK financial services firm (850 employees)
The incident: Ransomware attack detected at 11:47 PM on a Friday. Attackers had been present for 8 days. Multiple domain controllers encrypted.
Why the response worked:
- Immediate response card: On-call IT knew exactly who to call (IR retainer) and what to do (isolate, preserve, don't reboot)
- Pre-authorisations: Technical lead authorised to isolate critical systems without executive approval — contained spread within 20 minutes
- Out-of-band comms: Signal group activated within minutes, executive team briefed by midnight
- Contact list: IR retainer engaged by 12:15 AM, forensic collection started by 1:30 AM
- Tested roles: Quarterly tabletops meant everyone knew their responsibilities
- Communication templates: Board briefing sent by 8 AM using pre-approved format
Getting Started
If you're building from scratch or rebuilding a failed plan, start here:
- Create the immediate response card first. This has the highest ROI. It's what gets used when everything else fails.
- Define your core team and roles. Assign names to roles and ensure those people know their responsibilities.
- Build your contact directory. Validate every contact. Include backups for every critical contact.
- Establish out-of-band communications. Test them. Ensure everyone knows how to use them.
- Create one scenario procedure. Start with ransomware — it's the most likely severe incident. Use it as a template for others.
- Run a tabletop. Test your plan with a realistic scenario. Fix what breaks.
- Schedule maintenance. Put quarterly contact validation and annual reviews in the calendar now.
Need Help Building or Testing Your IR Plan?
Binary Response provides tabletop exercises, plan development, and IR readiness assessments. We help organisations build plans that work — because we know what fails when incidents happen.