We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

FAQGLOBALNIST SP 800-61 Rev. 3

NIST SP 800-61 Rev. 3 incident response What should recovery include in a NIST SP 800-61 Rev. 3 incident response process

Recover services in a secure, authorized order; verify and restored systems; confirm normal operation with system owners; and close recovery against documented criteria.

Recovery may begin during or after response. The incident response plan, mission priorities, dependencies, available resources, and the incident's known and assumed characteristics control the timing and scope.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
2 sections4 primary sources
Overview

should select, scope, prioritize, authorize, and perform restoration actions securely. Before use, check backups and other for compromise, corruption, and integrity problems. Before returning a restored system to production, check it for compromise, remediate the incident's root causes, verify that the restoration is correct and adequate, and have the responsible system owner confirm normal operation. Declare the end of recovery only against documented criteria and complete the incident record. NIST SP 800-61 Rev. 3 is April 2025 guidance; it does not set universal recovery-time or recovery-point targets.

Search this module

Find a question or answer quickly

2 of 2 questions
Question 1

What should recovery include in a NIST SP 800-61 Rev. 3 incident response process?

Apply the plan's recovery-initiation criteria to what is known and assumed about the incident, including the disruption recovery itself may cause. Recovery can start during or after response, so containment, , investigation, and restoration may overlap. Record the decision, authorization, dependencies, residual uncertainty, and any reason to delay or change a planned action.

Select actions using the incident-response plan, available resources, mission priorities, timeliness, precision, and reliability. NIST examples include restoring from clean backups, rebuilding systems, replacing compromised files with clean copies, installing patches, changing passwords, and tightening security controls. If a sophisticated threat actor's full tactics remain unknown, replacing compromised hardware may be necessary; treat that as a case-specific option, not a default.

Choose the scope deliberately. Restoring only affected files may be faster and more precise, while rebuilding a broader set of systems may provide more confidence when magnitude or persistence remains uncertain. Reassess the plan when incident facts, business needs, dependencies, or available resources change and record why the selected action changed.

Before using , check them for indicators of compromise, corruption, and other integrity problems. Before production use, check restored assets for compromise, remediate root causes, and verify that each restoration is correct and adequate. A successful boot or completed backup job is not enough if the service is still unsafe, incomplete, or unable to meet its approved operating need.

Validate that essential services return in the appropriate order, monitor restored systems to test whether restoration is adequate, and have system owners confirm successful restoration and normal operation. Coordinate progress with designated internal and external stakeholders, follow supplier information-sharing clauses, and use approved methods for public updates.

Declare recovery complete only when the plan's criteria are met. Complete the incident documentation and after-action report, but keep longer-running remediation or improvement work open under its own owner and acceptance condition. Applicable contracts, continuity plans, legal duties, or sector requirements may impose recovery targets or evidence beyond Rev. 3.

  • Apply documented initiation criteria, account for possible disruption, and tell everyone with recovery duties which plan and authorization applies.
  • Verify backup and restoration-asset integrity before use, then check restored assets for compromise and correctness.
  • Restore essential services in the approved order and have system or asset owners confirm normal operations.
  • Communicate restoration progress securely under response plans, information-sharing agreements, supplier contracts, and approved public methods.
  • Declare the end of recovery against documented criteria, complete the incident record and after-action report, and route lessons through ID.IM.
  • Record residual risks, temporary workarounds, unavailable dependencies, monitoring conditions, and the owner and due date for work that remains after operational restoration.
  • Reopen or revise recovery when monitoring finds renewed compromise, performance is inadequate, a restored dependency fails, root-cause remediation proves incomplete, or the system owner withdraws acceptance.
Question 2

What practical checklist should teams use for recovery under NIST SP 800-61 Rev. 3 incident response?

The recovery record should show the initiation decision, what was restored, why actions were prioritized in that order, who authorized and performed them, how and restored systems were checked, what root causes were remediated, how restored systems were monitored, and who confirmed operational readiness. Record changes to the plan as needs, resources, or incident facts change.

For each restored service, retain the dependency and priority decision, selected recovery source, integrity result, change or rebuild record, compromise checks, functional test, monitoring result, owner acceptance, and time returned to service. Note uncertainty and residual risk instead of presenting partial restoration as complete.

For recovery closure, retain the criteria applied, approving authority, unresolved work, status communications, final operational confirmation, completed incident documentation, and links to the after-action report and ID.IM actions. A later recurrence or failed acceptance condition should create a new decision record or reopen recovery under the organization's procedure.

  • Recovery scope, service priorities, selected actions, authorizations, owners, and dependencies.
  • Backup or restoration-asset integrity results and indicators-of-compromise checks.
  • Root-cause remediation, restored-asset validation, monitoring, and asset-owner acceptance.
  • Status communications, recovery-end declaration, completed incident documentation, and improvement actions.
  • Temporary workarounds, residual risks, operating restrictions, follow-up owners, due dates, and acceptance conditions.
  • Reassessment trigger, changed action, approving decision, and evidence that the revised restoration worked.
Recommended next step

Define recovery checks and closure authority

Assign restoration owners, check restoration assets and recovered services, and record the recovery completion decision.

Assessment workflow
Open Assessment Autopilot for NIST SP 800-61 Rev. 3

Create cited tasks, evidence requests, and review checkpoints for this NIST SP 800-61 Rev. 3 scope.

Explore next step
Talk to Sorena
Review this NIST SP 800-61 Rev. 3 scope with Sorena

Review decision authority, procedures, evidence gaps, and exercise results for this incident-response scope.

Explore next step
Primary sources

References and citations

NIST SP 800-61 Rev. 3 Incident Response
csrc.nist.gov3 citations
Referenced sections
  • Official final publication page and document history for the April 2025 CSF 2.0 incident response Community Profile.
  • Supports recovery initiation, secure action selection, restoration-asset checks, restored-system validation, communication, and closure.
  • Supports the recovery record, including priorities, authorization, integrity checks, root-cause remediation, monitoring, and owner confirmation.
"incident response recommendations and considerations"
NIST CSF 2.0 (CSWP 29)
doi.org
Referenced sections
  • Primary NIST source for the CSF Core, Organizational Profiles, Tiers, and implementation approach.
"does not prescribe how outcomes should be achieved"
NIST SP 800-61 Rev. 3 DOI
doi.org
Referenced sections
  • DOI for the April 2025 incident response publication.
"incident detection, response, and recovery activities"

Related guides

Event vs. Incident in NIST SP 800-61 Rev. 3

An event is observable activity. Declare an incident when analysis shows the occurrence meets documented cybersecurity incident criteria.

How should teams handle communications under NIST SP 800-61 Rev. 3 incident response?

Plan incident coordination, formal notifications, public communication, and voluntary information sharing under NIST SP 800-61 Rev. 3.

How should teams handle lessons learned under NIST SP 800-61 Rev. 3 incident response?

Capture incident-response lessons as they emerge, prioritize them through CSF 2.0 Improvement, and verify changes to plans, controls, training, and recovery.

How should teams handle post-incident evidence under NIST SP 800-61 Rev. 3 incident response?

Preserve incident records, collected data, metadata, integrity, provenance, access controls, and retention decisions under NIST SP 800-61 Rev. 3.

How should teams handle reporting clocks under NIST SP 800-61 Rev. 3 incident response?

NIST SP 800-61 Rev. 3 sets no universal reporting deadline. Build a clock register from each applicable law, regulation, policy, and contract.

How should teams handle severity under NIST SP 800-61 Rev. 3 incident response?

NIST SP 800-61 Rev. 3 sets no universal severity scale. Use documented risk factors to estimate severity and urgency, prioritize response, and reassess.

Show all related guides (20)

Which CSIRT roles should teams define under NIST SP 800-61 Rev. 3?

Define incident-response leadership, handlers, technical specialists, legal, communications, HR, facilities, asset owners, and providers under NIST SP 800-61 Rev. 3.

NIST SP 800-61 Rev. 3 CSF 2.0 Incident Profile Guide

Map NIST SP 800-61 Rev. 3 across CSF 2.0 preparation, Detect-Respond-Recover operations, and continuous improvement without treating the profile as a law or playbook.

NIST SP 800-61 Rev. 3 FAQ: practical implementation questions

Answers on incident declaration, severity, roles, communications, notification clocks, evidence, recovery, and continuous improvement under NIST SP 800-61 Rev. 3.

NIST SP 800-61 Rev. 3 Incident Communications and Escalation

Separate incident coordination, notification, public communication, information sharing, escalation, and elevation, with owners and decision records.

NIST SP 800-61 Rev. 3 Incident Response Playbook Template

Build a scenario-specific incident playbook with declaration criteria, authority, third-party coordination, response evidence, legal overlays, and recovery exit criteria.

NIST SP 800-61 Rev. 3 Incident Severity and Response Targets

Build organization-defined incident severity bands and response targets from NIST risk factors without claiming that NIST prescribes levels or deadlines.

NIST SP 800-61 Rev. 3 Post-Incident Evidence Log Workflow

Preserve incident records and data, document recovery, produce the after-action report, and verify corrective actions under NIST SP 800-61 Rev. 3.

NIST SP 800-61 Rev. 3 vs CISA playbooks: practical side-by-side comparison

Choose NIST SP 800-61 Rev. 3 for an organization-wide incident-response risk model and CISA's playbooks for detailed FCEB incident and vulnerability procedures.

NIST SP 800-61 Rev. 3 vs ISO 22301 business continuity: practical side-by-side comparison

Use NIST SP 800-61 Rev. 3 for cybersecurity incident response and ISO 22301:2019 with Amendment 1:2024 for the business continuity management system.

NIST SP 800-61 Rev. 3 vs ISO/IEC 27035: practical side-by-side comparison

Compare NIST SP 800-61 Rev. 3's CSF 2.0 outcome profile with the ISO/IEC 27035 incident-management process, planning, and ICT response guidance.

NIST SP 800-61 Rev. 3 vs NIS2 incident reporting: practical side-by-side comparison

Use NIST SP 800-61 Rev. 3 to run incident response and the applicable NIS2 national law to assess significant-incident reporting and legal deadlines.

NIST SP 800-61 Rev. 3: escalation decision workflow for incident communications

Run incident coordination, required notifications, public updates, and voluntary information sharing as separate, documented decision streams.

NIST SP 800-61 Rev. 3: What Changed from Rev. 2

See how NIST SP 800-61 Rev. 3 replaced Rev. 2's incident-handling guide with a CSF 2.0 Community Profile and what teams should update.

Using NIST SP 800-61 Rev. 3 for Incident Response

Use NIST SP 800-61 Rev. 3 to assign incident-response outcomes, owners, records, communications, and improvements while tracking binding duties separately.