Recover is the smallest Function in NIST CSF 2.0, and the one most often scored from a backup policy rather than from proof that the organisation can actually come back from a destructive incident. CSF 2.0 (NIST CSWP 29, 26 February 2024) defines Recover as the Function in which assets and operations affected by a cybersecurity incident are restored. It has two Categories and eight Subcategories, and several CSF 1.1 recovery outcomes were moved or merged in 2.0, which confuses crosswalks. This guide works through every Recover Subcategory with NIST's Implementation Examples, explains what changed from 1.1, shows the evidence an assessor should ask for, maps Recover to SP 800-53 Rev 5 and ISO/IEC 27001:2022, and covers the identity work that recovery depends on. It is for incident managers, resilience and continuity leads, infrastructure owners and auditors who already know the CSF basics.
Key takeaways
- Recover has two Categories and eight Subcategories: RC.RP Incident Recovery Plan Execution (RC.RP-01 to 06) and RC.CO Incident Recovery Communication (RC.CO-03 and 04).
- Integrity checks are explicit outcomes. RC.RP-03 requires backups and restoration assets to be verified before use, and RC.RP-05 requires restored assets to be verified before normal status is confirmed.
- Improvement left Recover. CSF 1.1 RC.IM was withdrawn; lessons learned now sit in Identify (ID.IM-03, ID.IM-04), and recovery plans themselves are an ID.IM-04 outcome.
- Recovery has a defined end. RC.RP-06 expects the end of recovery to be declared against criteria, with an after-action report, so "back online" is not the same as "recovered".
- Credentials are restoration assets. Service accounts, keys and tokens touched by the incident must be rotated before restored systems go live, or the attacker returns through the same door.
Where Recover sits in CSF 2.0
NIST's one-line definition of Recover is that assets and operations affected by a cybersecurity incident are restored. Recover follows Respond in the incident life cycle but is not strictly sequential: RC.RP-01 says the recovery portion of the incident response plan is executed once initiated from the incident response process, and the first Implementation Example is to begin recovery procedures during or after incident response. In practice, restoration of unaffected services often runs in parallel with containment of the affected ones.
The CSF is voluntary and outcome-based. CSWP 29 states that it does not prescribe how outcomes should be achieved; the Implementation Examples quoted below are illustrative actions from the CSF 2.0 Core data, not a mandatory checklist. Recover also depends on outcomes held elsewhere: recovery plans are established and maintained under ID.IM-04, backups are created, protected, maintained and tested under PR.DS-11, and resilience requirements sit in PR.IR. See the NIST CSF 2.0 Guide for the Core as a whole and the NIST CSF 2.0 Respond Function for the stage before this one.
What changed from CSF 1.1
The CSF 2.0 catalogue records where each withdrawn 1.1 outcome went. For Recover the moves are:
| CSF 1.1 outcome | Status in 2.0 | Now covered by |
|---|---|---|
| RC.RP-1, the single 1.1 recovery planning outcome | Expanded | RC.RP-01 to RC.RP-06 |
| RC.IM-01 Recovery plans incorporate lessons learned | Withdrawn | ID.IM-03, ID.IM-04 |
| RC.IM-02 Recovery strategies are updated | Withdrawn | ID.IM-03 |
| RC.CO-01 Public relations are managed | Withdrawn | RC.CO-04 |
| RC.CO-02 Reputation is repaired after an incident | Withdrawn | RC.CO-04 |
| RC.CO-03 Recovery activities are communicated | Retained, reworded | RC.CO-03 |
The practical effect: a 1.1 assessment that scored "RC.IM" now has to be re-scored in Identify, and organisations that treated recovery as one plan-execution line now face six distinct outcomes, from selecting recovery actions to declaring the end of recovery.
RC.RP Incident Recovery Plan Execution
Category statement: restoration activities are performed to ensure operational availability of systems and services affected by cybersecurity incidents. The table gives each outcome, the Implementation Examples from the CSF 2.0 Core (paraphrased) and what that means in practice.
| Subcategory | Outcome | NIST Implementation Examples | What it means in practice |
|---|---|---|---|
| RC.RP-01 | The recovery portion of the incident response plan is executed once initiated from the incident response process | Begin recovery during or after incident response; make everyone with recovery duties aware of the plans and the authorisations needed for each part | A named trigger and decision owner for starting recovery, and pre-agreed authority for actions such as rebuilding domain controllers or failing over regions |
| RC.RP-02 | Recovery actions are selected, scoped, prioritised and performed | Select actions using criteria in the incident response plan and available resources; change them when needs and resources are reassessed | Restore, rebuild or replace decisions per system, recorded with the reason, revisited as the investigation changes scope |
| RC.RP-03 | The integrity of backups and other restoration assets is verified before using them for restoration | Check restoration assets for indicators of compromise, file corruption and other integrity issues before use | Scan backups and golden images, choose a restore point before the earliest known attacker activity, check hashes of images and installers |
| RC.RP-04 | Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms | Use business impact and system categorisation records (including service delivery objectives) to restore essential services in the right order; confirm restoration with system owners; monitor restored systems | The business impact analysis drives order of restoration; temporary operating norms (manual workarounds, reduced service) are agreed rather than assumed |
| RC.RP-05 | The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed | Check restored assets for indicators of compromise and remediation of root causes before production use; verify the correctness of restoration actions before putting a system online | No system returns to production until the entry point is closed and compromised credentials are rotated; a sign-off per system |
| RC.RP-06 | The end of incident recovery is declared based on criteria, and incident-related documentation is completed | Prepare an after-action report covering the incident, response, recovery and lessons learned; declare the end of recovery once criteria are met | Written exit criteria (for example all critical services at agreed service levels, enhanced monitoring period complete) and a formal close |
Choosing restore, rebuild or replace
RC.RP-02 is where most recovery time is lost, because the decision is made under pressure without agreed criteria. A simple decision rule written into the plan helps:
- Restore from backup: when a clean restore point is known, the system was not used for attacker persistence, and the backup itself passed RC.RP-03 checks.
- Rebuild from code or images: for identity infrastructure, management servers and any system where persistence is suspected, rebuild from trusted images and configuration as code, then restore only data.
- Replace or retire: for end-of-life systems whose rebuild would recreate the same weakness, or where a managed service can take over.
- Accept degraded operation: under RC.RP-04, a documented decision to run a reduced service while low-priority systems wait.
Attackers target recovery directly. MITRE ATT&CK lists T1490 Inhibit System Recovery (deleting shadow copies, backup catalogues and recovery partitions) alongside T1486 Data Encrypted for Impact and T1485 Data Destruction, which is why RC.RP-03 checks and isolated backups matter. See the Backup Security and Immutable Backup Guide and the Ransomware Response and Recovery Guide.
RC.CO Incident Recovery Communication
Category statement: restoration activities are coordinated with internal and external parties. Only two Subcategories remain after the 1.1 public relations outcomes were merged.
| Subcategory | Outcome | NIST Implementation Examples | Practical evidence |
|---|---|---|---|
| RC.CO-03 | Recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders | Share recovery information securely, consistent with response plans and information sharing agreements; update senior leadership regularly on major incidents; follow contract rules for sharing with suppliers; coordinate crisis communication with critical suppliers | A status cadence (for example twice daily to the executive team), a stakeholder list with owners, supplier contact records |
| RC.CO-04 | Public updates on incident recovery are shared using approved methods and messaging | Follow breach notification procedures when recovering from a data breach; explain the steps being taken to recover and to prevent recurrence | Pre-approved holding statements, a single approver, a log of every public statement |
Regulatory notification itself is a Respond outcome (RS.CO-02, internal and external stakeholders are notified of incidents), so keep the two apart: RC.CO is about recovery progress and public messaging during restoration. Communication channels must also survive the incident; if email and chat run on the compromised identity provider, out-of-band channels need to be arranged in advance. See the Incident Communication Plan Template.
Where identity fits
Recover outcomes say nothing about identity by name, but RC.RP-03 and RC.RP-05 cannot be met without it. In NHI Mgmt Group's view, reinfection after recovery often comes from credentials left valid rather than from malware left on disk.
- Identity infrastructure first: the directory, identity provider and privileged access tooling usually have to be trusted before anything else can be restored. Back up identity provider configuration separately; see the IdP configuration backup and restore for Entra ID and Okta.
- Rotate before go-live: service account passwords, API keys, OAuth client secrets, signing keys and tokens on systems in scope must be rotated as part of RC.RP-05 "remediation of root causes". Cloudflare's 2023 incident shows the cost of missing some: credentials left unrotated after the earlier Okta breach were later used to get in.
- Backups have identities too: backup software service accounts and storage keys are prime targets; isolate them from the production directory. See the Backup Identity Isolation Guide.
- Break-glass access: recovery teams need emergency accounts that do not depend on the affected identity provider, tested before an incident.
- Restored stale access: restoring a directory from backup can bring back accounts and group memberships removed during containment; reconcile against the incident record before reopening access.
Implementing Recover step by step
- Confirm the inputs exist: a business impact analysis with recovery time and recovery point objectives per critical service (ID.AM-05, RC.RP-04), and recovery plans under ID.IM-04. Without these RC.RP-02 has no criteria. See the Business Impact Analysis Template.
- Write recovery into the incident response plan: define the RC.RP-01 trigger, who authorises it and which actions need extra approval. NIST SP 800-61 Rev 3 (April 2025) frames incident response as a CSF 2.0 Community Profile and covers recovery within it.
- Define integrity checks: list what is checked before a backup or image is used (malware scan, hash comparison, restore point selection) and after restoration (indicators of compromise, configuration baseline, credential rotation).
- Build recovery playbooks: SP 800-184, the Guide for Cybersecurity Event Recovery, recommends playbooks per scenario; start with ransomware, identity provider compromise and loss of a cloud region or SaaS tenant.
- Set exit criteria: agree in advance what "recovered" means for RC.RP-06, including an enhanced monitoring period after restoration.
- Prepare communications: stakeholder lists, approval chain and holding statements for RC.CO-03 and RC.CO-04, plus out-of-band channels.
- Test, then test harder: restore tests for individual systems, then full scenario exercises that include rebuilding identity services; feed findings into ID.IM-02. See the Backup and Recovery Testing Checklist.
- Re-profile: score all eight Subcategories in the Current Profile against evidence from the last real incident or exercise.
Small versus large organisations: a small business can meet Recover with a short recovery runbook, an offline or immutable backup that has been restored at least once, a contact list and a template customer notice. Large organisations need ordered restoration plans across hundreds of dependencies, a separate clean recovery environment, and supplier coordination for RC.CO-03; their main risk is dependency mapping that is out of date when the incident happens.
Evidence, measurement and assessment
| Subcategory | Weak evidence | Strong evidence |
|---|---|---|
| RC.RP-01 | A disaster recovery plan document | Incident records showing when recovery was initiated, by whom, and under which authority |
| RC.RP-02 | A list of systems | A decision log of restore, rebuild or replace choices with reasons |
| RC.RP-03 | Backup job success reports | Records of pre-restore scans and restore point selection in tests and incidents |
| RC.RP-04 | A business impact analysis | A restoration order that matches the BIA, with owner confirmation |
| RC.RP-05 | "System back online" tickets | Per-system sign-off including root cause fixed and credentials rotated |
| RC.RP-06 | Ticket closed | Exit criteria met, after-action report approved, actions tracked in ID.IM |
| RC.CO-03 and RC.CO-04 | A communications policy | Logged status updates and approved public statements from an incident or exercise |
Metrics that show Recover is working
- Restore test coverage: percentage of critical services with a successful full restore test in the last 12 months.
- Objective achievement: actual recovery time and data loss in tests and incidents against the stated objectives.
- Clean restore rate: percentage of restores where the first chosen restore point passed integrity checks.
- Credential rotation completeness: percentage of in-scope credentials rotated before go-live.
- Reinfection: number of incidents where the attacker regained access after restoration.
- After-action closure: percentage of after-action items closed by their due date.
Mapping to other frameworks
NIST publishes official CSF 2.0 Informative References, including a mapping to SP 800-53 Rev 5, through the CSF 2.0 Reference Tool; use those for formal crosswalks. This table is an orientation by control purpose.
| Recover outcome | SP 800-53 Rev 5 (related) | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 |
|---|---|---|---|
| RC.RP-01, RC.RP-02 | IR-4 Incident Handling, IR-8 Incident Response Plan, CP-2 Contingency Plan | 5.26 Response to information security incidents, 5.29 Information security during disruption | Control 17 Incident Response Management |
| RC.RP-03 | CP-9 System Backup, SI-7 Software, Firmware, and Information Integrity | 8.13 Information backup | Control 11 Data Recovery |
| RC.RP-04, RC.RP-05 | CP-10 System Recovery and Reconstitution | 5.30 ICT readiness for business continuity | Control 11 Data Recovery |
| RC.RP-06 | IR-4 Incident Handling | 5.27 Learning from information security incidents | Control 17 Incident Response Management |
| RC.CO-03, RC.CO-04 | IR-4, IR-6 Incident Reporting | 5.24 Information security incident management planning and preparation | Control 17 Incident Response Management |
| Testing (ID.IM-02 for Recover) | CP-4 Contingency Plan Testing, IR-3 Incident Response Testing | 5.30 ICT readiness for business continuity | Control 11 Data Recovery |
For recovery planning depth, NIST SP 800-184 and SP 800-34 Rev 1 (contingency planning) remain the main NIST references, and SP 1800-11 shows how to recover data integrity after ransomware and other destructive events. See the Cybersecurity Event Recovery Guide and the Business Continuity and Disaster Recovery Guide.
Common failure patterns
- Restoring the attacker: restoring the most recent backup without checking it, when persistence predates that restore point. RC.RP-03 exists for this.
- Backups on the same identity plane: backup consoles joined to the compromised domain, so the attacker deletes or encrypts them (T1490).
- Back online, not recovered: systems returned to production before credentials were rotated and root causes fixed, which fails RC.RP-05.
- No restoration order: teams restore what they know best rather than what the business impact analysis says is critical, breaching RC.RP-04.
- Recovery never ends: no exit criteria, no after-action report, so lessons never reach ID.IM and the same gaps recur.
- Silent recovery: executives and customers hear nothing structured during a long restoration, and ad hoc statements contradict each other.
Practitioner checklist
- Score all eight Recover Subcategories individually, and re-score 1.1 RC.IM items under ID.IM.
- Confirm every critical service has recovery time and point objectives in a current business impact analysis.
- Write the recovery trigger, authorities and restore, rebuild or replace criteria into the incident response plan.
- Define pre-restore integrity checks and a rule for choosing a clean restore point.
- Require credential rotation and root cause sign-off before any system returns to production.
- Keep backup infrastructure and its accounts isolated from the production identity provider.
- Set written exit criteria and produce an after-action report for every major incident.
- Prepare stakeholder lists, holding statements and out-of-band channels for RC.CO.
- Run at least one full scenario recovery exercise a year that includes identity services.
Standards and references
- NIST: The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: SP 800-184 Guide for Cybersecurity Event Recovery
- NIST: SP 800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems
- NIST: SP 1800-11 Data Integrity: Recovering from Ransomware and Other Destructive Events
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: T1490 Inhibit System Recovery
Related NHI Mgmt Group resources: NIST CSF 2.0 Guide · NIST CSF 2.0 Govern Function Guide · NIST SP 800-61 Incident Response Guide · Disaster Recovery Plan Template · Post-Incident Review and Root Cause Analysis Template