The integrity of backups and other restoration assets is verified before using them for restoration.
Also written as RC-RP-03, RC.RP-3, CSF 2.0 RC.RP-03, NIST CSF RC.RP.
RC.RP-03 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 backups and other restoration assets is verified before using them for restoration.” 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-03 corresponds to the following ISO 27001:2022 Annex A control(s): A.8.13. Evidence collected for one framework typically supports the other.
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-03 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-03 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.
Yes — RC.RP-03 corresponds to ISO 27001:2022 Annex A control(s) A.8.13. Evidence collected for one framework typically supports the other, so a single control library can serve both.