At 2:17 AM on a Tuesday, a SOC analyst at a major logistics company received an alert: unusual PowerShell execution on a finance server. By the time the on-call responder woke up and logged in, it was 3:04 AM. By 3:30 AM, when they started trying to figure out who to call and what to do, ransomware had encrypted 40,000 files across six servers.
The company had an incident response plan — a 47-page document last updated in 2021 that nobody had tested, and that nobody in the 2 AM team had ever read.
The IBM Cost of a Data Breach Report 2025 found that organisations with a tested incident response plan contained breaches 54 days faster than those without one, and spent $1.49 million less per incident. The gap is not about having a plan — it is about having the right plan, with the right structure, that the right people know how to execute under pressure at 2 AM.
This guide gives you the complete incident response plan framework aligned to NIST SP 800-61r3: the six phases, the team structure and RACI matrix, three complete playbooks for ransomware, phishing, and data breach, the severity classification system, and every checklist and template you need to make this operational — not just a document that sits on a shelf.
- What is an incident response plan?
- Incident response team — roles, RACI, and contacts
- Incident severity classification
- Phase 1 — Preparation
- Phase 2 — Detection and analysis
- Phase 3 — Containment
- Phase 4 — Eradication
- Phase 5 — Recovery
- Phase 6 — Post-incident activity
- Playbook — Ransomware attack
- Playbook — Phishing and BEC
- Playbook — Data breach
- Communication templates
- Frequently asked questions
An incident response plan (IRP) is a documented, tested set of procedures that defines how an organisation detects, responds to, contains, and recovers from cybersecurity incidents. It specifies who does what, in what order, with what authority, and using what tools — removing the need for improvisation under the pressure of an active attack.
The NIST Computer Security Incident Handling Guide (SP 800-61r3) defines the four-phase lifecycle most organisations expand into six operational phases: Preparation, Detection and Analysis, Containment, Eradication, Recovery, and Post-Incident Activity. This guide follows that structure.
Incident Response Plan: The strategic document. Defines the overall programme — team structure, roles, escalation paths, severity levels, communication policies, and legal/compliance obligations. Read once, referenced occasionally. This is what executives and auditors review.
Incident Response Playbook: The tactical procedure. A step-by-step checklist for a specific incident type (ransomware playbook, phishing playbook, insider threat playbook). What the analyst actually follows at 2 AM. Should be short enough to be used under stress — maximum two pages per playbook.
Every incident response failure traces back to the same root cause: at the critical moment, nobody was sure who was supposed to do what. The RACI matrix (Responsible, Accountable, Consulted, Informed) removes this ambiguity by assigning every response activity to specific roles before any incident occurs.
Owns the incident from declaration to closure. Makes all critical decisions including whether to take systems offline, when to notify customers, and when to engage law enforcement. Reports directly to the CISO or executive team. Does not do technical work during an incident — manages the team, coordinates communications, and makes risk decisions. In smaller organisations, the CISO fills this role.
Technical lead for the response. Directs the hands-on analysis, containment, and eradication work. Owns the technical investigation and interfaces between the IRM and the hands-on team. Must be available on-call 24/7 during active incidents or have a documented escalation chain to a backup.
Tier 1 and Tier 2 SOC analysts performing hands-on detection, triage, and initial response actions. Operate SIEM, EDR, and network monitoring platforms. Escalate to the Lead Analyst when thresholds are met. In organisations without a dedicated SOC, these functions fall to IT security engineers.
Performs deep technical investigation — memory forensics, disk imaging, log analysis, malware reverse engineering. Engaged for Critical and High severity incidents. May be an internal role or an external retainer (many organisations keep an external IR firm on retainer for P1 incidents). Responsible for maintaining evidence integrity for potential legal proceedings.
Owns the systems and infrastructure being affected. Executes technical containment and recovery actions on direction from the Lead Analyst — isolates machines, restores from backup, patches systems. Has administrative access that security analysts may not have. Critical liaison between security and IT.
Advises on breach notification obligations, evidence preservation requirements, and communications that might create legal liability. Must be consulted before any external communication (customer notification, regulatory notification, press statement). IR communications should always be reviewed by legal before sending.
Manages all external and internal communications during a breach. Owns customer notifications, press statements, and internal staff updates. Works closely with Legal. No external communication about a security incident goes out without sign-off from both Communications and Legal.
Informed for all Critical incidents. Makes decisions that exceed the IRM's authority — paying a ransom, notifying regulators, going public. Must be reachable 24/7 for P1 incidents. Their contact details must be in the IR plan and accessible offline.
| Activity | IR Manager | Lead Analyst | SOC Team | IT Ops | Legal | Comms | Executive |
|---|---|---|---|---|---|---|---|
| Incident detection and initial alert | I | C | R A | I | — | — | — |
| Incident severity classification | A | R | C | I | — | — | I (P1) |
| Incident declaration (formal) | R A | C | I | I | C | I | I (P1) |
| Technical containment actions | I | A | R | R | — | — | — |
| System isolation decision | A | R | C | R | C | — | I (P1) |
| Evidence collection and chain of custody | I | A | R | C | C | — | — |
| Customer / regulatory notification | C | I | — | — | A | R | A |
| Law enforcement engagement | R | C | — | — | A | I | A |
| Malware removal and eradication | I | A | R | R | — | — | — |
| System restoration and recovery | I | C | C | R A | — | — | — |
| Lessons learned meeting | R A | R | R | R | C | C | I |
| IR plan update | A | R | C | C | C | — | I |
R = Responsible (does the work) A = Accountable (owns the outcome) C = Consulted I = Informed
Severity classification determines the response tempo, escalation path, and resources allocated. Every incident must be classified within the first 30 minutes of triage. Classification is the Lead Analyst's responsibility, approved by the IR Manager.
An incident's severity must be re-evaluated and upgraded if any of the following are confirmed during investigation:
- Evidence of data exfiltration or confirmed access to regulated data (PII, PCI, PHI, IP)
- Spread to additional systems beyond the initially identified host
- Compromise of any privileged or administrative account
- Evidence of persistence mechanism established on any system
- Business operation disruption affecting customers or revenue
- Evidence of a second attacker or second intrusion vector discovered
- Involvement of a system in scope for PCI-DSS, HIPAA, or other regulated frameworks
- SIEM deployed and receiving logs from all critical systems (servers, endpoints, network, cloud, identity)
- EDR deployed on 100% of managed endpoints — coverage verified monthly
- Network monitoring and packet capture capability for critical segments
- Out-of-band communication channel operational (Signal group, secondary email domain, phone tree) for use if primary systems are compromised
- Forensic workstation ready with imaging tools (FTK Imager, Autopsy, Volatility) and write blockers
- Isolated recovery environment — clean network segment for restoring compromised systems without re-exposing them
- Backup systems tested within last 30 days — restoration procedure verified, not just backup success
- Asset inventory current — all hosts, owners, criticality tiers, and data classification
- Network diagrams current — segmentation, connectivity, and egress points documented
- SIEM correlation rules tuned with low false positive rate — alert fatigue documented and addressed
- IR plan documented, version-controlled, and reviewed within last 12 months
- Playbooks written for top 5 incident types specific to your organisation
- Contact list compiled with personal mobiles — verified accessible offline (printed copy)
- Escalation matrix defined — who to call at P1, P2, P3, and P4 severity levels
- Legal retainer in place for breach notification advice — counsel knows your environment
- External IR firm retainer in place (optional but strongly recommended for P1 incidents)
- Cyber insurance policy reviewed — coverage, notification requirements, and approved vendors documented
- Regulatory notification obligations mapped by data type and jurisdiction
- Evidence handling procedure documented — chain of custody forms printed
- Data retention policy for IR evidence defined (minimum 12 months recommended)
- All IR team members have completed IR fundamentals training within last 12 months
- Tabletop exercise conducted at least annually — ransomware scenario minimum
- Purple team exercise (red team attack + blue team response) conducted annually for mature teams
- New SOC analyst onboarding includes hands-on IR simulation before first on-call shift
- Non-technical stakeholders (Legal, Communications, HR) included in at least one tabletop per year
| Detection source | Incident types detected | Response time target |
|---|---|---|
| SIEM alert | Lateral movement, credential attacks, exfiltration, C2, anomalous behaviour | Triage within 15 minutes of alert generation |
| EDR alert (Critical/High) | Malware execution, fileless attack, privilege escalation, process injection | Immediate — EDR critical alerts page on-call analyst |
| User report | Phishing, ransomware note, unusual system behaviour | Acknowledge within 30 minutes, triage within 1 hour |
| Third-party notification | Breach of partner/supplier, threat intel on your IOCs | Acknowledge immediately, triage within 4 hours |
| External researcher / bug bounty | Vulnerability disclosure, exposed data | Acknowledge within 24 hours, triage within 48 hours |
| Regulatory notification | Breach affecting shared customers, legal action | Immediate legal consultation, response within 24 hours |
| Law enforcement | Criminal investigation involving your systems or data | Immediate legal consultation before any response |
- Verify the alert is not a false positive — check 2+ independent data sources (SIEM + EDR, or SIEM + network logs)
- Identify the initial affected system(s) and user account(s)
- Determine the attack vector — how did the attacker gain initial access?
- Scope the affected environment — which systems, accounts, and data are involved?
- Identify the likely attack stage using MITRE ATT&CK — initial access, execution, persistence, lateral movement, exfiltration?
- Classify severity (P1–P4) and document justification
- Open the incident ticket / case in SIEM or IR case management system
- Notify appropriate team members per the escalation matrix for the classified severity
- Begin documentation — every action, finding, and decision must be timestamped and logged from this point forward
- Preserve volatile evidence before taking any containment action that might destroy it (memory dump if malware is active in memory)
- Capture memory dump of affected systems before isolation (volatile evidence lost on reboot or shutdown)
- Capture full disk image of affected systems for forensic investigation
- Isolate affected systems via EDR network isolation — do NOT simply unplug network cable (EDR isolation preserves management channel and avoids evidence destruction)
- Block attacker-controlled IPs and domains at the perimeter firewall and DNS layer
- Disable compromised user accounts — do not just change passwords if credential harvesting may have occurred
- Revoke active sessions for compromised accounts in identity platform (Entra ID / Okta)
- Block known malicious file hashes across EDR fleet — push IOCs to all managed endpoints
- Alert SIEM with new IOCs — create detection rules for any IOCs not already covered
- Preserve all relevant logs — export and store copies independently of potentially compromised systems
- Implement temporary network controls to prevent attacker re-entry while full eradication is prepared
- Deploy enhanced monitoring on all systems in the same segment as affected systems
- Patch the vulnerability used for initial access on all similar systems — not just the affected one
- Force password reset for all accounts that may have been exposed (not just confirmed compromised)
- Require step-up authentication for all privileged accounts until investigation is complete
- Communicate estimated timeline to business stakeholders — when will affected systems return to service?
- Complete malware analysis — identify all components (droppers, loaders, C2 beacons, persistence modules)
- Identify and remove all malware components from every affected system
- Identify and remove all persistence mechanisms (registry run keys, scheduled tasks, startup items, WMI subscriptions, new user accounts, SSH keys)
- Identify and remediate the root cause vulnerability — patch or configuration change applied
- Audit all privileged accounts — identify any created by attacker, disable immediately
- Audit all scheduled tasks, startup scripts, and service installations on affected systems
- Scan all affected systems with updated EDR signatures post-eradication
- Search for lateral movement indicators — verify eradication on all systems the attacker touched, not just the initial entry point
- Perform IOC sweep across the entire environment — was the attacker present on any system not yet identified?
- Verify no rogue network connections or listening services remain on affected systems
- Restore systems from known-clean backups taken before the compromise — verify backup integrity before restoring
- Rebuild systems from scratch (preferred over restoring from backup if backup integrity is uncertain)
- Verify all restored systems pass security configuration baseline checks before returning to production
- Enable enhanced monitoring on all recovered systems for minimum 30 days — alert on any anomalous behaviour
- Validate business functionality — application owners confirm services are operating correctly
- Gradually restore network access — do not return full connectivity in one step
- Verify all security controls are fully operational on recovered systems (EDR, logging, backup)
- Obtain formal sign-off from business owners that services have been verified
- Communicate to affected users that systems are restored and the situation is resolved
- Document all recovery actions with timestamps for the incident report
- Critical business services — revenue-generating systems, customer-facing services, payment processing
- Core infrastructure — domain controllers, DNS, authentication, email
- Internal business applications — ERP, CRM, internal tools
- Development and test environments — restore last, after production is verified clean
Conduct within 2 weeks of incident closure. Attend: full IR team, IT Ops, Legal, Communications. Purpose is improvement — not blame. All findings must be documented with assigned owners and deadlines.
- Timeline review: Walk through the full incident timeline. What happened, when, and in what order?
- Detection review: How was the incident detected? How long between initial compromise and detection? What detection gaps exist?
- Response review: What worked well in the response? What did not work?
- Communication review: Were the right people notified at the right time? Were communications clear and effective?
- Plan review: Were there gaps in the IR plan or playbooks? What needs to be updated?
- Tool review: Did the tools work as expected? Are there tool gaps?
- Action items: Every identified improvement gets an owner, deadline, and success metric.
Ransomware is the most common P1 incident type in 2026. This playbook is designed to be used by the on-call analyst at the moment of detection — it is deliberately concise and action-oriented. Every step includes who executes it.
⚡ Make your IR plan operational this month
- Run a tabletop exercise within 30 days — you do not need a sophisticated red team. Pick a scenario (ransomware encrypts your file server), get the IR team in a room, and walk through the response step by step. Every gap you discover in the tabletop is a gap you would have discovered during a real incident — but without the consequences. Document every gap and assign owners to fix them.
- Build your offline emergency contact list today — print the contact list with personal mobile numbers for every member of the IR team. Store one copy in a physical binder accessible to on-call staff. Verify every number is correct by calling each person to confirm. This single action addresses the most common IR failure mode.
- Test your backups this week — not just whether backups complete successfully, but whether you can actually restore from them. Restore a critical server to an isolated environment. Time the process. If you cannot restore in your RTO window, your backup strategy needs fixing before any incident occurs.
- Deploy SIEM and EDR as your detection foundation — an IR plan is only as good as your ability to detect incidents. Without centralised log monitoring and endpoint detection, your plan starts at phase 3 rather than phase 2. SIEM guide → | EDR guide →
- Map your regulatory obligations now — before an incident — work with Legal to document which data types you hold, which jurisdictions' laws apply, and what the notification timelines are. This mapping should be in the IR plan and accessible offline. Discovering your GDPR obligations during a breach response is too late.
A complete incident response plan should include: the purpose and scope of the plan, the incident response team structure with roles and responsibilities, a RACI matrix assigning activities to roles, the incident severity classification system (P1–P4) with escalation procedures, the six response phases (preparation, detection, containment, eradication, recovery, post-incident) with checklists for each, specific playbooks for your most likely incident types (ransomware, phishing, data breach), an emergency contact list with out-of-band contacts, communication templates for internal and external notifications, regulatory notification requirements and timelines, evidence handling procedures with chain of custody forms, and the plan review and testing schedule. Most plans fail not because they lack content but because they are not tested and the playbooks are too high-level to be usable under pressure.
NIST SP 800-61 defines four phases that are typically expanded to six for operational clarity: Phase 1 — Preparation (build the team, tools, and playbooks before any incident); Phase 2 — Detection and Analysis (identify and scope the incident, classify severity, notify stakeholders); Phase 3 — Containment (stop the incident from spreading further while preserving evidence); Phase 4 — Eradication (remove all malware, persistence, and attacker access from affected systems); Phase 5 — Recovery (restore systems to normal operation with verification and enhanced monitoring); Phase 6 — Post-Incident Activity (lessons learned, root cause analysis, IR plan updates, and new detection rules). The phases feed back into each other — lessons learned from Phase 6 improve Preparation in Phase 1.
GDPR Article 33 requires notification to the relevant supervisory authority within 72 hours of becoming aware of a personal data breach — this clock starts when you become aware of the breach, not when it occurred. If you cannot complete the full notification within 72 hours, you can provide a partial notification and supplement it with additional information as it becomes available. Article 34 additionally requires notifying affected individuals "without undue delay" when the breach is likely to result in high risk to their rights and freedoms. Some EU member states have stricter requirements layered on top of GDPR. Legal counsel should be involved within the first hour of any suspected breach involving EU resident data.
This is a legal and business decision, not purely a technical one. The security community's general recommendation is not to pay — it funds criminal operations and does not guarantee data recovery or that the attacker will not leak the data anyway. Practically: first check NoMoreRansom.org for free decryptors (many exist for common variants). Assess your backup integrity — restoration from clean backups is almost always preferable. If considering payment: engage Legal immediately, as many ransomware operators are on sanctions lists (OFAC, EU), making payment potentially illegal regardless of whether you want to pay. Payment decisions for P1 incidents should involve executives, Legal, and potentially your cyber insurer (many policies cover ransom payments). Law enforcement (FBI, NCSC) should be notified — they sometimes have intelligence on the specific variant including free decryptors.
The incident response plan is the strategic document — it defines the programme, team structure, roles, severity levels, escalation paths, and overall methodology. It is typically 20–60 pages long and serves as the reference document for how the organisation approaches all security incidents. A playbook is a tactical, step-by-step procedure for responding to one specific incident type — ransomware, phishing, data breach, insider threat. Playbooks are typically 1–3 pages long and designed to be used under stress by an on-call analyst who may be woken at 2 AM. The plan tells you what to do at a programme level; the playbook tells you exactly what to click and who to call in the first hour of a specific incident type.
At minimum, a tabletop exercise (walkthrough discussion of a scenario without technical execution) annually. Ideally, a more hands-on simulation (using a test environment to actually execute parts of the response workflow) every six months for the core IR team. When to conduct additional tests: after any significant change to the environment (major cloud migration, new business acquisition, significant staff changes on the IR team), after a real incident (run a post-incident tabletop specifically on what could have gone better), and when new incident types become prominent threats to your industry. Plans that are not tested contain hidden gaps that only appear during real incidents — at the worst possible time.