Comparing Incident Response Frameworks

NIST SP 800-61 organises incident response into four phases. Preparation comes first and covers everything an organisation does before an incident: building and training the team, writing the IR plan and playbooks, deploying detection capabilities, and establishing communication channels. The guide treats preparation as continuous, not as a one-time activity; it is revisited after every incident review.

The second phase, Detection and Analysis, covers the work of identifying potential incidents from alerts and log data, confirming that an event is indeed an incident rather than a false positive, scoping the incident, and prioritising the response. NIST dedicates significant attention to this phase because misidentification at this stage propagates through everything that follows. A false negative means no response; a false positive wastes response capacity and can trigger unnecessary containment actions.

The third phase, Containment, Eradication, and Recovery, groups three operationally distinct activities into a single phase. Containment limits the spread and impact of the incident; eradication removes the root cause, including malware, attacker persistence mechanisms, and vulnerable configurations; recovery restores affected systems to normal operation and verifies that they are clean. NIST acknowledges that these three activities may overlap in practice, but keeps them conceptually ordered within the phase.

The fourth phase, Post-Incident Activity, covers the lessons-learned meeting, incident report, metric updates, and any process improvements triggered by the incident. NIST emphasises that this phase should occur within a defined window after the incident closes, typically one to two weeks, while memory is fresh and evidence is available.

SANS PICERL names six steps: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. The first step, Preparation, maps closely to NIST's preparation phase and covers the same content: team building, plan writing, tool deployment, and forensic readiness. PICERL's second step, Identification, corresponds to NIST's Detection and Analysis phase and covers alert triage, scoping, and incident confirmation.

The significant structural departure is that PICERL breaks NIST's combined third phase into three discrete steps: Containment, Eradication, and Recovery. This separation reflects an operational reality that incident responders encounter constantly. In a live incident, containment may be decided and executed by one team member while another is still gathering evidence. Eradication cannot begin safely until the scope of compromise is fully understood, which may lag containment by hours or days. Recovery requires sign-off criteria that are distinct from the criteria used to declare containment complete. Naming these as separate steps makes status reporting cleaner and reduces the risk that teams skip eradication and move straight from containment to recovery because both activities sit inside the same phase label.

The final step, Lessons Learned, aligns with NIST's Post-Incident Activity phase. SANS training typically emphasises structured blameless post-mortems, borrowed from the site reliability engineering community, as the format for this step. The goal is systemic improvement, not attribution of fault to individuals.

PICERL is the model most working incident responders encounter in their initial training because SANS courses such as FOR508 and SEC504 teach it explicitly. As a result, it has become a lingua franca in many security operations centres regardless of what the organisation's formal IR policy document calls the phases. Teams that write playbooks in PICERL language and are assessed against a NIST-structured IR plan need an explicit mapping between the two to avoid confusion during incidents.

ISO/IEC 27035 defines information security incident management across a five-phase model: Plan and Prepare, Detect and Report, Assess and Decide, Respond, and Lessons Learned. The five-phase structure sits between NIST's four phases and PICERL's six steps in terms of granularity. The Assess and Decide phase, which has no direct single-phase equivalent in NIST or PICERL, explicitly covers the decision about whether a detected event meets the threshold for incident declaration and which response track to follow.

The standard is published in multiple parts. Part 1 (ISO/IEC 27035-1) covers principles and concepts. Part 2 (ISO/IEC 27035-2) covers planning and preparation in detail. Part 3 covers guidelines for incident response operations. The multi-part structure allows organisations to adopt individual parts incrementally, which matters for organisations in the process of building IR capability rather than refining a mature one.

ISO/IEC 27035 carries weight in audit contexts because it is part of the ISO/IEC 27000 family, which includes ISO/IEC 27001 (the information security management system standard used for certification). An organisation pursuing ISO/IEC 27001 certification will have its incident management processes assessed for consistency with ISO/IEC 27035. In the European Union, the NIS2 Directive requires operators of essential services to have incident handling capability; national supervisory authorities in EU member states often reference ISO/IEC 27035 alignment as evidence of adequate capability. In the UK, the National Cyber Security Centre references the standard in its guidance for organisations.

CREST is a not-for-profit professional body registered in the UK that publishes guidelines and operates accreditation schemes for penetration testing, red teaming, and incident response service providers. Its IR guidance documents, including the CREST Cyber Security Incident Response Guide and the CREST Good Practice Guide for Incident Response, are aimed at both organisations building internal IR capability and at buyers of external IR services.

CREST's lifecycle model is broadly consistent with NIST and SANS but emphasises specific technical activities more explicitly than either: volatile data capture during live response, memory forensics, threat intelligence integration at the triage stage, and supply chain incident considerations. CREST also addresses the relationship between IR and crisis management more directly, including board-level communication and engagement with law enforcement, which tend to receive less specific attention in NIST and SANS documentation.

The CREST accreditation schemes are most relevant when an organisation is procuring external IR services. A CREST-accredited IR provider has been assessed against defined competency standards, which gives procuring organisations a benchmark for vendor selection. In the UK, the NCSC Cyber Incident Response (CIR) scheme uses CREST accreditation as one of its eligibility criteria. Similar schemes operate in Australia under CREST's regional body and in several Asian markets. Organisations in these markets that require their IR retainer providers to hold CREST accreditation are effectively making a framework selection decision by choosing a partner assessed against CREST standards.

The table below places the four frameworks side by side on six dimensions. None of the frameworks is objectively superior; each reflects a different primary use case and audience.

The phase count difference between NIST and PICERL is the most practically significant. In a live incident, a team using PICERL has three distinct phase transitions, from containment to eradication, and from eradication to recovery, each of which has its own entry criteria and sign-off process. A team using NIST has one composite phase. Whether that granularity helps or hinders depends on team size and incident complexity: in a small team handling a straightforward malware infection, the extra phase boundaries add friction; in a large organisation handling a multi-vector breach, they enforce discipline that prevents teams from moving to recovery before eradication is complete.

Most mature IR programmes do not use a single framework in isolation. The typical approach is to select one framework as the authoritative lifecycle reference, use a second for operational granularity, align to a third for compliance documentation, and reference a fourth when procuring services. This is not inconsistency; it is recognising that the frameworks serve different purposes and audiences within the same organisation.

A common blended pattern for a mid-size organisation with ISO 27001 certification, a UK or EU regulatory context, and an external IR retainer looks like this. NIST SP 800-61 provides the lifecycle backbone for the IR policy document because its four-phase model is widely understood by management and maps cleanly to policy-level descriptions of IR capability. SANS PICERL phase names appear in playbooks and runbooks because responders trained through SANS courses use those names instinctively during live incidents. ISO/IEC 27035 is the reference for audit evidence: the organisation documents that its Plan and Prepare phase activities satisfy the standard's requirements, which satisfies the ISO 27001 auditor. CREST guidelines inform the criteria used to select and manage the external IR retainer provider.

The mapping exercise between frameworks is not optional when blending. If a playbook written in PICERL language says an incident has reached the Eradication step, the IR manager must be able to confirm which NIST phase the incident is in for reporting to a CISO who uses NIST terminology, and which ISO/IEC 27035 phase applies for audit documentation. A simple mapping table in the IR plan resolves this. See also the NIST SP 800-61 Lifecycle and SANS PICERL Model topics for the detailed phase content of each.