The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed.
Also written as RC-RP-05, RC.RP-5, CSF 2.0 RC.RP-05, NIST CSF RC.RP.
RC.RP-05 is one of 8 subcategories in the Recover (RC) function, under the Incident Recovery Plan Execution category (RC.RP). The Core states: “The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed.” Recover outcomes are the least frequently tested in practice and the most commonly assumed — restoration evidence from a real test, not a backup job that reports success, is what demonstrates the outcome.
To demonstrate this outcome in an assessment or audit, gather artefacts such as:
RC.RP-05 has no direct one-to-one ISO 27001:2022 Annex A equivalent — it is a governance or process outcome that ISO 27001 addresses at the management-system level (Clauses 4–10) rather than through a specific Annex A control. Treat it as its own requirement in your CSF profile.
No. CSF 2.0 is a voluntary framework of outcomes rather than a set of requirements, and there is no certification against it. RC.RP-05 becomes binding only when something else makes it so — a contract, a regulator that references CSF, or your own Target Profile. That is the practical difference between CSF and an auditable standard like ISO 27001 or SOC 2.
Through profiles rather than pass/fail testing. You record how fully the outcome is achieved today in a Current Profile, state where it needs to be in a Target Profile, and the gap between them becomes your action plan. Implementation Tiers (Partial, Risk Informed, Repeatable, Adaptive) describe how rigorous your governance around the outcome is, not whether you have met it.
The Recover function is normally owned by the security or IT function, but RC.RP-05 still needs a specific named owner. Assessors treat an outcome with no owner as not achieved regardless of the tooling behind it, so record ownership in your profile alongside the assessment.