RECOVER
Objective
Restore affected services in a trustworthy state, communicate honestly during restoration, and convert every incident into institutional learning.
Core capabilities
StandardOCDFFunction from NIST CSF 2.0; the capability breakdown and IDs are this framework's.
| ID | Capability | Description |
|---|---|---|
| RC-1 | Recovery planning | Documented recovery plans for crown-jewel services with RTO/RPO targets agreed with the business; restoration ordering based on dependencies carried over from IDENTIFY. |
| RC-2 | Trusted restoration | Verify integrity of backups and systems before reconnecting, assuming ransomware persistence; rebuild-from-known-good procedures; credential rotation as standard recovery step. |
| RC-3 | Recovery execution & verification | Ability to execute restores at scale; post-restore validation that services function and are clean. |
| RC-4 | Recovery communication | Status communication to internal stakeholders, customers and authorities, meaning the final NIS2 and DORA reports, and the public where relevant, per CSF 2.0 RC.CO. |
| RC-5 | Lessons learned & improvement loop | Blameless post-incident reviews with tracked actions; findings feed the improvement backlog per CSF 2.0 ID.IM, and update playbooks, detections and controls. |
| RC-6 | Business continuity integration | CDC recovery plans aligned with enterprise BCM/DR; joint exercises. |
The recovery path is decided during response, not during recovery. Snapshot and backup retention defaults are measured in days: the SAN, hypervisor or filesystem snapshot taken before the intrusion is often the cleanest recovery point available, and it expires on schedule whether or not there is an incident open. Extending retention and isolating backup infrastructure belong in the first hour of response, covered in RESPOND. By the time this function starts, the options have already narrowed to whatever survived.
CIA mapping
OCDFThis framework's mapping of each capability to confidentiality, integrity and availability.
| Capability | C | I | A | Rationale |
|---|---|---|---|---|
| RC-1 Recovery planning | ○ | ○ | ● | RTO/RPO are Availability commitments. |
| RC-2 Trusted restoration | ○ | ● | ● | Restoring a backdoored system restores the breach: Integrity verification before Availability restoration is the core principle of this function. |
| RC-4 Communication | ● | ○ | ○ | Recovery comms must not leak sensitive investigation details, which is the Confidentiality of incident data. |
Roles & staffing
PractitionerStaffing figures are practitioner estimates; the arithmetic is under staffing and cost in Operating models.
- Service/platform owners execute restoration; the CDC verifies cleanliness.
- Incident manager remains accountable until closure criteria are met.
- BCM coordinator — interface to continuity management.
Maturity criteria
OCDFThis framework's criteria, informed by the NIST CSF tiers. Not a certification standard.
| Level | Criteria |
|---|---|
| 1 — Initial | Restoration improvised; backups untested; no post-incident reviews. |
| 2 — Managed | Recovery plans and RTO/RPO for critical services; annual restore test; post-incident reviews held for major incidents. |
| 3 — Established | Rebuild-from-known-good procedures; integrity verification gates before reconnection; lessons-learned actions tracked to closure; joint BCM/CDC exercise annually. |
| 4 — Optimising | Recovery time capabilities measured against RTO in realistic exercises including ransomware-scale scenarios; improvement loop metrics show incidents driving control changes; supplier recovery dependencies tested. |
EU regulatory hooks
LawParaphrased from the legal texts. Check the article itself and your national law; not legal advice.
- NIS2 Art. 21(2)(c) — business continuity, backup management, disaster recovery, and crisis management are explicitly required measures.
- NIS2 Art. 23 — the final report, due within 1 month, must include root cause, mitigation, and cross-border impact where applicable.
- DORA Art. 11–12 — response and recovery plans, backup policies and restoration procedures for financial entities, with testing obligations.
- GDPR Art. 32(1)(c) — "the ability to restore the availability and access to personal data in a timely manner" is a named legal requirement.
External dependencies
PractitionerTypical dependencies from experience; yours will differ.
| Dependency | Party | Type | Agree up front |
|---|---|---|---|
| RTO/RPO targets accepted | Business service owners | [GATE] | Signed per crown jewel; revisited after exercises |
| Restoration execution | Service/platform owners | [HARD] | Rebuild procedures rehearsed jointly |
| Reconnection of restored systems | CDC integrity verification | [GATE] | Cleanliness criteria checklist; CDC sign-off before reconnect |
| Business continuity alignment and joint exercises | BCM function | [HARD] | Shared scenario set; annual joint exercise |
| Supplier recovery dependencies | Vendors / procurement | [SOFT] | Recovery commitments in contracts where feasible |
Sources
- NIST CSF 2.0, CSWP 29: RECOVER function. https://doi.org/10.6028/NIST.CSWP.29
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems.
- NIS2: Directive (EU) 2022/2555 Art. 21(2)(c), 23; DORA: Regulation (EU) 2022/2554 Art. 11–12; GDPR Art. 32.
Open CDC Framework, licensed CC BY 4.0. Credits: References & credits.