RC.RP-04 says critical mission functions and cybersecurity risk management are considered to establish post incident operational norms. Put simply: restore what the business needs first, and decide what normal looks like after an incident rather than reverting by default.
What good looks like
You have a ranked list of services by business impact, with target recovery times. During recovery that list sets the order. System owners confirm each service is back, and restored systems are watched more closely for a period. Where the incident revealed a weakness, the new normal includes the fix, such as stricter access or extra logging.
How to implement it
- Build a simple impact table: service, owner, how long it can be down, what depends on it.
- Use it to sequence restoration and share it with everyone doing recovery work.
- Ask each owner to sign off that the service works, not just that it is up.
- Add temporary heightened monitoring to restored systems and review after two weeks.
- Decide which changes made during the incident stay permanent.
Evidence to collect
- The impact table or business impact analysis.
- Recovery tickets showing order of restoration and owner sign off.
- Monitoring notes for restored systems.
Common gaps
- Restoration order set by who complains first.
- Nobody checks business function, only server status.
- Emergency changes never reviewed.
Quick check
Where does the priority list come from?
From the people who run each service. Security cannot rank business impact alone.
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-04, 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.
