Recovery is where many SMBs discover the gaps they should have fixed months earlier. Backups that were never tested. RTO targets written in a policy but never validated against actual restore times. A post-incident review process that exists on paper but collapses under the pressure of an active incident.
NIST CSF 2.0 streamlines the Recover function to two categories: executing the recovery plan and communicating throughout the process. The simplicity is intentional — recovery under pressure is not the time for elaborate frameworks. It’s the time to execute a plan that was already validated.
Recover also closes the NIST CSF loop. The post-incident review required by RC.CO generates findings that feed back into Govern (policy updates), Identify (revised risk assessments), Protect (new controls), and Detect (tuned monitoring). Organizations that treat recovery as a terminal step rather than a feedback loop repeat the same incidents.
The 2 Recover Categories
Common SMB Gaps in the Recover Function
- Backups exist but are never restored — the first restore test happens during an actual incident, where a failure compounds the crisis rather than resolving it.
- No defined RTO or RPO — recovery time targets are vague (“as fast as possible”) with no measurement of whether backup architecture can actually meet them.
- Backup systems targeted in the same attack as primary systems — particularly common in ransomware scenarios where backups are encrypted along with everything else.
- No post-incident review process — incidents end when systems come back online, with no structured analysis of what was learned.
- RC.CO communication templates don’t exist — customer and stakeholder updates are improvised during recovery, creating legal and reputational risk.
- Recovery planning done once and never updated — the documented recovery procedure describes systems that no longer exist.
RTO, RPO, and the 3-2-1 Backup Rule
Setting RTO and RPO starts with a business impact analysis: for each critical system, what does an hour of downtime cost? A day? From that, derive the maximum tolerable downtime (your RTO) and maximum tolerable data loss (your RPO). Then verify — with an actual restoration test — that your backup system hits those targets.
The 3-2-1 rule (three copies, two media types, one offsite) remains the baseline for backup architecture that can survive a ransomware attack. The offsite copy must be either physically isolated or logically isolated with immutable storage (write-once, cannot be deleted or encrypted). Cloud backup services like AWS Backup, Azure Backup, or Backblaze B2 with object lock satisfy the immutability requirement cost-effectively.
For a complete cost and implementation comparison, see our NIST CSF implementation guide.