RS.MA-05 says the criteria for initiating incident recovery are applied. The point is a deliberate decision: recovery starts when agreed conditions are met, not when the pressure to get back online peaks.
What good looks like
Your plan lists the conditions for moving from response to recovery. Typical ones: the threat is contained, the root cause or entry point is understood well enough to close, forensic copies have been taken, and the business owner accepts the disruption recovery will cause. A named person, usually the incident lead with the system owner, signs off the decision and the time is recorded.
How to implement it
- Write a short checklist: contained, evidence preserved, cause understood or bounded, restore source verified, owner agrees.
- Weigh the cost of downtime against the risk of restoring into a live attacker.
- Record who approved and when in the incident ticket.
- Allow partial recovery for systems that are clearly unaffected.
Evidence to collect
- The written criteria in the incident plan.
- Incident tickets showing the go decision, approver and time.
- Notes where recovery was deliberately delayed and why.
Common gaps
- Restoring from backup before evidence is captured.
- Restoring before the way in is closed, so the attacker returns.
- No record of who said go.
Quick check
Can recovery start while response is still running?
Yes for unaffected systems, as long as the criteria were applied to them and the decision was recorded.
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 RS.MA-05, 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.
