NIST CSF 2.0 RC.RP-01: Execute the Recovery Plan

RC.RP-01 says the recovery portion of the incident response plan is executed once initiated from the incident response process. A plan that sits in a folder does not count. People need to know it exists, what their part is, and who authorizes each step.

What good looks like

Response hands over to recovery with a clear message from the incident lead. Everyone with a recovery role has seen the plan, knows which actions they may take, and knows which need approval. Recovery can begin during response for unaffected systems and continue after it ends.

How to implement it

• Keep the recovery plan as its own section or document, linked from the incident plan.
• List recovery tasks per critical service: restore data, rebuild hosts, redeploy from clean source, rotate secrets, verify.
• Record owners and backups for each task and the authority needed, for example who can approve a restore to production.
• Brief everyone named in the plan once a year and after major changes.
• Include the handover step in your tabletop exercises and time it.

Evidence to collect

• The recovery plan with version history.
• A roster of recovery roles and acknowledgements that people have read it.
• Incident tickets showing the handover and the start of recovery.
• Tabletop results.

Common gaps

• The plan names people who have left.
• Authorization is unclear, so engineers wait for approval during an outage.
• Recovery is improvised because the plan was never exercised.
• Plan covers servers but not SaaS tools or code repositories.

Quick check

Sources

• NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
• NIST CSF 2.0 implementation examples for RC.RP-01, as listed in the CSF 2.0 Reference Tool: https://www.nist.gov/cyberframework

CSF is voluntary guidance. There is no CSF certification, so use it to organize and show your own work.