NIST SP 800-61 Rev. 3 incident response 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, eradication, 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 restoration assets, 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.

The recovery record should show the initiation decision, what was restored, why actions were prioritized in that order, who authorized and performed them, how restoration assets 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.