← Patterns / SP-036

Incident Response

Incident Response is the organised approach to managing the aftermath of a security breach or attack. Its purpose is to limit damage, reduce recovery time and cost, and learn from every event to strengthen defences. Despite being universally acknowledged as essential, incident response remains one of the weakest capabilities in most organisations -- not because the theory is complex, but because effective response requires preparation, practice, and organisational muscle memory that cannot be improvised during a crisis. The incident response lifecycle has seven phases. Preparation builds the capability before incidents occur: team structure, playbooks, communication plans, tools, relationships with legal and law enforcement, and regular exercises. Detection and Analysis identifies potential incidents through monitoring, alerts, user reports, and external notification, then determines scope, severity, and initial classification. Triage prioritises the response based on business impact, regulatory obligations, and available resources. Containment limits the blast radius through network isolation, credential revocation, and system quarantine -- balancing speed of containment against evidence preservation. Eradication removes the root cause: malware, backdoors, compromised credentials, and the vulnerability that enabled initial access. Recovery restores systems to normal operation with enhanced monitoring to detect any recurrence. Post-Incident Review analyses the full incident timeline, identifies what worked and what failed, and produces concrete improvements to detection, response, and prevention. Two aspects distinguish mature incident response from immature. First, the recognition that incident response is a team sport: it requires coordination across security operations, IT operations, legal, communications, executive leadership, and often external parties including regulators, law enforcement, and incident response retainers. The incident commander role -- a single accountable person who coordinates all workstreams -- is critical. Second, the understanding that you cannot design your incident response process during an incident. Every decision that can be made in advance -- escalation criteria, communication templates, containment procedures, regulatory notification triggers -- must be documented and tested before the crisis hits. For regulated entities, incident response carries specific obligations. Financial services firms must notify regulators within defined timeframes (often within hours of detection). Data breaches require notification under GDPR, DORA, and equivalent regulations. Critical national infrastructure operators have additional reporting obligations to NCSC and sector regulators. This pattern addresses these obligations as architectural requirements, not afterthoughts.

Release: 26.02 Authors: Aurelius, Vitruvius Updated: 2026-02-07

Assess

ATT&CK This pattern addresses 452 techniques across 13 tactics View on ATT&CK Matrix →

Click any control badge to view its details. Download SVG

Key Control Areas

Incident Response Programme and Preparation

IR-01 IR-02 IR-08 PL-02 PM-14

Preparation is the foundation that determines everything else. IR-01 establishes incident response policy: scope (what constitutes a security incident), authority (who can authorise containment actions including system shutdown), roles and responsibilities, and integration with the wider risk management framework. IR-02 mandates incident response training for all team members: role-specific training for incident handlers, tabletop exercises for leadership, and awareness training for the broader organisation on reporting obligations. IR-08 defines the incident response plan: a living document that covers team structure, escalation procedures, classification criteria, containment strategies for common scenarios, communication templates, and contact details for all stakeholders including out-of-hours contacts. PL-02 documents the incident response architecture in the security plan: how IR integrates with monitoring (SP-031), how it interfaces with business continuity (SP-034), and how it aligns with regulatory expectations. PM-14 ensures the programme is tested regularly: quarterly tabletop exercises, annual full-scale simulations, and after-action reviews that drive improvement. Preparation also means pre-positioning: retainer agreements with external incident response firms, pre-approved legal counsel, relationships with law enforcement contacts, and pre-staged forensic tools and clean media.

Detection, Classification, and Triage

IR-04 IR-05 SI-04 AU-06 CA-07

Detection is the transition from monitoring to response. IR-04 handles initial incident identification from multiple sources: SIEM alerts, EDR detections, user reports (phishing, suspicious behaviour), external notification (threat intelligence, law enforcement tip-off, customer complaint), and proactive threat hunting. IR-05 provides continuous incident monitoring: tracking the developing picture as new indicators emerge and the scope becomes clearer. SI-04 feeds real-time system monitoring data to the triage process: what systems are affected, what data may be compromised, what the adversary appears to be doing now. AU-06 analyses audit records to establish the incident timeline: when did initial compromise occur, what actions has the adversary taken, what data has been accessed or exfiltrated. CA-07 provides continuous monitoring context: is this an isolated event or part of a broader campaign? Classification uses a severity model: Critical (active data exfiltration from crown jewel systems, destructive attack in progress), High (confirmed compromise with lateral movement, regulatory notification likely required), Medium (confirmed compromise contained to single system, no sensitive data access confirmed), Low (attempted or unsuccessful attack, policy violation). Triage determines response priority and resource allocation based on classification.

Containment Strategies

IR-04 SC-07 AC-02 AC-04 SI-04

Containment is the most time-critical phase. IR-04 executes containment actions through predefined strategies for common incident types. SC-07 enables network-level containment: isolating compromised segments through firewall rules, VLAN changes, or SDN policy, while preserving network connectivity for forensic data collection. AC-02 provides identity-level containment: disabling compromised accounts, forcing password resets, revoking active sessions across all systems, and temporarily elevating monitoring on related accounts. AC-04 controls information flow to prevent ongoing data exfiltration: blocking outbound connections to known C2 infrastructure, restricting data movement from compromised segments, and enabling enhanced DLP monitoring. SI-04 provides ongoing monitoring during containment to confirm effectiveness: is the adversary attempting to pivot to other systems, are new indicators appearing, is the containment holding. Containment must balance three competing priorities: speed (contain before the adversary achieves their objective), evidence preservation (capture volatile data before it is lost), and business continuity (minimise disruption to operations). Short-term containment stops the immediate bleeding; long-term containment maintains the quarantine while eradication is planned and executed.

Evidence Handling and Forensic Investigation

AU-09 IR-04 AU-02 AU-03 SI-04

Evidence handling must be forensically sound from the first moment. AU-09 protects audit information from tampering: ensuring that log data, memory captures, and disk images are cryptographically hashed and stored on write-protected media. Chain of custody must be maintained from collection through analysis to potential legal proceedings. IR-04 includes forensic investigation as a core incident handling function: determining initial access vector, mapping adversary movement through the environment, identifying all compromised systems and accounts, and assessing data exposure. AU-02 ensures the right events were logged in the first place: authentication events, process execution, network connections, file access, and configuration changes on affected systems. AU-03 validates that audit record content is sufficient for investigation: timestamps, user identifiers, source addresses, actions performed, and outcomes. SI-04 provides additional forensic data from system monitoring: endpoint telemetry, network flow data, and DNS query logs. Memory forensics must be performed before containment actions that would destroy volatile evidence (rebooting, reimaging). Disk forensics uses verified images, never the original media. All forensic findings feed into the incident timeline that drives eradication and recovery decisions.

Communication and Stakeholder Management

IR-06 IR-07 PM-14 PL-04

Communication during an incident is as critical as technical response. IR-06 defines incident reporting: internal escalation (who needs to know, when, and what), regulatory notification (trigger criteria, timeframes, required content), law enforcement notification (when to involve police, NCA, or FBI), and customer/member notification (when personal data or service integrity is affected). IR-07 provides incident response assistance: the incident commander coordinates all communication through a single point to prevent conflicting messages. PM-14 ensures communication procedures are tested during exercises: can you reach the CEO at 2am, does the regulatory notification template work, do you know the NCSC reporting portal login. PL-04 defines rules of behaviour during incidents: what can be said externally, who is authorised to speak to media or regulators, and how to handle speculation. Communication cadence must be defined: hourly situation reports during active incidents, daily summaries during extended containment, and formal closure notifications. For regulated entities, specific notification obligations apply: GDPR requires notification to the ICO within 72 hours of becoming aware of a personal data breach; DORA mandates initial notification to competent authorities without undue delay; FCA expects notification of material operational incidents. Pre-drafted notification templates with fill-in-the-blank fields dramatically reduce time-to-notify under pressure.

Eradication and Recovery

IR-04 CP-10 SI-07 CM-02 RA-05

Eradication removes the adversary completely. IR-04 at the eradication phase includes: removing malware and backdoors from all affected systems, closing the vulnerability that enabled initial access, revoking and reissuing all potentially compromised credentials (not just confirmed ones), and validating that no persistence mechanisms remain. CP-10 governs system recovery and reconstitution: rebuilding affected systems from known-good images rather than attempting to clean compromised systems, restoring data from verified backups, and validating system integrity before returning to production. SI-07 verifies software and firmware integrity on recovered systems: ensuring that operating systems, applications, and configurations match known-good baselines. CM-02 re-establishes baseline configurations: any configuration drift discovered during the incident must be corrected during recovery. RA-05 scans recovered systems for residual vulnerabilities before they return to production. Recovery must be coordinated: if the adversary detects eradication in progress before it is complete, they may accelerate their objectives or destroy evidence. Simultaneous eradication across all affected systems is preferred over sequential cleanup that gives the adversary time to react.

Post-Incident Review and Continuous Improvement

IR-04 IR-06 CA-02 PM-14 AT-03

Every incident is a learning opportunity. IR-04 mandates post-incident analysis: a blameless review conducted within two weeks of incident closure that examines the full timeline, identifies what detection rules fired and which missed, evaluates containment and eradication effectiveness, and assesses communication and coordination. IR-06 produces the formal incident report: executive summary, detailed timeline, root cause analysis, impact assessment, and remediation actions with owners and deadlines. CA-02 assesses controls that failed or were absent: every gap becomes a tracked remediation item. PM-14 integrates lessons learned into the testing programme: new scenarios for tabletop exercises, updated detection rules, revised playbooks. AT-03 provides targeted training where the review identified skill gaps. The post-incident review must produce concrete outputs: new or updated detection rules (deployed within days, not months), revised playbooks, updated communication templates, infrastructure changes to prevent recurrence, and metrics updates (time-to-detect, time-to-contain, time-to-recover). Organisations that treat post-incident review as a compliance exercise rather than a genuine improvement mechanism repeat the same failures.

Incident Response Team Structure and Readiness

IR-02 PS-01 PS-07 AT-03 PM-14

The incident response team is the human capability that makes everything else work. IR-02 provides training across multiple tiers: Tier 1 analysts handle initial triage and routine incidents, Tier 2 analysts conduct deeper investigation and coordinate containment, Tier 3 specialists handle advanced forensics, malware analysis, and threat hunting. PS-01 defines personnel security policies for IR team members: they require enhanced vetting given their access to sensitive forensic data and their role in high-stakes decisions. PS-07 manages external personnel: retainer incident response firms, forensic specialists, and legal counsel who augment internal capability during major incidents. AT-03 provides role-based training: incident commanders need leadership and communication skills, technical analysts need forensic tools proficiency, and business liaisons need regulatory knowledge. PM-14 ensures readiness through regular exercises and metrics: mean-time-to-acknowledge, mean-time-to-triage, and mean-time-to-contain measured across real incidents and exercises. On-call rotations, escalation procedures, and war room logistics must be maintained and tested. The incident commander role is paramount: a single person with authority to make decisions, allocate resources, and coordinate across all workstreams, who is trained in crisis management and can operate effectively under sustained pressure.

When to Use

This pattern applies to every organisation that operates information systems -- incident response capability is not optional. It is particularly critical for: regulated financial services firms with notification obligations to FCA, PRA, BoE, or equivalent regulators, organisations subject to GDPR or equivalent data protection regulations, critical national infrastructure operators with NCSC reporting obligations, organisations that process payment card data (PCI DSS requirement 12.10), healthcare organisations subject to breach notification requirements, any organisation that has experienced an incident and recognised the need for structured response capability, and organisations with cyber insurance that requires demonstrated incident response capability.

When NOT to Use

There are no contraindications for incident response capability -- every organisation needs it. The scale and formality of the capability varies: a five-person startup needs a documented plan and tested communication procedure, not a 24/7 SOC. Very small organisations should consider managed detection and response (MDR) services that include incident response capability rather than building in-house. Organisations that outsource all IT to managed service providers still need their own incident response plan -- the MSP handles technical response, but the organisation retains responsibility for business decisions, regulatory notification, and stakeholder communication.

Typical Challenges

The most common failure is lack of preparation: organisations that have not tested their incident response plan discover its gaps during a real incident, when the cost of discovery is highest. Incident classification is subjective and politically charged: nobody wants to declare a Critical incident with its mandatory notifications and executive involvement. Containment decisions involve difficult trade-offs: isolating a compromised production system stops the adversary but also stops the business. Evidence preservation conflicts with rapid containment: the fastest way to stop an attack (reimaging the system) destroys the forensic evidence needed to understand it. Communication breaks down under pressure: stakeholders receive conflicting information, regulatory notifications are delayed because nobody is sure of the trigger criteria, and media enquiries are handled ad hoc. Skilled incident responders are scarce and expensive: retainer agreements provide surge capability but response time SLAs may not meet the urgency of a fast-moving incident. Post-incident reviews are deprioritised as teams return to normal operations, losing the learning opportunity. Shadow IT and undocumented systems create blind spots: you cannot respond to an incident on a system you do not know exists. Cloud environments add complexity: incident response in AWS/Azure/GCP requires different tools, different access models, and different forensic approaches than on-premises.

Threat Resistance

Incident Response does not prevent threats -- it limits their impact when prevention fails. Effective incident response transforms potential catastrophes into manageable events. Ransomware impact is limited by rapid containment that prevents encryption from spreading, combined with recovery from immutable backups (IR-04, SC-07, CP-10). Data breach impact is limited by early detection that reduces the volume of exposed data, combined with rapid notification that meets regulatory obligations and preserves customer trust (IR-04, IR-06, AU-06). Business email compromise impact is limited by trained staff who report suspicious activity and rapid response that claws back fraudulent transactions (IR-04, AT-02, IR-07). Supply chain compromise impact is limited by forensic investigation that determines the scope of exposure and coordinated eradication across all affected systems (IR-04, SI-07, SR-10). Insider threat impact is limited by monitoring that detects anomalous behaviour and response procedures that preserve evidence for disciplinary or legal proceedings (AU-06, IR-04, PS-04). The key metric is dwell time: the gap between initial compromise and detection. Industry average dwell time remains measured in weeks to months. Organisations with mature incident response capability measure it in hours to days, dramatically reducing the impact of every incident type.

Assumptions

The organisation has security monitoring capability that can detect incidents (see SP-031). An incident response team exists or can be assembled from available personnel. Legal counsel is available who understands cyber incident obligations including regulatory notification. Management has pre-authorised containment actions including system isolation and account suspension. Communication channels exist that do not depend on potentially compromised infrastructure (out-of-band communication). Forensic tools and clean media are available or can be obtained quickly. Relationships with law enforcement and regulators are established before they are needed.

Developing Areas

Ransomware negotiation and payment decisions remain ethically and legally unsettled. Law enforcement agencies discourage payment but acknowledge that some organisations face existential threat without decryption keys. The emergence of ransomware negotiation firms, cryptocurrency tracing services, and OFAC sanctions screening for ransomware payments has created a de facto commercial ecosystem around an activity that many jurisdictions are considering criminalising. Incident response plans must address payment decisions explicitly rather than deferring them to crisis mode.
Cross-border incident response legal coordination is increasingly complex as regulatory notification timelines proliferate. An organisation operating across EU, UK, US, and APAC jurisdictions may face simultaneous notification obligations to 5-10 regulators with different timelines (72 hours GDPR, 24 hours DORA, 4 hours FCA material incident), different content requirements, and different legal privilege implications. No harmonised notification framework exists, and legal coordination during an active incident consumes resources that should be focused on containment.
IR automation and orchestration through SOAR platforms is maturing but unevenly adopted. Approximately 40% of large enterprises have deployed SOAR, but most use it for alert enrichment and ticket creation rather than automated containment actions. The gap between SOAR's potential (automated isolation, credential revocation, forensic collection) and actual deployment (manual playbooks with some enrichment) reflects legitimate concerns about automated actions causing business disruption without human judgement.
Incident response for cloud-native environments requires fundamentally different tooling and skills. Traditional forensic techniques (disk imaging, memory capture) do not translate directly to serverless functions, ephemeral containers, and managed services where the underlying infrastructure is inaccessible. Cloud-native IR relies on API-based log collection, cloud trail analysis, and provider-specific forensic capabilities that most IR teams are still learning.
Supply chain incident coordination -- responding to compromises that affect multiple organisations through a shared vendor (SolarWinds, MOVEit, CrowdStrike model) -- lacks established playbooks. The coordination problem involves information sharing between affected organisations, managing vendor communication, aligning disclosure timelines, and avoiding competitive disadvantage. ISACs provide some coordination infrastructure, but the speed and scale of modern supply chain incidents consistently outpace available coordination mechanisms.

Related Patterns

Patterns that operate within or alongside this one. Click any to view.

SP-025 Advanced Monitoring and Detection SP-029 Zero Trust Architecture SP-031 Security Monitoring and Response SP-034 Cyber Resilience SP-035 Offensive Security Testing

AC: 2AT: 2AU: 4CA: 2CM: 1CP: 2IR: 8PL: 2PM: 1PS: 3RA: 1SA: 1SC: 1SI: 2SR: 1

AC-02 Account Management

AC-04 Information Flow Enforcement

AT-02 Literacy Training and Awareness

AT-03 Role-Based Training

AU-02 Event Logging

AU-03 Content of Audit Records

AU-06 Audit Record Review, Analysis, and Reporting

AU-09 Protection of Audit Information

CA-02 Control Assessments

CA-07 Continuous Monitoring

CM-02 Baseline Configuration

CP-08 Telecommunications Services

CP-10 System Recovery and Reconstitution

IR-01 Policy and Procedures

IR-02 Incident Response Training

IR-03 Incident Response Testing

IR-04 Incident Handling

IR-05 Incident Monitoring

IR-06 Incident Reporting

IR-07 Incident Response Assistance

IR-08 Incident Response Plan

PL-02 System Security and Privacy Plans

PL-04 Rules of Behavior

PM-14 Testing, Training, and Monitoring

PS-01 Personnel Security Policy and Procedures

PS-04 Personnel Termination

PS-07 External Personnel Security

RA-05 Vulnerability Monitoring and Scanning

SA-09 External System Services

SC-07 Boundary Protection

SI-04 System Monitoring

SI-07 Software, Firmware, and Information Integrity

SR-10 Inspection of Systems or Components