What NIST SP 800-61 Rev. 3 changed for incident response
NIST SP 800-61 Rev. 3 replaces Rev. 2 of August 2012 and is organized as a CSF 2.0 Community Profile, so a program owner or customer who asks for incident response aligned to CSF 2.0 now has a NIST document that speaks the framework's own language. The publication, *Incident Response Recommendations and Considerations for Cybersecurity Risk Management*, was issued in April 2025. Its recommendations are no longer a separate incident response life cycle that you map to the framework afterward. Instead, each recommendation attaches to a CSF Function, Category or Subcategory, which makes the document easier to compare against your existing Current and Target Profiles. The revision treats all six Functions as part of incident response. Govern, Identify and Protect prepare the organization and feed lessons back into the program, while Detect, Respond and Recover handle discovery, containment, eradication, recovery, reporting and notification. Two decisions remain yours. First, the organization owns its response program, including who holds authority to declare an incident and how escalation works. Second, the document says organizations should use whichever life cycle model suits them best, so you decide whether to keep your current structure, adopt the Function-based model, or run both during a transition. Confirm which model your contracts, regulators and internal auditors reference before you restructure your runbooks.
A practical first check is to take your existing incident response plan and tag each section to the Function it serves. Gaps usually appear in Govern and Identify, where roles, risk decisions and lessons-learned loops are often undocumented, and in Recover, where backup verification and post-incident norms are easy to skip. Use the NIST Cybersecurity and Privacy Reference Tool (CPRT) resources that the publication points to for each Function, Category and Subcategory, since NIST moved those links to an Incident Response project page so they can change without a new revision. Ask your incident response vendor or implementation partner to show how their deliverables map to these Functions. A partner can prepare the runbooks, tabletop evidence and tooling, but the organization must approve the plan and an independent assessor, if one is engaged, judges whether the controls work.
Who should use this profile and in what role
Cybersecurity program leaders, such as the CISO or head of security, use SP 800-61 Rev. 3 to decide how incident response fits into the wider cybersecurity risk program. Because the publication is organized around the six CSF 2.0 Functions, leaders can read it alongside their Govern outcomes, such as risk management strategy and roles and authorities, and set priorities across prevention, detection and recovery. The profile informs how much investment goes into each part of the life cycle, who is accountable for decisions during an incident, and how lessons learned feed back into policy. It does not decide whether a specific event is reportable, which notifications are owed to regulators or customers, or what the organization says publicly. Those belong to legal counsel, privacy officers and the executives who own the relevant obligations.
- Priority setting: Use the Govern, Identify and Protect outcomes to decide where preparation effort reduces the most incident impact.
- Accountability: Confirm who can declare an incident, approve containment with business impact and authorize recovery.
- Lessons learned: Require that post-incident reviews change plans, controls and budgets, not only reports.
- Outside the profile: Notification deadlines, legal privilege and regulator contact stay with counsel and the compliance function.
Before relying on this tab, confirm which external reporting duties apply to your organization and where they are documented.
Security operations, incident response and threat detection staff are the main users of the publication's technical recommendations. They use the Detect, Respond and Recover Functions to plan how events are found, triaged, analyzed, contained, eradicated and restored. SP 800-61 Rev. 3 points to the CPRT online resources mapped to each Function, Category and Subcategory, so practitioners can connect their playbooks to other standards they already use. The profile informs how analysts classify and prioritize incidents, how evidence is preserved, and which containment actions are documented. It does not set the organization's risk appetite for downtime or decide which business services are shut down, since those trade-offs belong to system owners and executives.
- Playbook design: Map existing runbooks to RS.MA, RS.AN, RS.CO, RS.MI and RC.RP to find gaps.
- Evidence handling: Define how incident data is preserved so that later analysis and any legal review can rely on it.
- Analysis depth: Build root cause and magnitude estimates into the workflow, not only the initial alert.
- Recovery verification: Test that backups and restored assets are checked before recovery is declared complete.
Check that your tooling, logging and ticketing systems can produce the records that each playbook step depends on.
System administrators, application owners, help desk staff, facilities and business unit leads each play a part in preparing for, detecting, responding to or recovering from incidents, even when they are not security specialists. For them, the profile is most useful as a reference for what is expected of their role during each phase. It informs how they report suspicious activity, how they follow isolation and recovery instructions, and how they take part in exercises and reviews. It does not define personal liability, disciplinary outcomes or the content of external statements, which are decided by human resources, legal and communications teams.
- Reporting: Set clear channels and expectations so staff escalate suspicious events quickly and without guessing.
- Preparation: Ensure system owners maintain current asset and contact information that responders need during an event.
- Exercises: Join tabletop and technical exercises so that recovery steps are tested before a real incident.
- Restoration: Agree in advance which business services come back first and who approves the restoration.
Confirm that each operational team knows its incident role, its escalation contact and where the current response plan is stored.
Using the CPRT resources mapped to each Function, Category and Subcategory
SP 800-61 Rev. 3 does not carry its supporting resources inside the publication. Instead, it points readers to the NIST Cybersecurity and Privacy Reference Tool, where online resources are mapped to each CSF 2.0 Function, Category and Subcategory. The cards below cover what that mapping contains and how to use it safely.
The CPRT mapping structure
The Reference Tool links online resources to each CSF 2.0 Function, Category and Subcategory. For incident response, that means you can start at a Category such as Incident Analysis (RS.AN) and see the supporting material for each Subcategory beneath it. Read the mapping as the index to the guidance, not as a substitute for the publication's recommendations. Your team should work from the Subcategory level so each resource is tied to a specific outcome you can test.
Cross-references to other IR standards
The CPRT mappings include references to other incident response standards, so one Subcategory can point to several bodies of guidance. This helps a team that already follows a different incident handling model and needs to show how its procedures line up with the CSF Functions. Before you record a crosswalk as a control mapping in your evidence set, confirm the exact reference, edition and version directly in the Reference Tool, because mappings can be updated.
Moved links and the IR project page
NIST moved the resource links from SP 800-61 Rev. 3 to an Incident Response project page so it can update them without reissuing the publication. A link that worked when you first cited it may now point elsewhere or to a newer version. Check the project page before each audit cycle, and record the date and URL of every resource you rely on in your incident response plan so an assessor can trace what you reviewed.
Keeping a dated resource register
Maintain a short register that lists each CPRT resource you adopt, the Subcategory it supports, the owner who reviews it, and the date you last confirmed the link. This turns a moving reference into a stable control record. Assign one owner from the incident response function and set a review trigger tied to your normal plan review, so stale links are caught before a tabletop exercise or regulator request exposes them.
Mapping resources to your own procedures
The mapping tells you what external guidance exists for each outcome, but it does not tell you whether your runbooks meet it. Walk each relevant Subcategory against your playbooks, escalation paths and reporting duties, and note the gaps. Where a resource covers reporting or notification, check it against the deadlines in your own contracts and regulations, since the mapping does not set those obligations.
Questions to put to your team
Ask which CPRT resources the incident response lead has reviewed, which links are current on the project page, and which mapped references your organization has formally adopted. Ask whether anyone owns the register and how changes to the mapping reach the people who run the playbooks. Clear answers show that the resources are in use. Vague answers suggest the mapping is a bookmark rather than a working control.
How an organization adopts the profile as a target
This sequence turns SP 800-61 Rev. 3 from a reference document into a working Target Profile, with a recorded starting point, prioritized gaps, named owners and a feedback loop from lessons learned back into governance and improvement. NIST does not give a duration for this work, so the timeline should be set by each organization.
Inventory existing incident response documents
Collect every current incident response artifact, including the plan, runbooks, escalation contacts, playbooks, reporting procedures and recovery procedures. Sort each one against the six CSF 2.0 Functions (Govern, Identify, Protect, Detect, Respond and Recover) so you can see which Functions your documents already cover and which they ignore. Incident response leads and the cybersecurity program owner usually do this together. The step is complete when every document has at least one Function mapped to it and the unmapped gaps are listed.
Record the Current Profile
Write down, Subcategory by Subcategory, how your incident response activities work today. Use the CSF 2.0 Reference Tool and the Implementation Examples linked from SP 800-61 Rev. 3 as prompts, and base each entry on evidence such as tickets, exercise records or logs rather than on memory. Mark each Subcategory as achieved, partially achieved or not achieved. The step is complete when the Current Profile is approved by the people who run incident response and can be traced to supporting evidence.
Set the Target Profile from organizational risk
Decide the outcomes your organization needs for incident response, using your risk assessment, business impact analysis, regulatory obligations and customer or supplier requirements. Leadership should approve the target, because it expresses risk appetite, not only technical preference. Choose a Tier target where it helps communicate maturity. The step is complete when a signed Target Profile states which Subcategories must be achieved, to what degree, and why each matters to the business.
Identify gaps and assign owners
Compare the Current Profile with the Target Profile and list every Subcategory where the gap is material. Group the gaps by Function and by the team that would fix them, such as security operations, IT operations, legal, communications or executive leadership. Give each gap a named owner and record the dependencies between them, for example a logging gap that blocks detection and analysis. The step is complete when every material gap has one accountable owner and a recorded priority in the risk register.
Close gaps and test response procedures
Owners implement the agreed changes, such as updating runbooks, adding detection sources, clarifying reporting duties or documenting recovery steps. Test the changed procedures in tabletop or technical exercises so that the documents match what responders actually do. Keep the exercise records, since they are the evidence that the outcome is achieved. The step is complete when each closed gap has a changed artifact and at least one recorded test or exercise that exercised it.
Feed lessons learned into Govern and Improvement
After each real incident and exercise, hold a review that records root causes, decisions, missed steps and needed changes. Route policy and risk-related findings to Govern, including the risk management strategy, roles and oversight, and route procedural findings to the Improvement Subcategories under Identify. Assign each finding an owner and a due date set by the organization. The step is complete when the review records show where each lesson changed a policy, plan or the Target Profile.
Reassess the profile on a set cycle
Repeat the Current Profile review at a cycle the organization sets, and whenever the threat environment, technology, organization structure or regulatory obligations change. Compare the new Current Profile with the previous one and update the Target Profile if risk has shifted. Check the NIST updates archive for changes to the referenced resources. The step is complete when the leadership-approved profiles, the gap register and the change log show the current state and the reason for each change.
Rev. 2 versus Rev. 3: what a team must update
This table sets SP 800-61 Rev. 2, published in August 2012, beside Rev. 3, published in April 2025, across the areas a response team is most likely to change. Read each row as a question about your own documents: which life cycle your playbooks cite, which identifiers your evidence follows, and where your reference links point. The main takeaway is that Rev. 3 changes how recommendations are organized and where resources live, so existing plans may need re-mapping more than full rewriting.
| Area | SP 800-61 Rev. 2 (August 2012) | SP 800-61 Rev. 3 (April 2025) |
|---|---|---|
| Document status | Superseded by Rev. 3 | Current version; supersedes Rev. 2 |
| Life cycle structure | Earlier phase-based life cycle model | Life cycle based on the six CSF 2.0 Functions; teams may use whichever model suits them |
| Mapping to outcomes | Predates CSF 2.0, so no Function, Category or Subcategory mapping | Each Function, Category and Subcategory mapped to online resources |
| Role of Govern, Identify and Protect | Confirm how your copy addresses prevention and preparation | Help prevent incidents and improve from lessons learned |
| Resource location | References fixed in the 2012 publication; check for outdated links | Links moved to an Incident Response project page so NIST can update them |
| Mapping tool | Not built on the CSF 2.0 Reference Tool or CPRT | Points to the CPRT for resources and mappings to other incident response standards |
| Intended audience | Incident response teams and those handling incidents | Program leadership, cybersecurity personnel and others responsible for incident work, for most organizations |
| What to update | Confirm which phase names your playbooks, metrics and training cite | Re-map procedures to CSF 2.0 identifiers, then verify each CPRT link |
Mistakes teams make when they adopt the profile
SP 800-61 Rev. 3 is a guidance document built on the CSF 2.0 Functions, not an assessment scheme or a legal rulebook. Most adoption problems come from treating it as something it is not, or from letting its structure float free of named owners, current references and the notification duties it leaves to other sources.
Treating the profile as a certification
NIST does not certify anything against CSF 2.0 or its Community Profiles, and NIST has no plans for a conformity assessment program. Teams sometimes tell customers or boards that they are "compliant with SP 800-61 Rev. 3" when they have only mapped their program to it. Before using that language, confirm what an independent assessor or the customer contract actually asks for, and describe your alignment as a self-assessment unless an auditor has tested it.
Copying Functions into policy without owners
The six Functions are a way to organize the work, but a policy that says Detect, Respond and Recover will be "managed" names no one accountable. Assign a named owner to each Category you rely on, such as RS.MA for incident management or RS.CO for reporting and communication, and record who approves the incident response plan. Check that each owner can point to a current procedure, a runbook and a test date.
Relying on cached CPRT links
SP 800-61 Rev. 3 moved its resource links to an Incident Response project page so NIST can update them, and it points to the Cybersecurity and Privacy Reference Tool (CPRT) for mappings to Functions, Categories and Subcategories. Teams that saved links or spreadsheets from an early read will point auditors at outdated material. Re-pull the mappings from the live tool each review cycle, and record the date you checked them in your evidence folder.
Assuming the profile covers notification duties
The profile covers how incidents are handled and reported internally and externally in a cybersecurity sense, but the deadlines and recipients for legal and regulator notifications come from statutes, sector rules and contracts. A team that follows the profile perfectly can still miss a regulator clock. Build a separate notification matrix listing each obligation, its trigger, its deadline, its recipient and the person who signs off, and review it with legal counsel.
Picking a life cycle model by habit
SP 800-61 Rev. 3 replaces the older incident response life cycle with one based on the CSF 2.0 Functions and says organizations should use whichever model suits them best. Teams often keep the old phases in their runbooks while labeling them with Function names, which leaves gaps where Govern and Identify activities fall between documents. Choose one model, map every playbook step to it, and confirm that lessons learned flow back into the Improvement Subcategories under ID.IM.
Testing the plan once and filing it
The profile places preparation and improvement across Govern, Identify and Protect, but a tabletop exercise that was run once and never revisited shows little about current capability. Schedule exercises that exercise detection, containment and recovery against the systems you run today, and feed the findings into the plan. Ask whether each finding has a tracked action, a named owner and a closure date.
Questions buyers ask about SP 800-61 Rev. 3
Is NIST SP 800-61 Rev. 3 a certification?
No. SP 800-61 Rev. 3 is guidance, not a certification, and NIST does not offer certifications or endorsements of CSF-related products, implementations or services. It has no plans to create a conformity assessment program. Nobody can certify an organization as compliant with SP 800-61 Rev. 3 through NIST. What an organization can do is use the guidance to build and test its incident response program, then ask an independent assessor to review the evidence against its own stated scope. Any firm that promises an official NIST certificate for this publication is describing something NIST does not issue, so ask them to explain exactly what document they would produce and who would sign it.
Is SP 800-61 Rev. 3 mandatory for my organization?
Usually not on its own. NIST is not a regulatory agency, and most organizations use NIST guidance voluntarily. The publication itself is intended for most organizations regardless of sector or size. Obligations come from elsewhere: a customer contract, a sector regulator, or, for U.S. federal agencies, the executive order that made the CSF mandatory for them in 2017. Check whether your regulator, contract or insurer names NIST incident response guidance specifically, and whether it accepts an alignment statement or expects an independent review. Your legal or compliance team should confirm which obligations apply to your entity.
How does SP 800-61 Rev. 3 relate to NIST CSF 2.0?
SP 800-61 Rev. 3 is written as a CSF 2.0 Community Profile, so its recommendations are organized around the framework's six Functions: Govern, Identify, Protect, Detect, Respond and Recover. All six play a role in incident response. Govern, Identify and Protect help prevent and prepare for incidents and drive improvement from lessons learned. Detect, Respond and Recover help discover, contain, eradicate and recover from incidents and handle reporting and notification. The CSF 2.0 Core and its Categories and Subcategories supply the outcome language, and the CPRT resources map each one to the guidance. Organizations may still use whichever incident response life cycle model suits them best.
What does an incident response program need from internal staff?
Most of the work stays with your own people because the decisions are yours. Leadership must own the program, approve the scope and accept residual risk. Cybersecurity personnel must maintain detection, analysis, containment and recovery procedures and run exercises. Staff in legal, communications, HR, operations and business units need defined roles for reporting and notification. Expect the largest internal effort in deciding responsibilities, keeping plans current and producing records after each incident or exercise. Ask any partner which of these tasks they will perform, which they will only review, and which you must complete yourself before work starts.
Can a partner help prepare an SP 800-61 Rev. 3 adoption?
Yes, an implementation partner can help prepare systems, procedures and evidence aligned to the publication. DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and it runs security testing and private cyber ranges that can exercise response procedures. Ownership stays with you: the organization owns its controls and decisions, and DeployOpen does not issue audit reports, attestations or certifications. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Ask for the proposed deliverables and who signs off on each.
What would an independent assessor test in an incident response program?
An independent assessor, not NIST, would test whether your documented scope matches what operates in practice. Expect them to request the incident response plan, role assignments, and the mapping you used to connect procedures to CSF Subcategories. They will look for evidence that detection feeds triage, that escalation and reporting paths work, that containment and eradication steps are recorded, that backups and restored assets are verified, and that lessons learned change the plan. Records from past incidents and exercises usually carry the most weight. Confirm the assessment type, scope and evidence list with your chosen assessor before work starts.
Where to read the source documents first
Start with the primary text before relying on any summary, including this page. The publication page for NIST SP 800-61 Rev. 3 lists the document and its status, and the April 2025 PDF is the version to cite in a board paper, audit file or contract response. Check the front matter of the PDF for the publication date and confirm it supersedes SP 800-61 Rev. 2 of August 2012, so your team does not work from the retired model. Record the exact revision and date you reviewed, because the resource links in the document are maintained on a separate project page and may change after publication.
Next, read the life cycle section and the Function-by-Function discussion against your own incident response plan. Decide which of the six CSF 2.0 Functions your current plan already covers and which ones it treats as separate processes, such as reporting and notification handled by legal or a different team. Note any step you cannot map to an owner, since that gap is usually what an assessor will ask about first.
For Respond specifically, use the CSF 2.0 Reference Tool export to pull the Category and Subcategory text in one place. Respond contains four Categories (RS.MA, RS.AN, RS.CO and RS.MI), 13 Subcategories and 38 Implementation Examples in that export. Confirm the export version you download, since the Implementation Examples and informative references are updated separately from the CSF Core, and keep a dated copy alongside your mapping so the evidence trail stays traceable.
How DeployOpen helps teams align incident response to SP 800-61 Rev. 3
DeployOpen helps teams map their incident response plans, tooling and evidence onto the six CSF 2.0 Functions that SP 800-61 Rev. 3 uses as its life cycle. The organization keeps ownership of its incident response program, and DeployOpen prepares the systems, runbooks and records that show how the program works in practice.
How we scope
- Engagements are fixed-scope, with the systems, Functions and Subcategories in scope agreed in writing before work starts.
- The written scope names which incident response processes, teams and log sources the engagement covers in your environment.
- Scope also records which CSF 2.0 Subcategories from the Reference Tool your current incident response practices are measured against.
How we build
- Self-hosted open-source platforms are deployed inside your own cloud accounts, data centers or air-gapped networks, not in ours.
- Detection, case management and backup tooling is configured so that the records needed for analysis, reporting and recovery are captured.
- Runbooks and playbooks are drafted against the Govern, Identify, Protect, Detect, Respond and Recover Functions and tested through exercises you schedule.
How we hand over
- Deliverables include configuration records, mapping tables to CSF 2.0 Subcategories and the CPRT resources SP 800-61 Rev. 3 references.
- Documentation explains how each incident response step is evidenced, so your internal reviewers and independent auditors can follow the trail.
- Handover sessions walk your staff through the runbooks, dashboards and evidence locations before the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
- Retainers can cover updates when NIST revises SP 800-61 resources or informative references, which NIST publishes separately from the framework.
- Ask for a written quote based on your scope, and confirm with your auditor which evidence they will accept before work begins.
