RC.RP-03 backup integrity before restore: evidence and cost

RC.RP-03 backup integrity before restore: what NIST CSF 2.0 asks

Restoring from a backup is only safe if the backup is clean, so RC.RP-03 asks the organization to verify the integrity of backups and other restoration assets before any of them are used to restore. The risk is concrete: a team under pressure after an incident may restore a server image, database dump or file set that already contains attacker persistence, encrypted files or silent corruption, and then rebuild the incident on top of its own recovery. RC.RP-03 is a Subcategory of the Incident Recovery Plan Execution (RC.RP) Category in the RECOVER Function of CSF 2.0, as published in NIST CSWP 29. NIST publishes one Implementation Example for it: check restoration assets for indicators of compromise, file corruption and other integrity problems before use. CSF 2.0 is voluntary and NIST does not offer certification for it, so whether RC.RP-03 is met is judged by your own team or by an independent assessor you engage, not by a certificate.

What usually makes this hard is that backups were never tested as restores and no known-good baseline exists to compare against. Without a baseline of hashes or file attributes taken while systems were healthy, nobody can say whether a restored file differs from what it should be. Without restore tests, nobody knows whether the backup format is readable or whether the catalog matches the stored data. Practical decisions to make in advance include which backups are kept offline or immutable, who may approve a restore from a given point in time, and which checks run before data leaves the restore staging area. Open-source tools can supply parts of the evidence: Bareos keeps a catalog of backed-up files and runs verify jobs, restic's check command with --read-data or --read-data-subset reads pack files back to confirm they are unmodified, and Wazuh or osquery file integrity monitoring can compare restored files against a recorded baseline. Confirm each tool's current behavior in your own environment before relying on it as evidence.

When you assess this subcategory, ask for the restore procedure, a record of at least one recent restore test, the baseline used for comparison, and the results of integrity checks on the restored assets. Those records are the evidence an assessor will look for. A quote or scope for help with this work should name the backup systems in scope, the baseline method, the integrity checks, and who signs off before a restore proceeds. The organization owns the decision to restore and the evidence, an implementation partner can prepare the tooling and procedures, and only an independent assessor can give an opinion on whether the outcome is met.

Which backups and restoration assets does RC.RP-03 Backup integrity checks cover

RC.RP-03 reaches every asset a restore depends on, not only the nightly backup job. The scope you draw determines how many integrity checks you run, who performs them and how much evidence you must keep. The cards below mark the decisions that change that work most.

Backup repositories and catalogs

Backup repositories hold the data, and catalogs record which files sit in which backup set and when. Bareos, for example, keeps a SQL catalog of backed-up files and runs verify jobs against stored data. Scope both: a repository that passes a structural check can still hold data that no longer matches the catalog. Confirm which verification modes your tool offers and whether reading all stored data back is practical for your repository size and restore window.

Snapshots and the systems that hold them

Snapshots often sit on the same storage or hypervisor as production, so a compromised administrator account can reach both. Checking a snapshot means confirming its consistency and whether its source system showed indicators of compromise before the snapshot was taken. Scope the snapshot platform, its retention settings and the credentials that can delete or alter snapshots, since those credentials determine whether the copy can be trusted.

Restore media and offline copies

Tapes, removable disks and immutable or offline object storage are restore paths that attackers often cannot reach from the production network. Each medium needs its own check, such as a read test, a checksum comparison against the catalog or a scan on an isolated host. Record which media are in scope, where they are stored and how long a physical or logical retrieval takes, because that time shapes the recovery plan.

Golden images and configuration baselines

Golden images and configuration baselines are restoration assets too, because rebuilding a host from a tainted image restores the intrusion. Hash each approved image and baseline when it is signed off, then compare restore candidates against those hashes. Wazuh file integrity monitoring and osquery file integrity monitoring can record checksums and report changes to monitored files, which helps establish whether a baseline has drifted before anyone uses it.

Teams and managed backup providers

Backup administration is often split between an internal platform team, a security team and a managed backup provider. Each party holds keys, credentials or copies that count toward the scope. Decide who runs each check, who signs off the result and what the contract requires the provider to show. Confirm this allocation in writing before a restore is needed, since the answer changes both the work and the evidence trail.

Shared identities and backup credentials

Backup servers, catalogs and repository keys are high-value targets, and a restore can carry an attacker's access back into the environment. Include the accounts and encryption keys that unlock each repository in scope, plus any service accounts used for restores. Review who can change retention, delete copies or restore to production, because a restore integrity check cannot detect a restored account that was never checked.

How an assessor tests backup integrity before restore

This table walks through what an assessor checks for RC.RP-03, from the written procedure to sampled restores and exception handling. Read each row as a test step with the evidence it produces, and note where findings usually appear. The main takeaway is that a documented procedure alone does not pass; the assessor needs recorded integrity results from real restores.

Assessment step	What the assessor examines	Evidence requested	Common finding
Procedure review	Whether recovery and backup procedures include a named pre-restore integrity step, who performs it and which tools or checks are used	Current backup and restore runbooks, recovery plan sections, role assignments for restore approval	Procedures describe backups in general terms with no integrity step before restore
Scope of restoration assets	Whether the step covers backup sets, snapshots, configuration exports and other assets that could be used to rebuild systems	Asset list for restoration sources, with the storage location and owner of each	Only primary database backups are covered while images, keys or configuration exports are restored unchecked
Sampled recent restores	A selection of restores from the review period, checking whether each one has an integrity check recorded before the data was used	Restore tickets or job logs with timestamps showing the check ran before the restore started	Check results exist for test restores but not for live incidents or emergency restores
Known good state comparison	Whether restored or backed-up files were compared with a reference, such as stored checksums, a signed manifest or a verified catalog	Hash or checksum records, verification job output, catalog entries and where the reference values are stored	Checksums are generated at backup time but never compared with the stored copy before restore
Indicator of compromise and corruption checks	Whether checks looked for malware indicators and file corruption, not only for job success	Scan results, file integrity monitoring alerts reviewed for the backup window and integrity check reports	Backup job reports success, which is treated as proof that the data is clean
Verification testing of backups	Whether backup data is read back and tested on a schedule, with failures tracked to closure	Verification schedule, read-back test results and records of failed verifications and their follow-up	Backups are written but never read back, so corruption is found only during an actual restore
Exception handling	How the team responds when a check fails or cannot run, including who may approve a restore anyway and under what conditions	Exception log, approvals with names and dates, risk acceptance records and a note of the compensating checks used	Exceptions are approved verbally during an incident and never recorded or reviewed afterward
Post-review follow-up	Whether lessons from failed checks or exceptions changed procedures, tooling or backup schedules	Corrective action records, updated runbooks and review minutes from the improvement cycle	Failed checks are fixed in the moment but the procedure is never updated to prevent a repeat

How to verify backup integrity before restore, step by step

This sequence turns the RC.RP-03 expectation into a repeatable gate: every backup and restoration asset is inventoried, checked with the right test for its type, judged against written criteria, and locked into the restore runbook so no restore starts on unverified data.

Inventory every restoration asset
The recovery lead and the backup owner list each backup set, catalog, repository, golden image, installer and clean configuration that a restore could draw on, with its location, owner, retention and the systems it serves. Include copies held off-site or in cloud accounts, since these are often the ones used after an intrusion. The step is done when the list is reviewed against the asset inventory and no restore source is missing from it. Output: a restoration asset register.
Define the check for each asset type
The backup engineering team assigns a check to each type on the register. Backup catalogs need consistency checks against the stored data. Deduplicated repositories need structural verification and, periodically, reads of the stored data. Files need checksums recorded when they were written. Images and installers need malware scanning before use. Monitored systems need file integrity baselines. Output: a verification matrix that names the tool, the command or job, and the evidence each check produces.
Run checks against a clean baseline
Operators run the checks on the selected backup set before any restore. Bareos verify jobs can compare stored files with the catalog. restic check confirms snapshots, trees and pack files are consistent, and with --read-data or --read-data-subset it reads pack files back to confirm the stored data is unmodified. Wazuh or osquery baselines show whether monitored files changed after the backup date. Hash values of restored candidates are compared with the recorded values. Output: a dated verification record per asset with the tool version, scope, results and any exceptions.
Set pass and fail criteria with named decision makers
Before the first live restore, the CISO or incident commander approves written criteria for each check, such as zero consistency errors, matching hashes and no unexplained file changes since the baseline. The criteria state who may accept a documented exception and who must reject the set. The decision owner is named in the runbook, not left to the operator on shift. Output: approved pass and fail criteria with named approvers, stored under version control.
Record a signed decision to proceed
When checks finish, the incident commander reviews the verification record and signs a decision to proceed, restrict to clean sets, or reject and select an earlier backup. Rejected sets are quarantined and labeled so they are not reused. A failed check triggers a review of the backup chain, because corruption can predate the most recent set. Output: a signed restore authorization that references the verification record.
Add the check to the restore runbook as a gate
The restoration procedure is updated so that no restore step can begin until the verification record and signed decision exist. The gate lists each required check, the tool command or job and the approver. Runbook changes are reviewed by the recovery team and by the people who own backup systems. Output: a runbook version that includes the gate, with a change record showing the review.
Rehearse the gate and keep the evidence
The team runs the gated procedure in an exercise, using a non-production copy or a cyber range, and records how long each check took, which steps were unclear and which criteria needed adjusting. Findings feed back into the asset register and runbook. Ask your assessor which exercise records they expect to see, because rehearsal evidence supports the claim that the gate works under pressure. Output: an exercise report with corrective actions tracked to closure.

Evidence that proves backup integrity checks happen before restore

An assessor testing RC.RP-03 wants to see that the organization checked its backups and restoration assets before using them, not only that backups exist. The cards below are the records that show the check ran, who approved the restore, and whether the process works when tested. Each one should be kept current between audits by a routine that generates it, not by a one-time export.

Restore runbook with an integrity gate

The runbook is the written procedure that makes verification a required step before any restore begins. It should name the backup sets in scope, the verification method for each (catalog check, repository consistency check, or hash comparison), the person who signs off, and the action taken when a check fails, such as selecting an earlier backup. Review the runbook after each change to the backup platform and confirm the gate cannot be skipped in the restore procedure itself.

Verification job logs and reports

Verification jobs produce logs showing which backups were checked, when, and with what result. For Bareos, these come from verify jobs supervised by the Director. For restic, the output of restic check and any --read-data or --read-data-subset runs shows whether pack files still match stored data. Keep the reports for every backup set and set a scheduled review so a missed or failed job is noticed before an incident forces a restore.

File integrity baselines and alert records

A file integrity baseline records checksums and attributes of monitored files, so later changes can be detected. Wazuh file integrity monitoring and osquery file_events can flag created, modified or deleted files and record who or what made the change. Use these records to check restoration assets for indicators of compromise before use. Confirm that the baseline was captured from a known good state and that alerts are routed to a person who reviews them.

Restore approval records

Before a restore runs, an authorized person should approve the backup chosen, the integrity results behind that choice, and the target environment. The approval record links the decision to the verification evidence, so an assessor can see that someone reviewed the results rather than restoring from the newest backup by default. Store approvals in a system that keeps them unchanged, and ask who may approve, and whether approvers need a second person when the backup predates the incident.

Test restore results

Test restores prove that a verified backup can actually be restored, and they show how long the process took and what broke. Record the backup used, the restore target, the integrity checks performed on the restored data, and any gaps found. Rehearse on a fixed schedule set by the organization's own risk decisions, and feed each finding back into the runbook. An assessor will look for evidence that the most recent rehearsal led to a documented change.

What meeting RC.RP-03 backup integrity checks costs

This table breaks down the cost components of building and evidencing backup integrity checks before restore, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to frame a quote request, since no price list exists and every figure depends on your own backup estate and written scope.

Cost component	Who is paid	One-time or recurring	What drives it
Verification tooling or licenses	Software vendor or none if open source	Recurring if commercial, one-time setup otherwise	Number of backup platforms and whether verification features sit in a paid tier. Open-source options such as restic and Bareos can remove license spend, but confirm feature fit with the vendor or project.
Engineering time to build checks into backup and restore workflows	Internal staff or implementation partner	One-time	Number of backup jobs, data volume and how many restore paths must be instrumented with integrity steps before restore.
Indicator of compromise and corruption monitoring	Internal staff or implementation partner	One-time build, recurring tuning	Scope of file integrity monitoring such as Wazuh or osquery, including how many backup repositories and staging hosts are watched and how alerts are triaged.
Runbook and evidence upkeep	Internal compliance or security staff	Recurring	How often backup platforms, retention settings and restore procedures change, and how verification logs are retained for assessors.
Rehearsal time for restores	Internal recovery team	Recurring	Frequency of restore exercises, the number of systems in each exercise and whether tests include clean-room restores of suspect backups.
External testing or review	Independent assessor or security firm	Recurring, per engagement	Whether a third party reviews the verification design or tests restore integrity, and how many environments are in scope. Ask for a fixed-scope written proposal.
Auditor sampling effort	Internal staff supporting the auditor	Recurring, per assessment cycle	Number of backup and restore events an assessor samples and how easily records can be pulled from logs and tickets. Agree the sample set in advance with the auditor.

Open-source tools that verify backups and detect tampering before restore

Restoring from a compromised or corrupted backup can reinstate the attacker or the fault. The four tools below each produce a different piece of evidence that a restoration asset is intact: catalog and verify records, repository read-back results, file integrity alerts and file change events. Confirm fit for your environment before relying on any of them as the sole check.

Bareos catalog and verify jobs

Bareos is a backup system whose Director schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files. For RC.RP-03, the catalog gives you a record of what each backup contains and when, and verify jobs give you a documented check against that record before a restore is selected. Restores can be drawn from the current backup or from one taken before a given date and time, which helps when you suspect compromise predates the latest job. Confirm that verify jobs run against media you can actually restore from, and that your catalog itself is protected from the same compromise. License: AGPL-3.0-only, so confirm how the copyleft terms apply to your distribution and internal use with counsel.

restic repository checks

restic check verifies the structural consistency of snapshots, trees and pack files in a repository. Run without extra options, it confirms structure only. Adding --read-data reads every pack file back to confirm the stored data is unmodified, and --read-data-subset lets you sample pack files on a schedule when a full read is too slow for your storage. The evidence is the command output and exit status from each run, which you can retain as proof that a restoration source was checked before use. Confirm the read depth your recovery objectives can tolerate, and keep the repository password and keys out of the same blast radius as the data. License: BSD-2-Clause, a permissive license that generally imposes few redistribution conditions.

Wazuh file integrity monitoring

Wazuh file integrity monitoring records a baseline of checksums and attributes for monitored files and directories, then alerts when a user or process creates, modifies or deletes a monitored file. Scans run on a schedule or in real time, and alerts include how and when a file changed and who changed it. For RC.RP-03, this helps you decide whether a backup source or staging location was altered after it was last known good, and it produces alert records for the incident file. Confirm that the monitored paths include backup repositories, restore staging areas and the backup agent configuration, and that the baseline itself was captured before the suspected intrusion. License: GPL-2.0-only, so confirm the obligations that apply if you modify or distribute the software.

osquery file_events hashing

osquery can watch the paths you list under file_paths in its configuration and record each change in the file_events table with the action, time and path. Where possible it also calculates MD5, SHA1 and SHA256 hashes of changed files, so you can compare a restoration asset against a hash recorded earlier. For RC.RP-03, the table gives a queryable history of changes to backup catalogs, archives and restore scripts, and the hashes give you a comparison point. Confirm that the watched paths cover the restoration assets you rely on, that hashes are available for the file types you hold, and that the query results are exported somewhere the attacker cannot alter. License: Apache-2.0 OR GPL-2.0-only, so you may choose the license that suits your use.

Who verifies backups before restore: your team, a partner, the auditor

Your organization owns the decision to restore. Someone accountable on the security or operations side must decide whether a backup or restoration asset is trusted before it is used, and that decision belongs to staff who answer for the outcome. This is the restore gate: the point where a verification result, an indicator of compromise review or a corruption check either clears an asset for use or holds it back.

Restore gate ownership: Name the role that can approve or stop a restore from a given backup set, and document who substitutes when that role is unavailable.
Verification decisions: Decide which checks run before each restore class, what counts as a failed result, and when a backup older than the last known clean point is used instead.
Evidence retention: Keep verification logs, hash records, scan outputs and approval tickets in a location the restore team cannot alter after the fact.
Operational upkeep: Review check results on a schedule, investigate failures and confirm that exclusions and baselines stay current.
Oversight of partners: Hold the implementation partner to the written scope and review the evidence pack before it reaches an assessor.

Confirm that the named owner can show, for a sample restore, who approved it and which verification results they relied on.

Where backup integrity before restore usually fails

Restores often go wrong before any data moves, because the backup was never checked, the reference state was never recorded, or nobody was accountable for the decision to restore. The cards below cover the gaps we see most often when organizations try to show RC.RP-03 is met, with the closing action and the evidence an assessor would expect for each.

Backups never verified

Many teams confirm that a backup job finished without ever testing whether the stored data can be read back. Closing this gap means scheduling integrity checks on the backup repository itself. For restic repositories, run restic check regularly and add --read-data or --read-data-subset so pack files are read back and confirmed unmodified. Evidence is the scheduled job definition, its logs and a dated record of failures and how they were handled.

No baseline to compare against

Without a recorded reference state, nobody can tell whether a restored file is clean or was altered before the backup. Establish a baseline of checksums and attributes for critical files and directories, kept outside the systems being restored. Wazuh file integrity monitoring records such a baseline and alerts on changes, and osquery's file_events table records changes with hashes. Evidence is the baseline configuration, its scope list and the comparison output attached to each restore ticket.

Checks run only on the primary copy

Integrity checks often run against the production backup set, while the offsite or immutable copy used during a ransomware event is never examined. Verify every copy that could be a restore source, including replicas and archive tiers, and record which copy was checked. Confirm with your backup vendor how catalog and volume verification is run on each tier. Evidence is a per-copy verification record with timestamps and the identifier of the copy tested.

Restore runbooks with no gate

Restore runbooks often jump straight from selecting a backup to running the restore, with no step that stops the process if integrity is unconfirmed. Add an explicit gate in the runbook that blocks restoration until verification results are recorded and reviewed. Illustrative example: a step requiring a passed verification hash comparison before the restore command may be executed. Evidence is the versioned runbook, the completed gate checklist and any blocked restores with their reasons.

No record of restore approval

When a restore goes ahead, it is often unclear who decided the backup was safe to use and on what evidence. Assign a named role to approve restoration from each backup set, separate from the person running the restore where possible. Bareos keeps a catalog of backed-up files and restores from a chosen backup point, which helps tie an approval to a specific job. Evidence is the approval record with the approver, timestamp, backup identifier and verification results attached.

Questions about RC.RP-03 backup integrity cost, effort and outsourcing

What does it cost to verify backup integrity before restore?

No public price applies to this work, because the cost depends on your environment and scope. The main cost components are staff time to define verification steps, tooling (open-source tools such as Bareos, restic, Wazuh and osquery carry no license fee for the community editions, but licensing terms should be confirmed for your use), infrastructure to run test restores, and any external help. Setup costs are largely one-time, while checking, monitoring and periodic restore tests recur. Costs rise with the number of systems, the volume of data and how often you test restores. Ask any partner for a written scope listing the systems covered, the verification methods, the tools, the handover deliverables and the hours or fees behind each item.

How long does backup integrity verification take to set up?

The duration depends on how many backup sets, restore paths and systems you have, and on how much of the verification process already exists. Organizations with documented backup jobs and tested restores usually need less work than those that have never restored from their backups. Ask for a timeline in the written scope with milestones for inventory of restoration assets, configuration of checks, a first integrity test and a documented restore test. Treat any duration without a stated basis as a question to put back to the vendor or partner.

What does the internal team need to provide?

Your team needs to own the decisions that the framework expects the organization to make. These include which backups and restoration assets are in scope, who approves a restore, what counts as an indicator of compromise or corruption, and how a failed check is escalated. Engineers must have access to backup servers, catalogs, repositories and monitored hosts, and time to run and review test restores. Someone accountable for incident recovery should sign off the procedure. Partners can prepare the configuration and documentation, but the organization keeps the operational responsibility.

Can our own team verify backup integrity with open-source tools?

Yes, many teams can do this in-house if they have the skills and time to maintain it. The NIST implementation example for RC.RP-03 asks you to check restoration assets for indicators of compromise, file corruption and other integrity problems before use. Open-source tools cover parts of this: restic's check command verifies snapshot, tree and pack file consistency, and with --read-data it reads pack files back to confirm the stored data is unmodified. Wazuh and osquery can record file hashes and changes so you can compare restored files against known good baselines. Bareos keeps a catalog of backed-up files and supports verify jobs. Gaps usually appear in alerting, documentation and regular restore testing, so decide early who will run these checks after handover.

What will an auditor sample for backup integrity evidence?

An assessor typically asks to see how you verify backups before a restore, not only that backups exist. Expect requests for the backup and restore procedure, the list of restoration assets in scope, job and verify logs, records of integrity checks and any alerts raised, and evidence of at least one restore test with its results. Assessors may also select a recent restore and trace it back to the verification step that preceded it. Confirm the exact evidence expectations with your chosen assessor, because each framework that references this control may test it differently.

Does NIST certify that we comply with CSF 2.0?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. The CSF is voluntary for most organizations, though some customers or suppliers may require it. If a contract asks for evidence of alignment, ask for an independent assessment by a qualified assessor. DeployOpen prepares systems and evidence for assessments, but it does not issue audit reports, attestations or certifications.

What should a partner put in a written scope for this work?

A written scope should name the systems and backup sets covered, the verification methods used (such as repository checks, read-data tests, file integrity baselines and catalog comparisons), and the tools to be deployed or configured. It should list the deliverables, including procedures, configuration records, test restore reports and handover training, along with acceptance criteria and the dates or milestones that govern them. It should state what the organization must provide, who owns ongoing checks after handover, and whether support or retainers are included. Ask for the fee basis in writing as well.

How DeployOpen prepares backup integrity evidence for RC.RP-03

DeployOpen helps organizations prepare the systems, checks and records that show backups and other restoration assets were verified before use. The organization owns its recovery controls and decides what counts as acceptable integrity, and DeployOpen implements the self-hosted open-source tooling inside the client's own infrastructure. Assessment reports and conclusions come from the organization and its independent assessor, not from DeployOpen.

How we scope

Engagements are fixed-scope, with the written scope naming which backup systems, restore paths and asset types are covered for RC.RP-03.
The scope records which restoration assets are checked for indicators of compromise, corruption and other integrity problems before use.
Scope also confirms which evidence the client's assessor expects, such as verification job logs, check reports and documented restore decisions.

How we build

We configure backup platforms such as Bareos to run scheduled verify jobs and keep a catalog of what was backed up.
We set up restic repository checks, including data read-back options, to confirm stored backup data has not been modified.
We deploy file integrity monitoring with Wazuh or osquery to baseline checksums and alert on unexpected changes to restoration assets.

How we hand over

Deliverables include configuration records, runbooks for pre-restore integrity checks and the procedure for handling a failed check.
Test results from restore verification exercises are documented so the client can show the check ran before each restore.
Handover covers who in the organization reviews integrity results and who authorizes a restore after a check fails.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement.
Retainer work can cover updating checks when backup platforms, restoration assets or the client's threat picture change.
Organizations should confirm with their assessor which integrity evidence is sufficient before the engagement starts.