RC.RP-05 says the integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed. Before a restored system goes back into production, you check it is clean and that the cause of the incident is fixed. Afterward you confirm it is behaving normally.
RC.RP-03 checks what you restore from. RC.RP-05 checks what you ended up with.
What good looks like
Each restored system passes a go live check before it takes traffic. The check covers indicators of compromise, confirmation that root causes have been remediated, and correctness of the restoration: data complete, configuration right, integrations working. A system owner signs off. After go live, the system is monitored more closely for a period, and normal status is declared against stated measures such as error rates, latency, login patterns and outbound connections.
How to implement it
- Create a go live checklist for restored assets. Include: scan for indicators of compromise, confirm patches or fixes for the entry point are applied, confirm credentials and keys were rotated, verify data completeness, test core user journeys, confirm logging and monitoring agents are running.
- Bring systems back in stages. Start with an isolated or limited exposure environment, then widen.
- For software, rebuild from a clean pipeline and scan the resulting dependencies. A free in browser dependency scan at https://gold.safeguard.sh/scan can show known CVEs in a manifest before you redeploy. Reachability analysis can show whether a flagged function is actually called, which helps you decide what must be fixed before go live and what can follow.
- Raise monitoring on restored systems. Watch for repeat of the original behavior and for unusual outbound traffic.
- Define what normal means for each service before the incident, so you can compare.
- Hold a short sign off: system owner and incident lead confirm in the ticket.
- Keep the heightened monitoring window for a set period, such as two weeks, then step down.
Try it yourself
Continuous monitoring is what turns normal operating status from a feeling into a check. This demo shows how signals roll up into a status you can point to.
Click through it at your own pace, or open it full screen.
Evidence to collect
- The go live checklist and completed copies for past recoveries or exercises.
- Scan results for restored systems.
- Owner sign off records.
- Monitoring dashboards or alert history for the heightened period.
- Records showing the root cause fix was verified before go live.
A worked example
A web application is rebuilt after an attacker used an outdated library to run code on a server. Before go live the team runs through the checklist. The library is replaced and the version in production is confirmed against the lockfile. The credentials stored on the old server were rotated, and the old ones were tested and no longer work. A scan of the rebuilt host finds no unexpected processes or scheduled tasks. Core user journeys, including sign in and checkout, pass a scripted test.
The system goes live to five percent of traffic first. For two weeks, alerts are tightened on unusual outbound connections and new administrator accounts. After the window closes with no recurrence, the system owner and incident lead confirm normal operating status in the ticket, and monitoring returns to standard levels.
Common gaps
- Systems are declared fixed because they respond to a ping.
- The entry point was never patched, so the system is restored into the same hole.
- Credentials are not rotated, and old ones still work.
- Nobody defined normal, so no one can say when it has returned.
- Monitoring agents were not reinstalled on rebuilt hosts.
- Staff pressure pushes systems live before checks finish.
Quick check
What is the difference between RC.RP-03 and RC.RP-05?
RC.RP-03 verifies the backups and assets you restore from. RC.RP-05 verifies the restored result and confirms it works and is clean.
How do you define normal?
Pick measures per service before an incident, such as error rate, latency, sign in patterns and outbound connections, and record baseline values to compare against.
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-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.
