What is Recovery?

NIST defines the Recover function in one line: "Assets and operations affected by a cybersecurity incident are restored." SP 800-61 Rev. 3 (April 2025) lists what that involves: restoring systems from clean backups, rebuilding them, replacing compromised files with clean versions, installing patches, changing passwords and tightening security controls. If the attacker is highly sophisticated and the full scope of their activity is unknown, it adds, you may have to replace the hardware of every compromised system.

It is no longer a strictly final step. Rev. 2 put containment, eradication and recovery in one phase. Rev. 3 maps incident response onto CSF 2.0 and recommends that you "begin recovery procedures during or after incident response processes", so a file server can come back while the investigation of another segment is still open. The full model is on the incident response page. This page covers the restore itself: when to start, in what order, which backup to trust and when to call it done.

The Recover function in CSF 2.0: RC.RP and RC.CO

CSF 2.0 gives Recover two categories. Older material, including an earlier version of this page, also lists RC.IM for improvements. That category is from CSF 1.1. In 2.0, lessons from every function go to Improvement (ID.IM) under Identify.

The rest of the framework is on the NIST CSF page.

When to start

Restore a host while the attacker still has a way in and you have handed them a freshly built system. NIST SP 800-184, the agency's guide to cybersecurity event recovery, sets two conditions before the work starts in earnest: a basic understanding of what the adversary was after, and high confidence that you know how they kept access (or that they had no persistence). It also warns that starting too early can tip the adversary off, and a change in their tactics costs you the indicators you were tracking. Ransomware deadlines sometimes force a start on incomplete information. When that happens, write down which assumption you are gambling on. Removing persistence is eradication; stopping the spread is containment.

Restore order

Rev. 3 says to "validate that essential services are restored in the appropriate order". CISA's #StopRansomware Guide says to prioritize from a predefined critical asset list "as well as systems they depend on", to rebuild on a clean network and, if a new VLAN was created for the restore, to add only clean systems to it. Dependencies set the order. Nearly everything authenticates against the directory, so identity comes back before the servers that rely on it. The table is a starting point built on that logic, not a standard.

Stage 0 comes from SP 800-184, which lists out-of-band communication because production systems "are frequently monitored by advanced adversaries", along with a staging system to validate data restored from backups.

Vetting a backup before you restore it

RC.RP-03 is a single sentence. In practice it means five checks.

1. Date the initial access, not the encryption. CISA warns that a ransomware event "may be evidence of a previous, unresolved network compromise" and that dropper malware has to be found "before rebuilding from backups". The backup from the night before encryption usually still holds the foothold. In SP 800-184's ransomware scenario, the playbook is updated with the time of infection so the matching backups can be identified and checked.
2. Confirm the backup survived. CISA says most ransomware actors look for accessible backups to delete or encrypt them, and that synced cloud backups can overwrite good copies with encrypted files. Microsoft recommends immutable or fully offline storage, and an extra authentication step before anyone can change online backups.
3. Restore into staging and scan it. Search the restored copy for every hash, path, service, scheduled task and Run key on the case's indicator list, and check file integrity.
4. Inspect the directory backup before you boot it. Microsoft's Active Directory forest recovery guide describes mounting a backup with dsamain.exe and browsing it over LDAP, without restarting a domain controller in DSRM. Look for accounts and group memberships created after the initial access time. CISA lists newly created AD accounts and recent privileged activity among the things to hunt for.
5. Plan for what the backup brings back. A forest restore, Microsoft notes, loses every update made to existing objects since the backup. That includes the password resets from eradication, so stolen passwords work again. The entry vulnerability is back too, because the backup predates the patch. CISA puts password resets and patching after the environment is cleaned and rebuilt, and Rev. 3 asks you to fix the root cause before production use.

Microsoft's guide names the trade-off: a more recent backup recovers more data, "but it might increase the risk of reintroducing dangerous data". Restoring only the files you need, which Rev. 3 mentions under RC.RP-02, is how teams get the data back without the system state.

A simulated restore-point decision

Simulated example generated by SOCSimulator Research. Dates, hosts and names are invented.

INC-3318   file server FS02   nightly backups at 01:00 UTC, kept 45 days
 
2026-09-28 14:12  first attacker activity: loader runs on workstation WS-221
2026-09-30 22:47  scheduled task "OneDrive Sync Health" created on FS02
2026-10-14 03:05  encryption starts on FS02
 
Restore point      After first activity   Staging scan                     Used for
2026-10-13 01:00   yes                    task + loader DLL in system;     share files only
                                          share files clean
2026-09-30 01:00   yes                    nothing found                    not used
2026-09-28 01:00   no                     nothing found                    OS, applications, config

FS02 is rebuilt from the 09-28 restore point, the last one taken before the first known activity. The 09-30 copy scanned clean but is still rejected: it was taken after the attacker got in, and a clean scan only proves the absence of the indicators you already know. Losing 16 days of file changes is not acceptable, so document files from the share come from the 10-13 backup, scanned against the case IOCs, with no executables or scripts copied across. Before FS02 rejoins the network it gets every patch released since 09-28, and its local administrator password is rotated, because the 09-28 image brought the old one back.

Incident recovery vs disaster recovery

NIST SP 800-34 Rev. 1 describes a disaster recovery plan as one for "major, usually physical disruptions" that restores a system "at an alternate site after an emergency". SP 800-184 says cyber event recovery planning can live inside an existing disaster recovery or contingency plan, and Microsoft recommends exercising ransomware as seriously as a natural disaster. The two plans can share a document, but incident recovery starts from a different assumption: whoever caused the outage may still be inside.

Exit criteria

SP 800-184 recommends defining milestones and criteria for ending active work in advance, and notes that full restoration is not always practical in a reasonable time. One of its examples ends the effort once automated detection for the remaining affected systems is in place. CISA leaves the call to a designated IT or security authority, against established criteria. A workable checklist:

• every restored asset has been checked for the case IOCs (RC.RP-05);
• the root cause is fixed: entry point patched or closed, exposed credentials reset after the restore;
• system owners have confirmed normal operation (RC.RP-04);
• detections for the techniques seen in the incident are live and have been tested against the incident's own events;
• the after-action report is written (RC.RP-06), and status has gone to the people RC.CO-03 names.

Where these criteria sit in the plan, alongside the criteria for starting, is covered in the incident response plan template. Notification clocks that may run during recovery are on the escalation page.

What the SOC watches after go-live

SP 800-184 tells teams to monitor for the artifacts and evidence found during detection and response, and notes that a resource that has been attacked is often targeted again. In the watch window, look at restored hosts for:

• the case IOCs: hashes, domains and IPs from the investigation;
• new accounts and privileged group changes on restored domain controllers (events 4720, 4728, 4732 and 4756);
• tools CISA names as ways to stop a recovery: vssadmin.exe, wbadmin.exe, bcdedit.exe, fsutil.exe (deletejournal) and wmic.exe (shadowcopy);
• sign-ins by the reset accounts from hosts they do not normally use.

This query covers the first and third items for Defender XDR data in Microsoft Sentinel or advanced hunting:

// Watch window: case IOCs and recovery-inhibiting commands on restored hosts
let GoLive = datetime(2026-10-20T06:00:00Z);
let Restored = dynamic(["fs02", "sql01", "app03"]);
let CaseHashes = dynamic(["<SHA-256 values from the case>"]);
let CaseIPs = dynamic(["203.0.113.50"]);
let Inhibitors = dynamic(["vssadmin.exe", "wbadmin.exe", "bcdedit.exe", "fsutil.exe", "wmic.exe"]);
union
    (DeviceProcessEvents
    | where Timestamp > GoLive and DeviceName has_any (Restored)
    | where SHA256 in (CaseHashes) or InitiatingProcessSHA256 in (CaseHashes)
        or (FileName in~ (Inhibitors)
            and (FileName =~ "bcdedit.exe" or ProcessCommandLine has_any ("shadow", "shadowstorage", "resize", "delete", "deletejournal")))
    | project Timestamp, DeviceName, Hit = "process", Detail = ProcessCommandLine),
    (DeviceNetworkEvents
    | where Timestamp > GoLive and DeviceName has_any (Restored)
    | where RemoteIP in (CaseIPs)
    | project Timestamp, DeviceName, Hit = "network", Detail = strcat(RemoteIP, ":", RemotePort, " ", InitiatingProcessFileName))
| order by Timestamp asc

For the domain controllers, the same window in the SecurityEvent table:

SecurityEvent
| where TimeGenerated > datetime(2026-10-20T06:00:00Z)
| where EventID in (4720, 4728, 4732, 4756)
| project TimeGenerated, Computer, EventID, Actor = SubjectUserName, Target = TargetUserName, Member = MemberName

Both queries are written against the documented table schemas and have not been run against a live workspace. Treat every hit as a new incident, and put the go-live time in the ticket: a hit within hours of the restore usually points at the backup, one weeks later at access nobody found.