NIST SP 800-61 incident response recommendations

What it is

NIST Special Publication 800-61 Revision 3, "Incident Response Recommendations and Considerations for Cybersecurity Risk Management," is an April 2025 publication from the National Institute of Standards and Technology. It replaces the 2012 "Computer Security Incident Handling Guide" with a different kind of document: rather than a step-by-step procedure for handling an incident, it is a CSF 2.0 Community Profile, "a baseline of CSF outcomes that is created and published to address shared interests and goals for reducing cybersecurity risk among a number of organizations." It maps incident-response work onto the six Functions of the NIST Cybersecurity Framework (CSF) 2.0, Govern, Identify, Protect, Detect, Respond, Recover, and rates each Function, Category and Subcategory's relevance to incident response as High, Medium or Low, attaching a recommendation, a consideration, or a note to the higher-priority ones.

NIST developed the Profile under its own statutory role for federal information security, and describes it beyond that as something that "may be used by nongovernmental organizations on a voluntary basis." It sets no methodology anyone must follow to the letter and names no certification, accreditation or audit scheme against which conformance to it is checked. Its own Audience section says it "is intended for use by most organizations, regardless of sector, size, or other factors."

Who has to care

The document names cybersecurity program leadership and cybersecurity personnel first, then widens considerably: incident handlers, whether on staff, on contract, or available when needed through a provider such as a managed security services provider; technology professionals; legal; public affairs and media relations; human resources; physical security and facilities management; asset owners; and third parties under contract, including cloud and internet service providers who may hold their own incident-response obligations under a shared-responsibility model. For an organization outside the federal government, the practical trigger is usually a customer's security questionnaire or an incident-notification obligation that already uses this vocabulary, since the document itself creates no obligation on its own.

How the Profile is organized

The Profile's substance sits in two tables mapped to the CSF 2.0's Functions, Categories and Subcategories. Each row carries a priority, High, Medium or Low, for incident response specifically, and where relevant one or more lettered items: "R" for a recommendation ("something the organization should do"), "C" for a consideration ("something the organization should consider doing"), and "N" for a note. Table 2 covers Preparation and Lessons Learned (Govern, Identify, Protect); Table 3 covers Incident Response itself (Detect, Respond, Recover), where "all CSF elements in this part have recommendations or considerations," unlike Table 2, where most Govern rows carry none.

Govern and Identify set up the response before it is needed. Cybersecurity policy "should include an incident response policy," and roles, responsibilities and authorities "should include incident response," spanning third parties under contract, and "relevant suppliers and other third parties are included in incident planning, response, and recovery activities." Asset inventories let responders understand what an incident touched, and risk assessment supplies threat intelligence and a defined set of risk responses. Improvement, rated High, means identifying gaps "from evaluations," "from security tests and exercises, including those done in coordination with suppliers and relevant third parties," and from every operational process actually run, feeding an incident response plan that is kept "established, communicated, maintained, and improved" and synchronised with business continuity plans.

Detect, Respond and Recover carry the Profile's High-priority weight throughout. Detection is continuous monitoring across networks, the physical environment, personnel activity, external service providers, and computing hardware and software, followed by analysis that correlates findings and declares an incident once it meets defined criteria. Response triages and categorises incidents, explicitly rejecting a "first-come, first-served basis"; preserves the "integrity and provenance" of investigation records; notifies stakeholders in line with applicable laws; and contains and eradicates the incident, manually or through automation. One requirement worth knowing about: deliberately delaying containment to observe an attacker in a sandbox "should first discuss the feasibility of this strategy with the legal department before executing it," since the delay itself can let an attacker escalate. Recovery verifies the integrity of backups "before using them for restoration," restores essential services in the right order, and closes with "an after-action report that documents the incident itself, the response and recovery actions taken, and lessons learned."

What a reviewer looks for across all of this is an artefact trail rather than a certificate: a written incident-response policy and plan, named authorities for who can disconnect an asset, monitoring output tied to declared incidents, records of containment and eradication decisions, tested backups, and an after-action report per major incident.

How it is evaluated

There is no certification, accreditation, or notified-body scheme for SP 800-61r3. It is a Community Profile that organizations are explicitly invited to customize: "these priorities are intended as a starting point for organizations, who are encouraged to customize this Community Profile to reflect their own priorities and needs." Where evaluation happens, the document keeps it separate from any conformance test. Internally, Improvement recommends periodically evaluating "incident response program performance to identify problems and deficiencies that should be corrected," naming "self-assessments, third-party assessments, and independent audits" as possible forms, an organization checking itself rather than a body certifying it. For a US federal agency, whatever external oversight exists runs through the wider FISMA and OMB Circular A-130 machinery this publication says it is "consistent with," not through an audit of this document's own text. Outside federal government, the only external check most readers meet is a customer's security questionnaire or contract clause referencing the underlying CSF.

Standards it references

The Profile is built on the NIST Cybersecurity Framework (CSF) 2.0, whose Functions, Categories and Subcategories structure both of its tables, and it supersedes its own prior edition, NIST SP 800-61 Revision 2 (2012). It names a further set of NIST publications as supporting reading rather than binding requirements: SP 800-150 (cyber threat information sharing), SP 800-92r1 (log management), SP 800-84 (test, training and exercise programmes), SP 800-184 (cybersecurity event recovery), SP 800-216 (federal vulnerability disclosure), SP 800-218 (secure software development), SP 800-30r1 (risk assessment), SP 800-37r2 (the Risk Management Framework), and SP 800-160v1 (engineering trustworthy secure systems), alongside the CISA Cybersecurity Incident & Vulnerability Response Playbooks for worked procedure examples. None of these are resolved in our catalogue against this record, so they are named here rather than linked.