TL;DR
- NIST SP 800-61r3 was finalized in April 2025 and supersedes Rev. 2.
- Rev. 3 treats incident response as part of organization-wide cybersecurity risk management and expresses recommended outcomes through the six NIST Cybersecurity Framework 2.0 Functions.
- Govern, Identify, and Protect support preparation; Detect, Respond, and Recover contain the cybersecurity incident-response outcomes; improvement feeds all six Functions.
- The publication is a Community Profile, not a detailed technology playbook. Organizations still need environment-specific procedures, decision rights, evidence requirements, suppliers, exercises, and recovery criteria.
What changed from Rev. 2
Rev. 2 is widely remembered for preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. Those concepts remain useful, but they are not the organizing structure of the current publication.
Rev. 3 aligns incident response with CSF 2.0. That change matters because response quality depends on choices made long before a detector fires. Governance defines authority and risk appetite. Identification supplies asset, dependency, and impact context. Protection can limit initial harm and preserve response options. Detection finds and analyzes adverse events. Response contains and communicates. Recovery restores prioritized outcomes. Lessons from any of those activities can change the others.
The publication also avoids becoming a catalog of perishable technical procedures. It points organizations toward current online resources for implementation detail while providing durable outcomes that leadership, incident handlers, technology teams, legal counsel, privacy, communications, human resources, suppliers, and recovery owners can share.
Read it as an operating model
SP 800-61r3 is most useful when each outcome is translated into an operating decision. For every relevant outcome, ask:
- Who is accountable?
- Which event or threshold activates the process?
- Which data and systems are authoritative?
- What decision must be made, by when, and by whom?
- Which external parties are required?
- What evidence proves the outcome worked?
- Which failure or change triggers review?
A document that says “contain the incident” is incomplete if nobody can isolate a workload, revoke a token, stop a payment, preserve legal evidence, or approve customer communication. A contact list is incomplete if it is unavailable during identity-provider or network failure. A backup is incomplete if restoration has not been tested against business recovery objectives.
Govern: establish authority before urgency
Governance makes response executable. Define roles, decision rights, escalation paths, reporting obligations, risk thresholds, and exception authority before an incident. Include executive leadership, legal, privacy, communications, business owners, technology teams, insurers, regulators, law enforcement, service providers, and suppliers as applicable.
Useful governance artifacts include:
- a current incident-response policy and plan;
- severity and declaration criteria;
- named incident command and delegated authority;
- out-of-band contact and coordination methods;
- legal, regulatory, contractual, and insurer notification triggers;
- evidence-handling and investigation rules;
- supplier responsibilities and service expectations;
- documented risk acceptance and exception expiry;
- exercise and improvement ownership.
Test authority in exercises. A tabletop should force decisions about production isolation, customer impact, executive notification, payment fraud, supplier evidence, and recovery tradeoffs. If every decision must wait for an unavailable person, the governance design has failed even if the plan is well written.
Identify: know what the event can affect
Triage depends on context. Maintain asset, service, data, identity, supplier, and dependency information at a level that supports impact analysis. The objective is not a perfect inventory for its own sake; it is the ability to answer which business services, customers, data, credentials, regions, and recovery paths are exposed.
Connect technical identifiers to service ownership and business priority. An alert naming a cloud account, workload identity, repository, object bucket, SaaS tenant, or certificate should resolve to an accountable owner and criticality. Map dependencies that can create hidden blast radius: centralized identity, DNS, build pipelines, shared observability, key management, managed service providers, and recovery infrastructure.
Risk assessment should include plausible incident scenarios, control assumptions, and uncertainty. Threat models and architecture reviews can supply abuse paths; incident history and near misses show which assumptions already failed. Feed those insights into detection coverage and exercises.
Protect: preserve options and limit harm
Protective controls are part of response readiness when they reduce blast radius or make containment possible. Examples include segmented identities and networks, least privilege, phishing-resistant administrator authentication, rapid credential revocation, immutable or protected logs, controlled administrative access, secure backups, recovery isolation, hardened builds, and supplier access boundaries.
Design controls for failure. If central identity is unavailable, responders may need controlled emergency access. If production is isolated, evidence and recovery channels must still work. If a key is suspected compromised, teams need tested rotation and data-recovery paths. Emergency mechanisms should be protected, monitored, exercised, and removed or resecured after use.
Training also belongs here. Role-specific preparation is more useful than generic annual awareness. Executives practice declaration and communication; engineers practice isolation and evidence preservation; finance practices payment fraud response; support teams practice verified customer and administrator channels.
Detect: turn telemetry into an incident decision
Detection is not synonymous with collecting logs. Define event sources, schemas, integrity, retention, correlation, baselines, analytics, thresholds, owners, and expected action. Monitor the health of the detection pipeline itself; a silent sensor or dropped event stream is a security condition.
An alert should carry enough context to support validation and scoping: actor and workload identity, time, action, resource, policy result, network or session context, service owner, correlation IDs, relevant configuration version, and source reliability. Preserve raw evidence where required, but avoid collecting sensitive data without a defined purpose and protection.
Analysis distinguishes an event from an incident and estimates scope, impact, urgency, and confidence. Record the evidence and assumptions behind classification. Severity should reflect business consequence and response need, not only a vendor's alert label.
Test detections end to end. Generate safe synthetic behavior, confirm the signal arrives, verify enrichment and routing, and make the assigned responder execute the first decision. A rule that fires but cannot be investigated is not operationally complete.
Respond: contain, communicate, and coordinate
Response includes incident management, analysis, reporting, communication, and mitigation. Establish an incident record with a clear timeline, decision log, ownership, hypotheses, evidence references, affected assets, and next review time. Separate observed facts from inference.
Containment should be tied to objectives and side effects. Revoking every session may stop account misuse but interrupt critical work. Network isolation may destroy a volatile evidence source or break recovery dependencies. The right action depends on safety, business impact, attacker persistence, evidence needs, and available alternatives. Preapproved playbooks can accelerate common actions without removing incident-command judgment.
Communication must use verified audiences and channels. Define what can be shared, who approves it, and how facts, uncertainty, and updates are represented. Internal responders, customers, regulators, insurers, suppliers, law enforcement, and the public may need different information at different times.
Supplier incidents require evidence and authority that contracts often fail to define. Know who can request logs, revoke access, isolate integrations, preserve data, and approve recovery. Exercise at least one scenario where a critical external service is degraded or suspected compromised.
Recover: restore trusted outcomes
Recovery is not simply bringing systems online. Establish recovery objectives, clean-state criteria, restoration order, validation, heightened monitoring, and transition back to normal operations. Rebuild trust in identities, keys, artifacts, configurations, data, and administrative paths as relevant.
Prioritize business outcomes and dependencies. A restored application may remain unusable if identity, DNS, certificates, data pipelines, communications, or supplier services are unavailable. Conversely, restoring a dependency too early can reintroduce compromise.
Validate backups and recovery infrastructure before incidents. Test restoration time, data integrity, access control, secrets, current patches, observability, and capacity. Protect recovery credentials and environments from the same failure domain as production.
Define exit criteria. Who declares containment sufficient, recovery accepted, and heightened monitoring complete? Which residual risks remain? Which customers or authorities require confirmation? A documented handoff prevents the incident from ending only because the bridge became quiet.
Improvement is continuous
Rev. 3 emphasizes improvement across the lifecycle. Do not wait for a ceremonial final report. A responder may discover during triage that asset ownership is missing, during containment that revocation is too slow, or during recovery that backup telemetry is absent. Route those findings immediately when delay creates risk.
Use a structured improvement record:
- observation and evidence;
- affected CSF outcomes and services;
- risk and recurrence conditions;
- corrective action and owner;
- acceptance criteria and verification;
- priority, target date, and dependencies;
- exception authority and expiry if deferred;
- evidence of closure.
Track themes across incidents and exercises. Repeated identity ambiguity may justify a platform control. Repeated supplier delays may require contract and integration changes. Repeated alert noise may indicate weak telemetry design rather than insufficient analyst effort.
A practical adoption sequence
Now
- Name incident-command authority and backups.
- Define declaration, severity, escalation, and external-notification criteria.
- Map the current plan to all six CSF 2.0 Functions and identify uncovered outcomes.
- Verify out-of-band contacts and emergency access.
- Select one high-consequence scenario for an end-to-end exercise.
Next 30–60 days
- Connect critical assets and alerts to service owners and business priorities.
- Test credential revocation, workload isolation, evidence preservation, customer communication, and supplier escalation.
- Validate recovery objectives and one representative restore path.
- Define detection-pipeline health measures and response service objectives.
- Turn exercise findings into owned, testable corrective actions.
Ongoing
- Review after material architecture, supplier, legal, or organizational change.
- Exercise technical, business, legal, communications, and recovery dependencies together.
- Measure time to decision and control effectiveness, not only alert and ticket counts.
- Feed lessons into risk registers, threat models, architecture, safeguards, detection, response, and recovery.
Evidence that the program works
Useful evidence includes:
- exercised decision rights and reachable alternates;
- end-to-end detection tests with investigation-ready context;
- measured isolation and revocation capability;
- protected, retrievable, and legally appropriate evidence;
- supplier response performance against agreed expectations;
- restored services meeting defined integrity and recovery criteria;
- corrective actions verified against their original failure mode;
- declining recurrence or blast radius for repeated incident classes.
Avoid treating plan approval, training completion, log volume, or tool deployment as sufficient evidence. They may be inputs, but outcomes require demonstration.
Caveats
SP 800-61r3 is a flexible profile. It does not replace sector rules, contracts, privacy and labor requirements, legal advice, digital-forensics procedures, safety engineering, or technology-specific playbooks. Organizations may keep a familiar incident lifecycle while mapping its outcomes to CSF 2.0.
This brief summarizes the current publication and preserves its freshness metadata. Use the primary publication for authoritative language and monitor NIST for errata or updates.