NIST 800-61 Rev 3 is not a refreshed edition of the incident handling guide many programs were built on; it is a different kind of document. NIST finalized it on 3 April 2025, a year after the draft of 3 April 2024, and it supersedes SP 800-61 Rev. 2, the Computer Security Incident Handling Guide published in August 2012.
If your incident response plan still cites the Rev. 2 phases, it is not wrong about how to handle an incident. It is citing a superseded baseline. This guide explains what NIST 800-61 Rev 3 contains, how to read its structure, and the specific changes a Rev. 2-era program should make.
What NIST 800-61 Rev 3 actually is
The full title is Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. The authors are Alexander Nelson, Sanjay Rekhi and Murugiah Souppaya of NIST, and Karen Scarfone of Scarfone Cybersecurity.
The subtitle carries the meaning. A Community Profile takes the NIST Cybersecurity Framework (CSF) 2.0 and states, for one purpose, which outcomes matter and how much. NIST 800-61 Rev 3 does this for incident response: it walks the CSF 2.0 Core and rates every Function, Category and Subcategory by how much it contributes to responding to incidents.
That is a change of genre. Rev. 2 told a response team how to handle an incident. NIST 800-61 Rev 3 tells an organization where incident response sits inside its wider cybersecurity risk management, and leaves the hands-on method to you.
Why NIST rewrote it from scratch
Section 1.1 says the scope differs significantly from earlier versions, and gives the reason: the details of how to perform incident response change too often to capture in one static publication. Appendix C, the change log, confirms how far the change goes:
- It is a full rewrite, not an edit of the Rev. 2 text.
- The focus moved from incident handling guidelines to recommendations across cybersecurity risk management.
- The content was reorganized as a CSF 2.0 Community Profile.
- Most hyperlinks moved out of the document to the SP 800-61 project website, where they can be maintained without a new revision.
- It uses the new NIST publication template.
The practical consequence: you cannot compare Rev. 2 with NIST 800-61 Rev 3 paragraph by paragraph and patch the differences. Treat Rev. 3 as a new reference and re-map your program to it.
NIST 800-61 Rev 3 by the numbers
The profile has 134 rows: the 6 CSF Functions, 22 Categories and 106 Subcategories. Each row carries a priority, and many carry numbered items. These are the counts worth knowing before you start mapping.
| Element | Count | What it is |
|---|---|---|
| Profile rows | 134 | 6 Functions, 22 Categories, 106 Subcategories |
| Recommendations (R) | 106 | Actions NIST recommends |
| Considerations (C) | 8 | Options NIST suggests you weigh |
| Notes (N) | 107 | Explanation, context and references |
| High-priority Subcategories | 39 of 106 | The core of incident response |
The rows sit in two tables. Table 2 covers preparation (Govern, Identify and Protect) and lessons learned (the Identify Improvement Category, ID.IM). Table 3 covers incident response itself: Detect, Respond and Recover.
Where the High ratings fall
| Function | Rev. 3 table | Subcategories | Priority pattern |
|---|---|---|---|
| Govern (GV) | Table 2 | 31 | 11 Medium, 20 Low, none High |
| Identify (ID) | Table 2 | 21 | 6 High, 14 Medium, 1 Low |
| Protect (PR) | Table 2 | 22 | 1 High, 21 Medium |
| Detect (DE) | Table 3 | 11 | All High |
| Respond (RS) | Table 3 | 13 | All High |
| Recover (RC) | Table 3 | 8 | All High |
Every Detect, Respond and Recover Subcategory is rated High. Only seven Table 2 Subcategories are: ID.RA-02 (threat intelligence), ID.RA-05 (using risk to inform response prioritization), ID.RA-06 (choosing and tracking risk responses), ID.IM-02, ID.IM-03 and ID.IM-04 (improvement and plans), and PR.DS-11 (backups that are created, protected, maintained and tested).
How to read the High, Medium and Low ratings
In NIST 800-61 Rev 3, High marks an activity NIST treats as core incident response. Medium marks an activity that directly supports incident response. Low marks one that supports it indirectly. NIST presents the ratings as a starting point and encourages organizations to customize them.
Use one decision rule: start from NIST’s rating and change it only where you can write down why. If your core service depends on one cloud provider, you might raise the supply chain rows under GV.SC, most of which are Low. Record the reason beside the change, so an auditor sees a decision rather than drift.
Low does not mean optional. It means the row matters to incident response through something else, such as your general risk management or HR practices. Do not drop Low rows from scope; give them less effort.
Recommendations, Considerations and Notes in NIST 800-61 Rev 3
The numbered items are where the substance lives. Each identifier joins a row ID, an item type and a number. RS.MA-02.R1 is the first Recommendation under RS.MA-02 (incident reports are triaged and validated): perform a preliminary review to confirm an incident has occurred, then estimate its severity and the urgency of response.
Three items show the style of the whole profile:
- RS.MA.R1 — because resources are limited, incidents should not be handled on a first-come, first-served basis.
- RS.MA-01.C1 — consider designating an incident lead for each incident.
- RS.MA-04.N1 — escalation generally means more resources or time; elevation means involving a higher level of management.
Treat the three types differently. Each Recommendation is a candidate requirement: adopt it, adapt it, or reject it with a written reason. Each Consideration is a design choice to decide explicitly, then record. Notes are context; read them, but do not track them as controls.
Rev. 2 vs NIST 800-61 Rev 3: where the four phases went
Rev. 2 organized incident handling as a four-phase life cycle: Preparation; Detection and Analysis; Containment, Eradication and Recovery; and Post-Incident Activity. Table 1 of Rev. 3 maps those phases onto CSF 2.0 Functions.
| Rev. 2 life cycle phase | Rev. 3 CSF 2.0 Functions (Table 1) |
|---|---|
| Preparation | Govern; Identify (all Categories); Protect |
| Detection and Analysis | Detect; Identify (Improvement) |
| Containment, Eradication and Recovery | Respond; Recover; Identify (Improvement) |
| Post-Incident Activity | Identify (Improvement) |
Two things stand out. Preparation is no longer a phase of incident response; it is the governance, risk and protection work the rest of the organization already does. And improvement appears in three of the four rows, because Rev. 3 expects lessons to be captured and shared as soon as they are identified, not saved for a meeting after recovery ends.
Rev. 3 also says organizations should use whichever life cycle model suits them best. Keeping the four phases in training material is acceptable, provided your plan and your evidence map to the Functions.
What a Rev. 2-era program must update
You do not need to rebuild everything. These are the changes that move a Rev. 2 program onto NIST 800-61 Rev 3 with the least wasted effort.
- Re-map the plan. Add a column to your plan’s table of contents showing the CSF Function each section serves. Gaps in Detect, Respond or Recover are your first priority, because every row there is High.
- Confirm the policy exists. GV.PO.R1 says cybersecurity policies should include an incident response policy. GV.RR-02.R1 says all incident response roles and responsibilities should be documented in policy.
- Replace the queue with risk factors. RS.MA.R2 bases triage, prioritization, escalation, elevation and recovery decisions on risk evaluation factors. RS.MA.N2 gives examples: asset criticality, functional impact, data impact, stage of observed activity, threat actor characterization and recoverability.
- Name an incident lead per incident. RS.MA-01.C1 is a Consideration, so decide it on the record either way.
- Move lessons learned into continuous improvement. ID.IM-03 is High: improvements come from running your own processes, including every response and recovery effort.
- Synchronize continuity and response. ID.IM-04.R1 asks you to synchronize business continuity plans with incident response plans.
- Write third-party roles into contracts. Under a shared responsibility model, define responsibilities, information flows, coordination and authority to act, including restrictions.
- Fix stale references. Rev. 3 cites NIST IR 8286 (2020), which has since been superseded by NIST IR 8286 Rev. 1 (December 2025). Check every NIST citation in your documents against the current version.
What NIST 800-61 Rev 3 does not give you
Knowing the gaps saves time in an audit. The profile deliberately leaves out step-by-step handling procedures; Section 2.3 expects you to write playbooks and procedures yourself, and points to CISA’s Cybersecurity Incident & Vulnerability Response Playbooks (2021) as examples.
It also sets no notification deadlines. RS.CO-02.R3 says to notify in compliance with the laws and regulations that apply to your sectors and locations. Notification clocks differ by regime and start from different triggers, so build a register of the obligations that apply to you; our breach notification guide covers how to approach that.
Finally, NIST 800-61 Rev 3 assumes you speak CSF 2.0. If the Functions and Categories are new to you, read our NIST Cybersecurity Framework overview first. The authoritative source is the publication itself: NIST SP 800-61 Rev. 3.
Applying NIST 800-61 Rev 3: the guides in this series
Each guide below takes one part of NIST 800-61 Rev 3 and turns it into something you can adopt.
- The NIST incident response lifecycle: the four Rev. 2 phases and the Table 1 mapping to CSF 2.0.
- Incident response plan template: what a Rev. 3-aligned plan contains, section by section.
- Incident response policy: the seven key elements in Section 2.3.
- Incident severity levels: a matrix built from Rev. 3’s six risk evaluation factors.
- Incident response roles and responsibilities: Section 2.2 roles, authority and a RACI.
- Incident response playbook: a standard structure and the scenarios worth writing first.
- Ransomware playbook: the first hour, the payment decision and clean restores.
- Security event vs incident: the Rev. 3 definitions and declaration criteria.
- Tabletop exercise scenarios: seven cyber scenarios with injects, for ID.IM-02.
- Incident response checklist: a checklist ordered by CSF Function.
NIST 800-61 Rev 3 FAQ
Is NIST 800-61 Rev 2 still valid?
Rev. 2 was superseded by NIST 800-61 Rev 3 on 3 April 2025. Its four phases remain a usable teaching model, since Rev. 3 lets you choose your life cycle, but cite Rev. 3 as your baseline.
Does NIST 800-61 Rev 3 replace an incident response plan?
No. It tells you which outcomes your program should achieve and how to prioritize them. You still need your own policy, plan, procedures and playbooks.
How many recommendations are in NIST 800-61 Rev 3?
There are 106 Recommendations, 8 Considerations and 107 Notes spread across 134 profile rows.
Do I have to adopt CSF 2.0 to use NIST 800-61 Rev 3?
Not as a full program, but the profile is written in CSF 2.0 identifiers, so your mapping and evidence will use them. Mapping to the Functions is the simplest way to show alignment.
Our Incident Response Toolkit provides 93 editable templates aligned to NIST SP 800-61 Rev. 3 — including the Toolkit Guide and Rev 2 to Rev 3 Transition, the Incident Response Community Profile Workbook and the Incident Response Plan — for $99.