NIST SP 800-61 Rev. 3 is no longer an incident handling manual, and teams that still read it as one miss most of what it asks for. Revision 3, finalised on 3 April 2025, replaced the 2012 Rev. 2 and its four-phase lifecycle with a CSF 2.0 Community Profile: a set of CSF outcomes, each rated for how central it is to incident response and annotated with numbered recommendations, considerations and notes. This guide is a working reading of that profile: what is in it, how the High, Medium and Low priorities and the R, C and N items work, the rows that matter most, how to assess yourself against it, where credentials and service accounts fit, and how it maps to SP 800-53, CIS Controls and ISO/IEC 27001. It is written for incident response leads, security architects, GRC teams and assessors. For plan contents, playbooks and retainers see the Incident Response Guide.
Key takeaways
- Rev. 3 is a Community Profile. Its full title is "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile". Rev. 2 was withdrawn on 3 April 2025, the day Rev. 3 was published.
- Priorities tell you where to start. Each CSF row is rated High ("Functions as a core incident response activity for most organizations"), Medium (directly supports) or Low (indirectly supports). The core Detect, Respond and Recover rows are rated High.
- Items are addressable. Recommendations, considerations and notes are numbered so that "GV.OC-03.R1" identifies one recommendation. Use those IDs in plans, assessments and audit evidence.
- Preparation now lives in Govern, Identify and Protect. Policy, roles, current and automatically updated inventories, logging and supplier involvement are part of the profile, and Improvement (ID.IM) carries lessons learned into every Function.
- Identity is in the rows, not a chapter. Rev. 3 has no section on service accounts or tokens, but DE.CM-03, DE.CM-09, RS.MI-02 and PR.AA-01 require monitoring authentication, disabling breached accounts and managing credentials for users, services and hardware.
What it is and who it applies to
SP 800-61 Rev. 3 was written by Alexander Nelson, Sanjay Rekhi and Murugiah Souppaya of NIST and Karen Scarfone of Scarfone Cybersecurity. Its stated aim is to help organisations incorporate incident response recommendations and considerations into their cybersecurity risk management activities; in NIST's words, "Doing so can help organizations prepare for incident responses". The profile is intended for most organisations regardless of sector or size.
- Status: final, published April 2025 (DOI 10.6028/NIST.SP.800-61r3). SP 800-61 Rev. 2 (August 2012) is withdrawn and superseded.
- Who uses it: US federal agencies use NIST guidance alongside SP 800-53 control IR-8 and related controls; for everyone else it is voluntary guidance that can be adopted in whole or in part.
- What it is not: it no longer gives step-by-step handling procedures, forensic techniques or incident categories. The change log (Appendix C) says the content was fully rewritten, outdated material and material covered by other NIST and federal publications was removed, and most hyperlinks moved to a new SP 800-61 project website.
- Definitions: an event is "any observable occurrence that involves computing assets, including physical and virtual platforms"; "Adverse events are any events associated with a negative consequence regardless of cause"; an incident is an occurrence that actually or imminently jeopardises, without lawful authority, the integrity, confidentiality or availability of information or an information system, or violates law or security policy (FISMA 2014 wording).
Rev. 3 states that "Incident response is now considered a critical part of cybersecurity risk management", and its Table 1 maps the Rev. 2 phases onto CSF 2.0: Preparation becomes Govern, all of Identify, and Protect; Detection and Analysis becomes Detect plus Identify's Improvement category; Containment, Eradication and Recovery becomes Respond and Recover plus Improvement; Post-Incident Activity becomes Improvement. Organisations may keep any lifecycle model that suits them; the profile describes outcomes, not a sequence. For CSF 2.0 itself see the NIST CSF 2.0 Guide.
Structure and key requirements
The document has an executive summary, an introduction, Section 2 on incident response as part of risk management (lifecycle model, roles and responsibilities, policies, processes and procedures), Section 3 with the profile itself, references and three appendices (acronyms, glossary, change log). Section 3 has two tables:
- Table 2, preparation and lessons learned: Govern, Identify and Protect rows.
- Table 3, incident response: Detect, Respond and Recover rows.
Each row is a CSF Function, Category or Subcategory with a priority and, where NIST had something specific to say, numbered items: R for a recommendation, C for a consideration, N for a note. Many rows carry only a note pointing to a parent row or to another NIST publication; PR.AA, for example, has only "See the notes for PR."
Table 2 rows that carry real requirements
| Row | Priority | What Rev. 3 asks for |
|---|---|---|
| GV.OC-03 | Medium | R1: cybersecurity requirements include incident response obligations such as notification and breach reporting |
| GV.PO (parent) | See note | R1 at Category level calls for an incident response policy; GV.PO-01 itself is rated Low with no items |
| GV.RR-02 | Medium | R1: document all incident response roles in policy; R2: give each party the authority it needs |
| GV.SC-08 | Medium | Suppliers and third parties included in planning, response and recovery; exercises with them under ID.IM-02 |
| ID.AM-01, ID.AM-02 | Medium | R1: "current and automatically updated inventories" of hardware, and of software, services and systems, internal and external |
| ID.RA-08 | Medium | Processes for receiving vulnerability disclosures; points to SP 800-216 |
| ID.IM-01 | Medium | R1: periodically evaluate programme performance; self-assessment, third-party assessment or independent audit |
| ID.IM-02, ID.IM-03 | High | Improvements from tests, exercises and real incidents; points to SP 800-84 for tabletop and simulation exercises |
| ID.IM-04 | High | R1: synchronise business continuity plans with incident response plans; R2: review plans periodically or when gaps appear; R4: each plan names its resources and management support |
| PR.AT-02 | Medium | R1: "Role-based training should include incident-related responsibilities." |
| PR.PS-04 | Medium | Logs are essential for detection, response and recovery; points to SP 800-92r1 |
High-priority rows in Table 3
Rev. 3 rates DE.CM-01, -02, -03, -06 and -09; DE.AE-02, -03, -04, -06, -07 and -08; RS.MA-01 to -05; RS.AN-03, -06, -07 and -08; RS.CO-02 and -03; RS.MI-01 and -02; RC.RP-01 to -06; and RC.CO-03 and -04 as High. The table covers the rows with the most specific items.
| Row | Key items | What to build |
|---|---|---|
| DE.AE-08 Incidents are declared | R1: apply incident criteria to known and assumed characteristics, allowing for known false positives | Written declaration criteria and a named declaring authority |
| RS.MA-02 Triage and validation | R1: preliminary review to confirm and assess severity; R2: mechanisms for third parties to report possible incidents | Intake channel for suppliers, customers and researchers |
| RS.MA-03 Categorise and prioritise | R1 categorise by type; R2 prioritise by scope, impact, urgency and resources; R3 balance fast recovery against observing the attacker; N1 "Every response strategy decision has trade-offs." | Severity matrix and a documented containment strategy choice per incident |
| RS.MA-04 Escalate or elevate | N1 distinguishes escalation (more resources or time) from elevation (higher management); R1 track all open incidents | Incident tracker with status review cadence |
| RS.MA-05 Recovery criteria | R1 apply recovery criteria; R2 weigh operational disruption of recovery | Defined entry criteria for recovery |
| RS.AN-03 Root cause | R1 sequence of events; R2 vulnerabilities, threats and actors; R3 underlying or systemic causes; R4 check deception technology | Timeline and root cause record |
| RS.AN-06, RS.AN-07 Records and evidence | Protect confidentiality and integrity of records; collected data "is still considered evidence" even without formal chain of custody | Evidence handling and retention procedure |
| RS.CO-02 Notification | R3 notify "in compliance with the current incident notification-related laws and regulations"; R4 affected third parties; R5 law enforcement and regulators per plan criteria and management approval | Notification matrix with deadlines and approvers |
| RS.MI-01 Containment | C1 automated containment by security tools; C2 authorise third parties such as ISPs and cloud providers to contain; R1 handlers can act manually | Pre-approved containment actions and provider authorisations |
| RS.MI-02 Eradication | R1 identify all affected hosts and services so all flaws are fixed; C1 automation; C2 third parties; R2 manual action | Scope verification before declaring eradication |
| RC.RP-03, RC.RP-05 Integrity | Check backups and restoration assets for indicators of compromise and corruption before use; check restored assets and remediate root causes before production | Clean restore validation step |
| RC.RP-06 Close | R1 after-action report covering the incident, response, recovery and lessons learned | After-action report template and owner |
Roles (Section 2.2): leadership, incident handlers, technology professionals, legal, public affairs and media relations, human resources, physical security and facilities management, and asset owners, with third parties defined in contracts. Each should appear in the plan with authority as GV.RR-02.R2 requires.
Identity and NHI requirements
Rev. 3 does not use the terms "service account", "token", "API key" or "non-human identity". The identity requirements sit in individual rows, and the profile's own reference to credentials covers services and hardware, not only people:
- PR.AA-01: "Identities and credentials for authorized users, services, and hardware are managed by the organization". In incident terms, you cannot revoke what you have not inventoried, which links ID.AM-02's automatically updated inventories to the credentials each service holds.
- DE.CM-03 and DE.CM-09.R2: monitor personnel activity including "anomalous user activity" and "Monitor authentication attempts to identify attacks against credentials and unauthorized credential use". Apply this to workload and integration identities as well as users: a service account signing in from a new location or calling unusual APIs is the machine equivalent. The Uber breach 2022, which began with MFA fatigue and a contractor's password, is the user-side example.
- RS.MI-02: eradication may include "disabling breached user accounts". For non-human identities this means rotating API keys, revoking OAuth grants and refresh tokens, re-issuing certificates and signing keys, and invalidating sessions, then confirming no workload still uses the old secret.
- RS.AN-08 magnitude: scope every credential the attacker could have read, not only those seen in use. Relevant ATT&CK techniques include T1552 Unsecured Credentials, T1528 Steal Application Access Token, T1550 Use Alternate Authentication Material, T1098 Account Manipulation and T1078.004 Cloud Accounts.
- GV.SC-08: SaaS and integration suppliers hold tokens into your environment; include them in revocation runbooks.
For identity-specific procedures see the Identity Incident Response Playbook, and for exposed keys and tokens the Leaked Credential Response Playbook.
Implementation steps
- Scope and owner: name an executive owner and decide which business units and suppliers the assessment covers (GV.RR-02, GV.SC-08).
- Current profile: for each Table 2 and Table 3 row, record whether the outcome is achieved, partly achieved or not achieved, and cite the R, C and N items you meet by ID. Start with all High rows.
- Target profile: decide which Medium and Low rows matter for your risk. A small organisation may accept partial coverage of supporting rows such as ID.RA-08 or PR.AT-02 while a regulated or critical operator targets all of them.
- Gap plan: turn gaps into owned actions with dates. Typical first actions are written declaration criteria (DE.AE-08), a notification matrix (RS.CO-02), automated inventories of assets and credentials (ID.AM-01, ID.AM-02, PR.AA-01) and clean-restore validation (RC.RP-03).
- Update policy and plans: fold the outcomes into the incident response policy and plan, synchronised with business continuity (ID.IM-04.R1). The Incident Response Plan Template provides the plan structure.
- Pilot: test the updated plan on one scenario in a tabletop with suppliers (ID.IM-02), including a credential-compromise scenario, before rolling it out. Keep the previous plan version approved and available until the exercise shows the new one works.
- Automate carefully: introduce automated containment (RS.MI-01.C1) in alert-only or approval mode first, measure false positives, then enable automatic action for well-understood cases with a documented way to reverse it.
- Review cycle: re-score the profile after every major incident and at least annually (ID.IM-01, ID.IM-04.R2).
Evidence and assessment
Because every item has an ID, assessment evidence can be filed against it. The table lists evidence an assessor or auditor would expect for the core rows.
| Row | Evidence |
|---|---|
| GV.RR-02, GV.OC-03 | Approved policy naming roles and authorities; register of notification obligations by jurisdiction and contract |
| ID.AM-01, ID.AM-02, PR.AA-01 | Inventory exports with last-updated timestamps; service account and credential inventory with owners |
| DE.AE-08, RS.MA-02, RS.MA-03 | Declaration criteria; incident tickets showing triage, category, priority and strategy decision |
| RS.AN-06, RS.AN-07 | Evidence log, access controls on case records, retention settings (SP 800-53 AU-9, AU-11) |
| RS.CO-02 | Notification matrix; sent notifications with timestamps and approvals |
| RS.MI-02, RC.RP-05 | Credential rotation and revocation records; scans of restored systems before return to service |
| RC.RP-06, ID.IM-03 | After-action reports and a tracked list of improvement actions with closure dates |
| ID.IM-02, PR.AT-02 | Exercise reports including supplier participation; role-based training records |
Metrics that show the profile is working:
- Percentage of High-priority rows assessed as achieved, tracked per assessment cycle.
- Median time from first alert to declaration, and from declaration to containment.
- Percentage of incidents closed with an after-action report within an agreed period (for example 30 days).
- Percentage of improvement actions from after-action reports and exercises closed by their due date.
- For credential incidents, time from declaration until every exposed secret is rotated or revoked, and the count of old secrets still seen in use afterwards.
- Number of exercises per year that include at least one supplier.
Mapping to other frameworks
Rev. 3 is itself built on CSF 2.0, and NIST publishes mappings to other resources through the Cybersecurity and Privacy Reference Tool. The cross-reference below is this guide's, not NIST's. SP 800-53 identifiers were checked against the Rev. 5 catalogue.
| Rev. 3 area | SP 800-53 Rev. 5 | CIS Controls v8.1 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Policy, plan and roles (GV.RR-02, ID.IM-04) | IR-8 Incident Response Plan | 17.1, 17.4, 17.5 | A.5.24 |
| Training (PR.AT-02) | IR-2 Incident Response Training | 14 (security awareness and skills training) | A.6.3 |
| Exercises and improvement (ID.IM-02, ID.IM-03) | IR-3 Incident Response Testing | 17.7, 17.8 | A.5.27 |
| Detection, declaration, triage (DE.AE, RS.MA) | IR-4 Incident Handling; IR-5 Incident Monitoring; AU-6 | 17.9 thresholds; 8 (audit logs) | A.5.25, A.6.8 |
| Containment and eradication (RS.MI) | IR-4, IR-4(1) Automated Incident Handling Processes | 17.4 | A.5.26 |
| Evidence (RS.AN-06, RS.AN-07) | AU-9, AU-11 | 8 | A.5.28 |
| Notification (RS.CO-02) | IR-6 Incident Reporting; SR-8 Notification Agreements | 17.2, 17.3, 17.6 | A.5.24, A.5.26 |
| Recovery (RC.RP) | CP-9 System Backup; CP-10 System Recovery and Reconstitution | 11 (data recovery) | A.5.29, A.5.30 |
| Credentials (PR.AA-01, RS.MI-02) | AC-2, IA-4, IA-5 | 5, 6 | A.5.16, A.5.17 |
| Outside help (GV.SC-08) | IR-7 Incident Response Assistance | 17.2 | A.5.19, A.5.24 |
See the NIST SP 800-53 Guide for the IR family in control terms.
Common pitfalls
- Reading Rev. 3 as Rev. 2: teams look for the handling checklists that were removed and conclude there is nothing to implement. The requirements are in the R items of the profile tables.
- Assessing only Respond: ignoring Medium Govern and Identify rows such as GV.OC-03 and ID.AM-02 leaves notification duties and inventories, the two things that slow every real incident, outside the assessment.
- Eradication without full scope: RS.MI-02.R1 asks for all affected hosts and services. Rotating the credential that was seen while leaving others in place invites a second incident, as the Internet Archive breach 2024 showed when unrotated Zendesk keys led to a second breach within a month.
- Underestimating magnitude: RS.AN-08 asks for magnitude to be estimated and validated. The LastPass breach 2022 shows how stolen DevOps secrets can reach far beyond the first system compromised.
- Restoring compromised backups: skipping RC.RP-03 checks and restoring images or secrets the attacker had already altered or copied.
- No after-action report: closing tickets without RC.RP-06.R1 reports, so ID.IM-03 has nothing to learn from and the same gaps recur.
Practitioner checklist
- Replace references to SP 800-61 Rev. 2 and its four phases in policies, contracts and audit criteria with Rev. 3.
- Score your current profile against every High row in Tables 2 and 3, citing R, C and N items by ID.
- Write declaration criteria and name who may declare an incident (DE.AE-08).
- Maintain a notification matrix covering laws, regulators, contracts and law enforcement (GV.OC-03, RS.CO-02).
- Keep automatically updated inventories of assets, services and the credentials they hold, with owners (ID.AM-01, ID.AM-02, PR.AA-01).
- Monitor authentication by users and service identities for credential misuse (DE.CM-09.R2).
- Include key, token and certificate rotation in eradication, and verify scope before closing (RS.MI-02).
- Validate backups and restored systems for compromise before return to service (RC.RP-03, RC.RP-05).
- Exercise the plan with suppliers at least annually and track improvement actions to closure (ID.IM-02, ID.IM-03).
- Produce an after-action report for every significant incident (RC.RP-06).
Standards and references
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile
- NIST: SP 800-61 Rev. 3 (PDF)
- NIST: NIST Revises SP 800-61, Incident Response Recommendations and Considerations
- NIST: SP 800-61 Rev. 2, Computer Security Incident Handling Guide (withdrawn)
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: Steal Application Access Token
Related NHI Mgmt Group resources: Incident Response Guide · Incident Response Plan Template · Incident Response Maturity Model · NIST CSF 2.0 Guide · Identity Incident Response Playbook