NIST 800-61 vs SANS PICERL: Which Incident Response Model to Use

Teams still argue about whether to run incidents on the NIST four-phase cycle or the SANS six-step PICERL model, but both sources have moved on, and the real decision is how to structure plans and playbooks so they survive incidents that run for weeks. NIST replaced the SP 800-61 Rev. 2 lifecycle with a CSF 2.0 Community Profile in Rev. 3 (April 2025). SANS's Incident Handler's Handbook still describes Preparation, Identification, Containment, Eradication, Recovery and Lessons Learned, while SANS published a newer adaptive model, the Dynamic Approach to Incident Response (DAIR), in September 2026. This guide compares the models on structure, intent and fit, shows how they map to each other, and gives decision criteria, controls per phase and a worked scenario. It is for incident response leads, SOC managers and GRC owners deciding what to write into the incident response plan. For Rev. 3 itself, see the NIST SP 800-61 Incident Response Guide.

Key takeaways

• Short answer: use NIST SP 800-61 Rev. 3 and CSF 2.0 outcomes as the governance and audit backbone, and use PICERL-style phases (or an adaptive loop) only inside playbooks, where responders need ordered actions.
• They answer different questions: Rev. 3 says what outcomes an organisation should achieve across Govern, Identify, Protect, Detect, Respond and Recover; PICERL says what a handler does, in sequence, during one incident.
• The phases map cleanly: PICERL splits NIST Rev. 2's "Detection and Analysis" into Identification and its "Containment, Eradication and Recovery" into three steps; Rev. 3 maps the old phases onto CSF Functions in its Table 1.
• Linear models fail long incidents: Rev. 3 notes that recovery can take weeks or months and lessons should be shared as they emerge; SANS's own DAIR work makes the same criticism of a fixed sequence.
• Do not choose one name and stop: auditors expect CSF outcome evidence, responders need step-by-step playbooks, and regulators set notification clocks neither model contains.

The two models from their primary sources

NIST SP 800-61 Rev. 3. Its full title is "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile". It was finalised on 3 April 2025 and supersedes Rev. 2 (August 2012). It describes three layers: Govern, Identify and Protect as preparation activities that support incident response but belong to wider risk management; Detect, Respond and Recover as the incident response itself; and Improvement (ID.IM) in the middle, taking lessons from every Function and feeding them back. Each CSF row carries a priority (High for core incident response activity, Medium for direct support, Low for indirect support) and recommendations. Rev. 3 deliberately does not provide step-by-step procedures, because those change often and vary by environment; it encourages organisations to document procedures for their most common incident types and points to CISA's playbooks as examples.

SANS PICERL. The SANS Incident Handler's Handbook (SANS Reading Room white paper, published February 2012) describes six phases in order: Preparation, Identification, Containment, Eradication, Recovery and Lessons Learned, and says each phase builds on the previous one. It splits Containment into short-term containment, system back-up (forensic images before wiping) and long-term containment, and recommends a lessons learned meeting, with "within 2 weeks after the incident" as a rule of thumb. The handbook includes a handler's checklist for each phase. "PICERL" is the practitioner acronym for these six phases rather than a SANS product name.

SANS DAIR. In September 2026 SANS published "Dynamic Incident Response: A Framework for Security Teams", a free book under a Creative Commons licence, describing the Dynamic Approach to Incident Response. SANS's announcement describes the traditional prepare, identify, contain, eradicate, recover, lessons learned path as linear, and DAIR as an adaptive, iterative model built around explicit verification, triage and iterative scoping, which responders can re-enter as new evidence appears. SANS says DAIR aligns with NIST guidance and the CSF and is now the version taught in its incident handling course.

Side-by-side comparison

How the phases map

Rev. 3's Table 1 maps the Rev. 2 phases to CSF 2.0 Functions. PICERL's phases sit inside the same structure:

Two gaps show up in the mapping. PICERL has no explicit place for communications and notification, which Rev. 3 covers in RS.CO-02, RS.CO-03, RC.CO-03 and RC.CO-04. And PICERL's Preparation is mostly about the response team, while Rev. 3's preparation layer also covers asset inventories, logging, access control and supplier involvement.

Failure mode: linear models in continuous incidents

Threat model: an intruder with valid credentials and several persistence paths, such as a stolen cloud access key plus an OAuth grant, active over weeks. Each new finding reopens scope.

How the linear model breaks: the team declares Containment complete after disabling the first key, moves to Eradication and Recovery, and closes the ticket. A second credential found later has no phase to go back to, so it is opened as a "new incident", splitting the timeline, the evidence and the root cause analysis. Lessons learned are captured two weeks after closure, after the same gap has already been exploited again.

What Rev. 3 and DAIR change: Rev. 3 treats detection, response and recovery as continuous and asks that lessons are shared as soon as they are identified. RS.AN-08 requires that magnitude is estimated and validated, which forces a check for other affected targets before eradication is called complete. DAIR, by SANS's description, builds explicit verification and iterative scoping into the loop so responders re-enter it when evidence changes.

Controls: make "scope re-validated" an exit gate for containment and eradication; allow a playbook to loop back to Identification without opening a new ticket; keep one incident record with a running timeline; and run interim lessons learned reviews for any incident open longer than an agreed period.

Controls per phase

For the full control family, see the NIST SP 800-53 IR Incident Response guide.

Decision criteria: which to use where

• CSF 2.0 alignment required: if you report a CSF Profile to a board, regulator or customer, or are a US federal agency or supplier, build the plan and programme assessment on Rev. 3. Its rows are already CSF Subcategories, so evidence collected for incident response counts towards the Profile.
• Playbook design: write playbooks with ordered phases, because responders under pressure need sequence. PICERL headings are familiar to most handlers; add explicit loop-back points and scope re-validation gates.
• Training and certification background: if most handlers were trained on PICERL, keep its vocabulary in playbooks and map it to Rev. 3 in the plan. Note that SANS now teaches DAIR, so newer hires may arrive with that vocabulary instead.
• Adaptive loop or fixed phases: a fixed PICERL sequence suits short, well-understood incidents such as a single phishing compromise or a lost device, where scope rarely changes. An adaptive loop of the kind SANS describes for DAIR suits intrusions with several identities and footholds, cloud and SaaS incidents where new evidence arrives from multiple providers, and ransomware cases where recovery overlaps ongoing investigation. Many teams keep both: fixed phases for high-volume playbooks, a looped structure with scope gates for major incidents.
• Small teams: a single plan that names the six CSF Functions plus three or four PICERL-style playbooks for the most common incidents (phishing, credential compromise, ransomware) is enough. Use the Small Business Incident Response Guide.
• Large or regulated organisations: Rev. 3 for policy and audit, a playbook library per incident type, and a separate notification matrix covering every regulatory clock.
• Outsourced response: require the retainer provider to work to your playbook phases and report against your CSF outcomes, so evidence lands in one place.

Worked scenario: refactoring a PICERL plan for Rev. 3

A software company has a 2019 incident response plan with six PICERL chapters and no reference to CSF. A customer audit asks for evidence against CSF 2.0 Respond and Recover outcomes.

1. Split plan from playbooks: the plan keeps policy, roles, severity, communications and improvement; the step detail moves into playbooks. See Incident Response Playbook vs Runbook.
2. Score against Rev. 3 High rows: the team finds no defined incident criteria (DE.AE-08), no backup integrity check before restore (RC.RP-03) and no supplier involvement in planning (GV.SC-08).
3. Keep PICERL inside playbooks: the credential compromise playbook keeps its six headings but gains a loop-back from Eradication to Identification when a new credential or host is found.
4. Add communications: a notification matrix covering customers, regulators and law enforcement is attached to RS.CO-02.
5. Test: a tabletop exercise runs the revised playbook against a multi-week intrusion scenario; findings feed ID.IM-02.

Implementation steps

1. Decide the backbone: record in policy that the programme follows SP 800-61 Rev. 3 and CSF 2.0, and that playbooks use ordered phases.
2. Baseline against Rev. 3: score current practice against every High priority row first, then Medium.
3. Define the phase model for playbooks: PICERL, a DAIR-style loop or your own, with explicit loop-back and scope gates. Publish one glossary so phase names mean the same thing everywhere.
4. Write or refactor the top three playbooks: start with the incident types you see most.
5. Pilot in exercises: run tabletop and technical exercises before using new playbooks live; keep the old playbook available as a fallback until the exercise passes.
6. Roll out and train: brief handlers, on-call engineers and the retainer provider.
7. Review after every major incident: update playbooks and the Rev. 3 score from the after-action report.

Detection and measurement

• Rev. 3 High-row coverage: percentage of High priority rows with current evidence.
• Scope reopen rate: share of incidents where new affected assets were found after containment was declared. A rising figure means scope gates are weak.
• Split incident count: incidents later merged because they were one intrusion. Target zero.
• Time to interim lessons: days from first finding to first shared improvement for long incidents.
• Action closure rate: after-action items closed by their due date.
• Playbook freshness: playbooks exercised or reviewed in the last 12 months.

Common failure patterns

• Reading Rev. 3 like Rev. 2: looking for the old four-phase checklists, finding none and concluding there is nothing to implement.
• PICERL as the whole programme: a plan that covers handling but not inventories, logging, supplier roles or governance, which Rev. 3 treats as preparation.
• Closing on first containment: no magnitude validation, so a second persistence path survives.
• Lessons learned as a single end meeting: no interim reviews for incidents lasting weeks.
• Missing communications: PICERL-based plans without a notification matrix for regulators, customers and law enforcement.
• Mixed vocabularies: NIST phases in the plan, PICERL in playbooks and a provider's own terms in reports, with no glossary.

Framework mapping

Practitioner checklist

• State in policy that the programme follows NIST SP 800-61 Rev. 3 and CSF 2.0.
• Remove references to SP 800-61 Rev. 2 from plans, contracts and audit criteria.
• Score the programme against all Rev. 3 High priority rows.
• Keep phase-ordered steps in playbooks, not in the plan.
• Add loop-back points and scope re-validation gates to every playbook.
• Document incident declaration criteria and a severity matrix.
• Attach a notification matrix covering every regulatory and contractual clock.
• Run interim lessons learned for incidents open beyond an agreed period.
• Publish one glossary of phase names used by staff and providers.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: SP 800-61 Rev. 3 (PDF)
• NIST: The NIST Cybersecurity Framework (CSF) 2.0
• SANS: Incident Handler's Handbook
• SANS: Dynamic Incident Response announcement
• SANS: Dynamic Incident Response book
• CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbooks

Related NHI Mgmt Group resources: Incident Response Guide, NIST SP 800-61 Incident Response Guide, Incident Response Plan Template, AI Agent Observability and Incident Response Guide, NIST CSF 2.0 Respond Function Guide.