RC.RP-05 Restored assets verified: requirements and evidence

What RC.RP-05 asks you to prove before systems go back into production

RC.RP-05 requires you to show that restored assets have had their integrity verified, that systems and services were restored in a controlled way, and that normal operation is confirmed, including evidence that the root causes of the incident were remediated before production use. If your team has just restored systems after an incident, the question an assessor or board will ask is not whether the restore finished, but whether you can prove it was safe to put those systems back into service. The main risk is reinfection. A backup can contain malware that was already present before the backup was taken, a golden image can carry the same weakness that let the attacker in, and a restored host can be reconnected to the network while the original entry point is still open. RC.RP-05 treats these as separate checks: the asset must be examined for indicators of compromise, the cause of the incident must be shown to be fixed, and the restoration steps must be verified before the system goes live.

RC.RP-05 is new in CSF 2.0. NIST's transition spreadsheet flags it as a topic that was not clearly present in any CSF 1.1 Category or Subcategory, so organizations that only had a generic recovery procedure in 1.1 will find no direct prior mapping to rely on. NIST's informative references point to SP 800-53 control CP-10 (system recovery and reconstitution) and to Annex A control 5.26 of ISO/IEC 27001:2022 (response to information security incidents). Use those references as starting points for finding your existing evidence, but confirm the exact scope of each control in the source documents, since a mapping does not replace reading the control itself. The work is hard for a practical reason: the pressure to restore service quickly comes from the business, while the verification steps belong to security, and recovery teams often assume that security has signed off when security assumes the recovery team has tested the image. Before the next incident, agree in writing who owns each check, who can stop a restore, and what record proves each check was done.

A practical starting point is to ask your team for three artifacts from the last recovery: the scan or review record for each restored asset, the change or ticket that documents the root cause fix, and the sign-off that the system was returned to normal operation. If any of these is missing or was produced after the system went live, you have a gap to close before an assessment. Confirm with your independent auditor or assessor which of these records they will accept and in what form, because the acceptance criteria are theirs to set. DeployOpen can prepare the technical checks, the runbook steps and the evidence templates for these records in your environment, but the determination that the evidence meets RC.RP-05 rests with your organization and its assessor.

Which systems, backups and teams fall under RC.RP-05

RC.RP-05 covers every restored asset that returns to production after an incident, so scope should start from the critical services named in the recovery plan. The cards below separate what gets restored, where it comes from, who signs off each step, and which third parties touch the process.

Restored compute and endpoints

Servers, virtual machines, endpoints and cloud workloads that the recovery plan brings back are the core of RC.RP-05. For each critical service, list the hosts, their operating systems and installed applications, and their owners. Before a restored host returns to production, confirm that its software inventory has been checked for vulnerable or unexpected components, since a host restored from an older source can reintroduce a weakness that caused the incident. Ask the operations team to show the list used for sign-off.

Containers, images and cloud workloads

Containers, container images, infrastructure templates and cloud workloads are restored by redeploying rather than by copying disks, so their verification step differs. Identify which images are pulled from internal registries, which come from public sources, and which configurations are regenerated from code. Each source needs a check that the artifact matches what was approved before the incident, and that no compromised base image or changed template is redeployed into production.

Data stores and databases

Databases, object stores, file shares and other data stores are where restored integrity problems are hardest to see, because the service can start while its contents are altered or incomplete. Scope these by data classification and by the recovery point each one can reach. Document which stores need consistency checks, such as application-level reconciliation, before users or downstream systems read from them, and who approves that the restored data is fit for use.

Backup repositories and restore sources

Every restored asset traces back to a recovery source: a backup repository, a golden image, or vendor-supplied installation media. Inventory each source, its location, its access path and its retention, and record which assets depend on it. Backup tools such as Bareos keep a catalog of backed-up files and restore from the current backup or one taken before a given date and time, so the chosen restore point should be recorded alongside the asset. Confirm that each source has been verified under RC.RP-03 before it feeds production.

Recovery, security and application owners

Several teams own steps in RC.RP-05 and the handoffs between them are where checks are skipped. Typically the backup or infrastructure team performs the restore, the security team checks indicators of compromise and confirms root-cause remediation, and the application owner confirms normal operation. Write down who signs each verification, what authority they hold to block a return to service, and how a disagreement is escalated. The recovery plan should name these roles before an incident occurs.

Managed backup and recovery providers

Managed backup providers, managed security service providers and vendors supplying media or images are third parties whose work feeds RC.RP-05. Confirm in the contract what they restore, how they document integrity checks, how quickly they can supply evidence, and whether they can access restored systems. The organization remains responsible for its controls, so the agreement should require the provider to deliver verification records that the organization can review and retain.

How an assessor tests restored assets

The first thing an assessor checks is whether the organization has written down how restored assets are verified before they return to production. The assessor reads the recovery procedures and asks whether they state who verifies, what is checked, which tools are used, and what must be true before a system goes back online. Procedures that only say "verify the restore" give the assessor nothing to test against. The assessor will compare the written steps with the incident response and recovery plans referenced elsewhere in the program, and look for gaps between them.

Verification criteria: The procedure should name the checks, such as scanning for indicators of compromise and confirming the root cause is addressed, and state the pass or fail condition for each.
Roles and separation: The document should identify who performs the verification and who approves the return to service, and show that these are different people where the organization's size allows.
Tooling references: Named tools or commands should match what the team actually runs, for example a vulnerability scanner or a file integrity check.
Version control and approval: The assessor will check the document date, owner and approval history against the review cycle the organization claims.
Link to recovery authorization: The procedure should say which conditions must be met before a system is declared restored and who records that decision.

Confirm that the procedure is the one the team follows in practice, because assessors often compare it against the most recent recovery record.

Implementing RC.RP-05 step by step

This sequence turns RC.RP-05 into a repeatable acceptance process, so each restored asset leaves recovery with documented integrity checks, confirmed root-cause remediation, and a sign-off record that the end-of-recovery step can rely on.

Define the restored-asset acceptance checklist
Before any restore starts, the recovery lead and the system owners agree a written acceptance checklist for each asset class. It covers file and configuration integrity, checks for indicators of compromise, confirmation that the incident's root cause was remediated, configuration against the approved baseline, and service health criteria. The output is a versioned checklist attached to the recovery plan, with a named owner for each check. Ask your team to confirm which checks are mandatory for each system tier before the incident occurs, not during it.
Assign verification roles separate from restoration roles
The people who rebuild or restore a system should not be the only people who accept it. Name a verifier for each asset who was not directly responsible for the restore action, and record both assignments in the recovery roster. The output is a roster that shows, for every asset, who restored it and who will verify it. This separation gives an independent check on the work, and it gives an assessor a clear answer when asked who accepted a system into production.
Verify the restore source before use
Before a restored asset is accepted, the verifier confirms that the source it was restored from passed its own integrity checks. This is the handoff from RC.RP-03, which covers verifying backups and other restoration assets for indicators of compromise and corruption. Where a backup tool offers integrity checks, such as a structural consistency check or a read-back of stored data, record the command, the scope and the result. The output is a record linking each restored asset to a verified source, or to a documented exception.
Scan and inventory restored hosts
Run a software inventory and vulnerability scan on each restored host and compare the results with the approved build baseline. Look for software that should not be present, unexpected services or accounts, and known vulnerabilities in the operating system and installed applications. Open-source tools such as Wazuh, which correlates agent inventories with vulnerability feeds, or Fleet, which matches installed software against vulnerability sources, can produce this evidence in a self-hosted setting. The output is a dated inventory and scan report per host, with each finding either resolved or accepted by a named owner.
Confirm root-cause remediation with a named owner
Using the root cause recorded during incident analysis, the named owner of that remediation confirms in writing that the fix is in place on each restored asset. The owner shows the evidence, such as a patched version, a removed credential, a closed entry point or a changed configuration, and the verifier checks it independently. The output is a signed remediation statement per asset. If the root cause is not yet fixed, the asset stays out of production or runs under a documented, approved restriction. Confirm with your team how this interacts with your incident analysis records.
Run functional and monitoring checks
Once the asset is in its recovered state, the verifier runs functional tests that match the service's normal behavior, such as application transactions, authentication, data access and dependent integrations. The team also confirms that logging and monitoring for the asset are active and reporting to the security operations function. The output is a test log showing the results against the defined normal operating status, with any deviations logged and resolved before the asset is accepted.
Record sign-off and hand the record to RC.RP-06
The verifier and the system owner sign the acceptance record for each asset, which lists the checklist results, the source verification, the scan findings, the remediation statement and the test results. The complete set is then passed to the team responsible for declaring the end of recovery under RC.RP-06, which requires the records to support that decision and the after-action report. The output is a signed, dated acceptance file per asset. Ask your auditor which format they will expect to see this evidence in before the next assessment.

Evidence that passes RC.RP-05 and how to keep it current

An assessor testing RC.RP-05 wants to see that each restored asset was checked for indicators of compromise and root-cause remediation before it returned to production, and that the checks are repeatable. The cards below cover the records that show this, and the routines that keep them current between audits. The organization owns these records; an independent auditor decides whether they are sufficient.

Signed restoration checklists

A restoration checklist is the per-asset record that shows verification steps were performed in order before the system went back online. For each restored asset, it should name the restore point used, the person who performed each step, the person who approved return to service, and the time of each sign-off. Check that the checklist references the same asset identifier used in your scan and monitoring records, so an assessor can trace one system across all the evidence.

Post-restore integrity and vulnerability scans

Scan output taken after restoration shows whether the rebuilt system carries known vulnerabilities or unexpected software. Wazuh vulnerability detection correlates each agent's software inventory with a vulnerability repository, which can be a locally hosted offline copy, and Fleet matches installed software on enrolled hosts against advisory sources. Keep the scan date, the asset identifier and the data source version with each report, because an assessor will ask which vulnerability data was current when the check ran.

Root-cause remediation tickets linked to assets

RC.RP-05 expects evidence that the root causes of the incident were remediated before production use. A ticket that records the root cause, the remediation applied, and the restored asset it affects is the link an assessor looks for. Tie each ticket to the asset identifier and to the checklist item it satisfies, and do not close the ticket until verification evidence is attached. Tickets opened for the incident but never linked to a restored system are a common gap.

Change records for configuration differences

A restored system often differs from its pre-incident configuration, for example after a patch was added, a firewall rule was tightened, or a credential was rotated. Change records document each difference, the reason for it, and the approval. They show an assessor that the restored state is known and intentional rather than drift. Confirm that your change management process accepts recovery changes made under incident conditions, and that these records are retained with the incident file.

Monitoring baselines after return to service

Monitoring baselines capture normal behavior for a restored system, such as its running services, network connections and authentication activity, over a defined period after it returns to production. Deviations from the baseline are evidence that normal operating status was confirmed and that anomalies were reviewed. Store the baseline snapshots with timestamps, and record who reviewed them and what was done about any deviation.

Restoration exercise reports

Restoration exercises test whether backups can actually be restored and verified, and whether the checklist works as written. Bareos runs restore and verify jobs on a schedule, and restic's check command with read-data options confirms that stored backup data is unmodified. Keep a dated report for each exercise listing the asset restored, the steps that failed, and the fixes made. Scheduled exercises between audits are the strongest proof that the process is current rather than documented once.

What meeting RC.RP-05 costs in money and effort

This table lists the cost components of verifying restored assets under RC.RP-05, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to shape the questions you put to a fixed-scope quote, not as a price estimate.

Cost component	One-time or recurring	Who is paid	Drivers and how to reduce cost
Verification tooling or licenses	Recurring (subscription or support) or one-time (purchase)	Software vendor, or no license fee for self-hosted open source	Asset types needing integrity checks. Self-hosted tools such as restic (BSD-2-Clause) and Bareos (AGPL-3.0-only) carry no license fee, but support contracts, if bought, are a recurring cost to confirm with the vendor.
Engineering time for checklists and scans	One-time build, then recurring upkeep	Internal engineers or an implementation partner under a fixed-scope agreement	Number of restored asset types and how often checklists change. Reusing one indicator-of-compromise checklist across server, endpoint and database restores lowers effort.
Restoration exercise time	Recurring	Internal recovery team, with partner support if scoped	Restore frequency and the number of systems tested per exercise. Sampling a defined subset of systems each cycle, and documenting the sample rule, keeps effort predictable.
Vulnerability and remediation checks on restored systems	Recurring	Internal security staff, or the licensed platform if already owned	Tooling already owned, such as Wazuh (GPL-2.0-only) or Fleet (MIT) for software inventory matching. Confirm that a local offline vulnerability copy is supported in your environment before counting it as no-cost.
Evidence upkeep	Recurring	Internal compliance or operations staff	Volume of restore records and how they are stored. Standard log and ticket templates that capture the verification result, reviewer and root-cause status reduce rework at audit time.
External review or red-team validation	Recurring or periodic, depending on contract	Independent testing firm or security testing provider	Regulated scope and whether a third party must validate root-cause remediation. Ask the provider to scope the check to specific restored systems rather than the whole estate.
Auditor sampling effort	Recurring at each assessment cycle	Independent auditor (fee set by the auditor engagement), internal staff for evidence pulls	Number of restore events in the audit period. Keeping one consistent evidence set per restore makes sampling faster and reduces follow-up requests.

Who owns restored-asset verification and what to outsource

Your organization owns RC.RP-05. The CSF 2.0 outcome is that the integrity of restored assets is verified, systems and services are restored, and normal operation is confirmed, and that outcome belongs to the people accountable for the service. Your team decides what counts as acceptable, who signs off that a system returns to production, and whether the root cause of the incident has been remediated. These are judgments about business risk and cannot be delegated to a vendor.

Acceptance criteria: Define in advance what a restored system must show before production use, such as clean malware scans, expected patch levels and validated configuration baselines.
Sign-off authority: Name the individuals who approve each restored service going live, and record their decisions with timestamps.
Root-cause decisions: Decide whether the cause is closed, including any residual risk accepted in writing.
Exception handling: Document who may approve a deviation from the criteria and under what conditions.
Evidence ownership: Keep the signed records in your own repository so they remain available after any partner engagement ends.

Before engaging anyone, confirm that these decisions have named owners and that the sign-off record would make sense to an assessor who never saw the incident.

Where RC.RP-05 usually fails and how to close each gap

RC.RP-05 fails less often on technology than on process: the restore happens, but nobody can show what was accepted, by whom, against which criteria, or whether the cause was removed. The six gaps below share one pattern, where evidence is either missing or produced by the same people whose work it is meant to check.

No acceptance criteria for restored assets

Teams often declare a system restored once it boots and answers a login prompt. An assessor will ask what 'restored and verified' means for that asset. Define the checks in advance for each asset class: file integrity against the known-good baseline, expected services running, configuration matching the approved build, and no unexplained listening ports or new accounts. Record the criteria in the recovery plan so they exist before the incident begins. Confirm with your recovery owner that each criterion can be tested with a tool you already run.

Verification by the person who restored

When the engineer who ran the restore also signs off on it, no one independent has checked the result, and the sign-off carries little weight with an assessor. Assign verification to a second person or team, ideally one who did not perform the restore and who works from the acceptance criteria rather than memory. Keep the sign-off record separate from the change ticket, with the verifier's name, the time, the asset identifier and the results. Ask your auditor which separation of duties they expect for your environment.

Root-cause fixes not tied to the restored system

Implementation Examples for RC.RP-05 expect checks that the incident's root causes were remediated before a restored system returns to production. In practice, the patch or configuration change is recorded in the incident ticket but never checked on the restored host, so the same weakness can come back with the data. For each root cause, add a verification step that tests the fix on the specific asset, such as confirming the patched package version or the hardened setting. Confirm that your vulnerability tooling reports against the restored host, not only against the original fleet.

Restores never exercised

Backups that have never been restored in a test produce no evidence that the restore path works, and a recovery under pressure is the wrong place to discover a missing key or an incomplete catalog. Schedule restore exercises for representative systems and keep the results: the target, the time taken, the checks run and the outcome. Where the backup tool supports it, use its verify jobs and periodic data checks, and keep their logs. Ask whether your last exercise restored a full system or only individual files, since an assessor will treat those differently.

Scan results without retained output

Teams often run a malware or vulnerability scan after restore, see a clean summary on screen, and then close the ticket with no copy of the report. The evidence is gone as soon as the console session ends. Export each scan result, store it with the incident record, and note the tool version, rule or signature date and the asset scanned. Where the scan is a vulnerability check, the Wazuh and Fleet vulnerability documentation explains how inventory is matched against advisories, which helps you explain what a clean result means.

No monitoring baseline after return to service

A restored system that returns without a recorded baseline gives no way to tell normal behavior from a reinfection. Capture the expected process list, open ports, scheduled tasks, user accounts and log volume at the moment the system is confirmed normal. Enable the monitoring agents on the restored host before it rejoins production, and set alerts that compare current state to that baseline. Confirm with your security operations lead that the baseline is stored outside the restored system so that it cannot be altered along with it.

Questions buyers ask about RC.RP-05 cost, effort and audit

How much effort does RC.RP-05 take to meet?

The effort depends mostly on how many systems your recovery plan covers, how many restore paths each one has, and how much verification evidence already exists. RC.RP-05 asks that restored assets be checked for indicators of compromise and root cause remediation before production use, and that restoration actions be verified before a system goes back online. Each critical system needs a documented check, a named owner, and a record of the result. Organizations with a tested restore process and clear acceptance criteria usually spend far less effort than those building both from scratch. No general duration is set by NIST, so ask any provider to estimate effort from a written list of in-scope systems.

Can we meet RC.RP-05 in-house without outside help?

Yes, an organization can meet RC.RP-05 with its own staff, because NIST's Core describes outcomes and the organization owns its controls. The harder part is usually skill and capacity: the team must know how to verify backups, scan restored images, and confirm that the vulnerability or compromise that caused the incident is fixed. Outside help is most useful when the team has not run a full restore exercise or lacks tooling for integrity checks. An implementation partner can prepare systems and evidence, but only an independent auditor issues any report, and NIST does not certify compliance.

What does the recovery work need from our team?

RC.RP-05 needs people in four roles: a recovery lead who signs off on restoration, system owners who confirm normal operation, security staff who check for indicators of compromise, and someone who records root cause remediation. The team also needs access to backup repositories, asset inventories, and monitoring data for the restored systems. Before any exercise, agree who can declare an asset safe to return to production. Written roles and authorities make the evidence easier to defend later. Confirm which of these roles already exist in your incident response plan before scoping any work.

How long does it take to prepare RC.RP-05 evidence?

Evidence preparation time depends on whether restore records, integrity check outputs and sign-off forms are already kept consistently. Most of the work is collecting logs of each restore, the checks run before production use, the remediation tickets tied to the incident's root cause, and the approval for return to service. If these records exist for past incidents or exercises, preparation is mainly a review and gap-filling task. If they do not, the first cycle takes longer because the process must be defined as well as documented. Ask any provider for a timeline tied to a written scope and a named sample of systems.

Does NIST certify that we comply with RC.RP-05?

No, NIST does not certify compliance with the CSF or any subcategory. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. Compliance claims for RC.RP-05 therefore rest on your own documented evidence, and any independent assessment is performed by an outside assessor who issues its own report. Be cautious with any vendor that offers a NIST certificate, since none exists for this purpose. Ask providers to state in writing which party issues each deliverable.

What will an auditor sample when testing RC.RP-05?

An assessor typically samples recent restores or exercises and checks whether each restored asset was verified before production use. Expect requests for a few representative systems, the integrity check output for each, evidence of root cause remediation, and the approval that returned the system to service. The assessor will also look for consistency: the same steps should appear in procedures, tickets and records. Keep restore logs that identify the backup used, so the sample can be traced back to a verified source. Confirm the exact sampling method with your chosen assessor before the review starts.

Can a partner run restore exercises for our systems?

Yes, DeployOpen plans, implements, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, and restore exercises can be included in a fixed scope agreed in writing before work starts. Such an exercise can cover restore testing with tools such as Bareos for backup and restore jobs, restic consistency checks that read pack files back, and vulnerability review of restored endpoints with Wazuh or Fleet. Your team still owns the decision to return a system to production. Ask for the exact systems, restore targets, pass criteria and evidence formats in the written scope.

What changes the cost of meeting RC.RP-05?

Cost is driven by scope and maturity, not by the subcategory itself. The main drivers are the number of critical systems, the number of backup sources, how often restores must be exercised, whether the environment is cloud, on-premises or air-gapped, and how much evidence must be retained. Costs are one-time for designing the verification process and recurring for exercises, log retention and reviews. When you request a quote, ask which items are one-time and which recur, and what the provider assumes about your existing backups and incident records.

Where to read the official text and mappings

The authoritative text for RC.RP-05 is the CSF Core in Appendix A of NIST CSWP 29, the *NIST Cybersecurity Framework (CSF) 2.0* publication. Read the Subcategory wording there before you write any internal control statement, because your own policies and evidence should match what the outcome actually says: restored assets are checked for integrity, systems and services are restored, and normal operation is confirmed. Use the CSWP 29 PDF as the reference copy for your change control records, and note the publication date so later readers can tell which version your program was assessed against.

The Implementation Examples for RC.RP-05 and its informative references are not in CSWP 29. They sit in NIST's CSF 2.0 Reference Tool export, which is the place to check the two examples on indicators of compromise and pre-production root cause remediation, and the mappings to SP 800-53 control CP-10 and ISO/IEC 27001:2022 Annex A control 5.26. Because NIST updates these online, pull the export on the date you assess and record that date in your evidence file. Confirm the current list with NIST rather than relying on a copy saved from an earlier review.

If your program was built on CSF 1.1, the CSF 1.1 to CSF 2.0 Core transition spreadsheet shows that RC.RP-05 is new in 2.0, so there is no older Subcategory to inherit evidence from. Ask your assessor to treat this outcome as a gap until you have documented restore verification steps for it. The same spreadsheet helps you explain the change to the board and to any customer whose questionnaire still refers to CSF 1.1 numbering.

How DeployOpen prepares restored-asset verification and evidence

DeployOpen plans and builds the technical checks that show restored systems are clean, correctly configured and back in normal operation, inside your own infrastructure. The organization owns its recovery decisions and its CSF 2.0 outcomes, and an independent assessor is the party that tests them.

How we scope

The written scope lists which restored systems, services and backup sets fall under RC.RP-05 verification.
Scope names the integrity checks for each asset class, such as indicators of compromise and root cause remediation evidence.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure verification steps before production use, such as restore-then-scan gates and vulnerability checks on restored hosts.
Backup verification uses tools such as restic check with read-data options to confirm stored data is unmodified.
We test restoration actions in a staging environment so the post-restore checklist is proven before a live incident.

How we hand over

Handover includes runbooks that define who signs off each restored asset and what evidence that sign-off requires.
Evidence packs record check outputs, timestamps and remediation records, organized so an independent assessor can sample them.
We document the gaps we found and the open items your team must close before the control is ready for assessment.

How we support

Ongoing support, upgrades and continuous testing of the verification tooling are available as a retainer.
We can re-run restore verification exercises after platform upgrades or significant changes to your environment.
Ask your assessor which evidence format they accept before we finalize the evidence pack.