RC.RP-02 says recovery actions are selected, scoped, prioritized and performed. After an incident you rarely have the time or people to do everything at once, so the choice of what to do first, and how far to go, matters.
What good looks like
Recovery actions come from the criteria in your incident plan and the resources you actually have that day. Each action has a defined scope (which systems, which accounts, which data). The plan changes when reality changes: a restore fails, a second system turns out to be affected, or a key person is unavailable. Every change is recorded with the reason.
How to implement it
- Create a recovery action list per incident, with owner, scope, dependency and priority.
- Use the impact table from your business continuity work to rank services.
- Decide between repair in place and rebuild from known good source. For serious compromise, rebuild is usually safer.
- Reassess at set intervals, such as every four hours, and update the list.
- Capture resource limits openly: staff, access, vendor lead times.
- Keep actions small enough to be verified one at a time.
Evidence to collect
- Recovery action lists from past incidents or exercises.
- Records of reprioritization with reasons.
- The criteria section of the incident plan.
Common gaps
- Scope creeps because nobody wrote down what was in it.
- Teams repair compromised systems instead of rebuilding them.
- The list is held in chat and lost afterward.
Quick check
Why record a changed plan?
It shows the change was a decision, and it feeds the after action review with what you learned about estimates and dependencies.
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-02, 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.
