Safeguard 11.5 Test data recovery: requirements and evidence

What CIS Safeguard 11.5 test data recovery asks you to prove

Safeguard 11.5 requires you to test backup recovery at least quarterly, using a sample of in-scope enterprise assets, and it is the only IG2 safeguard in Control 11 that proves backups can actually be restored. Having backup jobs that report success is not enough. The safeguard asks for evidence that files, systems or data sets come back out of the backup in a usable state. CIS Controls v8.1 places it in the Data asset class and the Recover security function, so it applies to IG2 and IG3 enterprises but not IG1. The Assessment Specification scores it with a Backup Integrity Quality metric, the share of restored backup samples that work properly, and it is measured at zero if more than three months pass between recovery tests. The risk is simple to state and easy to miss. Backups can exist, appear healthy in a dashboard, and still fail when needed because of corrupted data, missing encryption keys, incomplete application state, expired credentials or a restore procedure nobody has run in years. Ransomware makes this worse, since attackers often target backup catalogs and repositories before they encrypt production. A rehearsed restore is the only direct test that the recovery path still works. Organizations find this hard for two reasons. Restores are rarely rehearsed because they disrupt production staff and need a non-production target. Sampling also depends on an accurate asset inventory, so you need to confirm that Safeguard 1.1, the detailed enterprise asset inventory, is current before you can choose a defensible sample. Ask your team which assets are in scope, which backup jobs cover them and who owns each restore. Safeguard 11.5 sits beside Safeguards 11.2 to 11.4 and does not repeat them. Automated backups (11.2), protection of recovery data (11.3) and an isolated copy (11.4) determine what is backed up, how it is secured and where a clean copy lives. Safeguard 11.5 checks whether those choices work end to end. Decide who signs off on each test, record the assets, the restore target, the time taken and whether the restored data was verified, and keep those records as evidence for an assessor. Open-source tools such as Bareos and restic can support the restore and verification steps, but confirm their capabilities against your own environment and the vendor documentation before relying on them.

Which assets and teams fall under CIS Safeguard 11.5 test data recovery

Safeguard 11.5 applies only to IG2 and IG3 enterprises, and its sample is drawn from in-scope assets listed in the inventory. The cards below cover the scoping decisions, the platforms and teams that produce restore evidence, and the third-party services whose restore records you need to collect.

Implementation Group 2 and 3 only

Safeguard 11.5 is assigned to IG2, so it applies to IG2 and IG3 enterprises and does not apply to IG1 organizations. Confirm your Implementation Group before you schedule the work, because an IG1 enterprise that tests restores anyway will not be measured against this Safeguard. If your enterprise has grown into IG2 criteria, the Safeguard applies from that point, and the first quarterly test should be documented as the baseline for the assessment.

Data asset class and Recover function

In v8.1, Safeguard 11.5 sits in the Data asset class and the Recover security function. That placement tells assessors that the subject is the data itself and the ability to return it, not the backup software configuration. Use it to explain the scope to auditors: the test proves recoverability of business data, so the evidence should name the data sets restored, not only the job logs.

Defining the in-scope sample

The Safeguard requires testing on a sample of in-scope enterprise assets, so you must first define which assets are in scope and then choose the sample. Pick a mix that includes critical servers, databases, file shares and cloud workloads, and rotate the selection each quarter so every critical system is restored over time. Record the selection rationale, since an assessor will ask why a given system was or was not sampled.

Dependency on the asset inventory

Safeguard 1.1, the detailed enterprise asset inventory, is a prerequisite for measuring Safeguard 11.5. Without a current inventory you cannot prove that the sample represents the in-scope estate or that no critical system was left out of backup coverage. Reconcile the backup job list against the inventory before each test cycle, and flag any asset that is in the inventory but absent from backup policies.

Backup platforms that produce restore evidence

Restore evidence usually comes from the backup platform's own records, such as job history, catalog entries and restore logs. Bareos, for example, uses a Director to schedule and supervise restore jobs and keeps a catalog of backed-up files, which lets you show which file versions were restored and when. Where you use restic, its check command with read-data options reads pack files back to confirm stored data is unmodified. Confirm which records each platform retains, because retention settings can remove evidence before the assessor asks for it.

Teams that own the restores

Restores are usually owned by infrastructure or platform operations, while the business data owner decides whether a restored data set is acceptable. Separate those roles in the test plan: operations performs the restore and records the result, and the data owner or application team confirms the restored content is usable. Name both people on each test record. Security or compliance should review the results but not run the restore themselves, so the evidence shows independent checking.

Third-party backup services

If a SaaS provider, managed backup service or cloud-native backup vendor holds your backups, you still need restore evidence for the in-scope assets it covers. Put a clause in the contract requiring the provider to support sample restores on request and to supply restore logs and success records. Ask the provider whether it can run a restore for your sample within your test window. Without this, your quarterly test may depend on a service you cannot inspect.

How the assessment specification turns a quarterly restore into a pass or fail

The CIS Controls Assessment Specification scores Safeguard 11.5 with a Backup Integrity Quality metric: the share of restored backup sampling deemed to be properly working. The metric is a ratio, so the result depends on two things you control, which assets you sample and whether each sampled restore produces data that is usable. A restore job that completes without errors does not count on its own. The reader's task is to define the sample, run restores against it, record what was recovered and judge whether it is correct. Each sampled restore either works or it does not, and the score follows from that record. The timing rule is separate and stricter. Under the specification, Safeguard 11.5 is measured at zero and fails if more than three months pass between backup recovery tests. A quarterly cadence therefore leaves a small margin, and a missed quarter fails the safeguard regardless of how well the earlier restores went. Build the test calendar, named owner and evidence retention around that gap so a delayed test cannot quietly lapse. Prerequisite work also matters: the specification lists Safeguard 1.1, the detailed enterprise asset inventory, as a prerequisite, so an incomplete inventory makes the sample hard to justify.

The specification defines what to measure, not how to run the restore. It does not prescribe sample size, the choice of assets, the restore destination, the level of data comparison or the acceptance criteria for a partial restore. Those decisions belong to your organization and must be documented and agreed with your assessor before the first test is counted. Confirm with the assessor how they expect the sample to be drawn, whether they want restores to an isolated environment, how they will verify recovered data and which evidence they will accept for each test date. Ask whether a failed sampled restore lowers the metric for that cycle and what remediation they expect before a retest. Open-source tools can produce much of this record. Bareos keeps a SQL catalog of backed-up files and restores selected files from the current backup or from one before a given date and time, which gives you restore logs tied to specific jobs. restic's check command verifies structural consistency, and with --read-data or --read-data-subset it reads pack files back to confirm stored data is unmodified. Those checks show the repository is sound, but they do not replace a restore of a sampled asset to a usable state, so keep both in the evidence pack and document the link between them.

How an assessor tests CIS Safeguard 11.5 test data recovery

This table sets out what an assessor checks for Safeguard 11.5, the evidence they ask for, and the findings that most often cause a failed measure. Read it as a checklist for your own test records before an assessment starts, since the Safeguard is measured at zero once more than three months pass between recovery tests.

Assessor check	What the assessor does	Evidence requested or common finding
Test cadence	Confirms restore tests happened at least quarterly, with no gap longer than three months between tests	Dated test records across the review period. Finding: no dated tests, or a gap that exceeds three months
Sample source	Checks that the sampled assets come from the in-scope enterprise asset inventory, which depends on Safeguard 1.1	Sample list cross-referenced to the asset inventory. Finding: samples drawn from systems outside the defined scope
Sample coverage	Checks that the sample represents the in-scope assets and that it changes between test cycles	Sample lists for each cycle. Finding: the same single system tested every quarter with no rationale
Restore re-performance	Re-performs a restore or observes one live, from the backup set and into a controlled target	Restore logs, target system identifiers, operator and timestamps. Finding: logs show a job status but no restore into a target
Backup Integrity Quality	Determines the share of sampled restores that produce properly working backups	Pass and fail results per sampled asset with the reason for each failure. Finding: failures recorded without follow-up
Data usability	Opens or validates restored data to confirm it is complete and usable, not only present	Application or file validation results, checksums or agreed test cases. Finding: testing stops at backup job success
Results and remediation	Checks that failed restores were investigated and retested before the cycle closed	Remediation tickets, retest dates and sign-off. Finding: failed restores not retested or not linked to a root cause

Implementing a restore test program that survives an audit

This sequence turns Safeguard 11.5 into a repeatable program: it fixes scope, samples real backups, proves restores work against known content, and leaves a dated record an assessor can trace from schedule to result.

Confirm IG2 scope and the asset inventory
Confirm that your enterprise falls under Implementation Group 2 or 3, since Safeguard 11.5 does not apply to IG1 organizations. Then check that the detailed enterprise asset inventory required by Safeguard 1.1 is current, because the CIS Controls Assessment Specification lists it as a prerequisite for measuring 11.5. The output is a signed scope statement naming the in-scope enterprise assets and the inventory version it relies on. Ask your assessor which inventory evidence they expect to see.
Define and rotate the restore test sample
Select a sample of in-scope enterprise assets that covers the main backup types you run, such as file, database and virtual machine backups, and record the selection criteria. Rotate the sample each test cycle so that every asset class is eventually exercised, not only the convenient ones. The output is a sample register listing each asset, its backup job, the test date and the reason it was chosen. Keep the register as evidence that the sample is representative rather than handpicked.
Write the restore test procedure and success criteria
Document the step-by-step procedure for each sampled asset: which backup set to select, the target location, the restore command or console steps, and who performs and who reviews the test. Define success criteria in measurable terms, such as the restore completing without errors and the restored content matching the expected files or records. Your backup platform's own documentation should guide the commands, for example the restore selection and verification features in Bareos or the check options in restic. The output is an approved test procedure version-controlled with the backup policy.
Run restores in a non-production environment
Perform each test restore into an isolated non-production environment so that a failed or partial restore cannot overwrite live data or disrupt operations. Restore from the backup copy that the test is meant to validate, and record the start time, end time, operator, source job and any errors. Where the backup tool supports integrity verification, run it as part of the restore cycle and capture the output. The output is a completed test run record for each sampled asset.
Verify restored data against known content
Compare restored data with content whose correct state you already know, such as a seeded test file with a recorded checksum, a known database row set, or a reference application dataset. A restore that completes without error but produces wrong or missing content is a failure, so the comparison must be explicit. Record the match result for each item and the percentage of sampled restores that verified correctly, which feeds the Backup Integrity Quality measure in the assessment specification. The output is a verification report signed by the reviewer.
Log results and track corrective actions
Enter each test result into a single register that links the test run, the verification evidence and any defects found. For every failed or partial restore, open a corrective action with an owner, a root cause and a retest date, and do not close the item until a later restore of the same asset passes. Keep the failed records, since an assessor will look for how you responded to failures as much as for passing tests. The output is an up-to-date results log with open and closed corrective actions.
Set the quarterly schedule and escalation path
Put the recurring restore test on a calendar that keeps the gap between tests within the three-month limit in the assessment specification, and assign a named owner for each cycle. Define an escalation path so that a test that is overdue or fails twice reaches the CISO or equivalent manager within a timeframe you set and document. Review the schedule and escalation rules at least once a year as part of the Control 11 review. The output is an approved schedule, a named owner and an escalation record that shows what happened when a test was missed.

Evidence for CIS Safeguard 11.5 test data recovery in an audit

An assessor testing Safeguard 11.5 wants to see a repeating cycle of planned, executed and reviewed restore tests, not a single successful restore. The cards below cover the artifacts that prove that cycle, and the register and calendar that keep them retrievable between audits.

Dated test plan and sample list

The test plan states the quarterly cadence, the restore method, the expected recovery point and the owner for each test. The sample list names the in-scope enterprise assets chosen for that cycle and records why each was picked, such as a database, a file server or a virtual machine image. Check that the sample rotates across quarters and that each asset carries an ID that matches the asset inventory required by Safeguard 1.1, because the assessment specification treats that inventory as a prerequisite for measuring 11.5.

Restore run records

Each restore run needs a record showing who started it, when it began and ended, which backup set or snapshot was restored, the target location and the result. Logs or job reports exported from the backup system serve as the primary proof. Ask whether restores went to an isolated target rather than production, since a test that overwrites live data is a finding in its own right. Store the raw job output alongside the summary so an assessor can trace a claim back to the system record.

Integrity verification results

A restore that completes is not yet proof that the data is usable. The assessment specification scores 11.5 with the Backup Integrity Quality metric, which is the share of sampled restores found to be working properly. Keep the checksum, application-level validation or record-count comparison used for each restored asset, and the pass or fail outcome. For file-based repositories, a verification command such as restic check with read-data options can supply an independent integrity result that the restore log alone does not give.

Catalog and snapshot references

For each tested asset, record the catalog entry, job identifier or snapshot ID that the restore used, along with its creation time. This lets an assessor match the restored data to a specific backup point and confirm that the restore came from the backup schedule set under Safeguard 11.2, not from a manually created copy. Bareos keeps a SQL catalog of backed-up files that can be queried for this, and restic identifies each snapshot by ID. Confirm that catalog exports are retained with the restore records.

Defects, remediation and re-tests

A failed restore is expected to appear in the register, with a root cause, an owner, a fix and a re-test that passes. Assessors look for this loop because it shows that the program responds to failure. Record the date each defect was opened and closed, and link the re-test run to the original failure. A register with no failures across several quarters invites questions about whether testing was thorough, so state the sample and method clearly.

Approval records and test calendar

Approval records show that a named owner reviewed each quarter's plan and results and accepted any residual risk. Pair them with a test calendar that lists each planned restore window, the responsible person and the due date for the next test. The calendar is the simplest proof of cadence: the assessment specification fails 11.5 when more than three months pass between tests, so gaps must be visible and explained. Keep a single register that indexes every plan, run, result and approval, so an assessor's sample can be pulled from one place.

Open-source tools that support restore testing

Bareos is an open-source backup system built around a central Director that schedules and supervises the work. For restore testing, the Director runs restore jobs against selected assets and records the outcome, so a test can be scheduled on a recurring basis rather than run by hand. Its SQL catalog tracks which files were backed up and when, which helps the team show which assets were included in a sample and which backup version was restored.

Scheduled restore jobs: The Director can run restore jobs alongside backup, verify and archive jobs, so restore tests can follow a fixed calendar that supports a quarterly cadence.
Catalog of backed-up files: The SQL catalog lists backed-up files, giving the team a record to match against the asset sample.
Point-in-time selection: Files can be restored from the current backup or from one taken before a given date and time, which lets testers check older recovery points.
License: Bareos is licensed under AGPL-3.0-only, so the license terms should be reviewed by legal counsel before modifying or distributing the software.

Confirm the Director, catalog and restore behavior against the current Bareos documentation for the version you deploy, and keep the job logs as test evidence.

What meeting CIS Safeguard 11.5 costs in money and effort

This table lists each cost component of running Safeguard 11.5 restore tests, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Read it as a checklist for a written quote: the recurring rows drive the long-term cost, while the one-time rows mostly reflect the initial build of the test process.

Cost component	Who is paid or who carries the cost	One-time or recurring	Main drivers and how to keep it down
Backup tooling or licenses	Software vendor for commercial products; no license fee for self-hosted open-source tools such as Bareos or restic	Commercial licenses recur; open-source removes license spend	Open-source tools remove license spend but not operations. Ask whether any add-on modules, support contracts or storage gateways are priced separately.
Engineering time to design the test process	Internal staff or an implementation partner under a fixed-scope agreement	One-time	Driven by the number of in-scope asset classes and how many backup policies exist. Reusing one documented procedure across similar systems keeps it shorter.
Engineering time to run restore tests each cycle	Internal operations or platform staff	Recurring, at least quarterly under Safeguard 11.5	Driven by sample size, the number of asset types sampled and the manual steps involved. Scripted restores and standard runbooks reduce hands-on time per cycle.
Restore environment capacity	Cloud provider, data center team or hardware owner for isolated restore hosts and storage	Recurring while tests run, plus a one-time setup	Driven by data volume and restore time for the largest sampled assets. Restoring a representative sample to a smaller isolated environment, with full-size tests only where needed, limits capacity spend.
Evidence upkeep	Internal compliance or security staff, sometimes with a partner preparing templates	Recurring	Driven by how many test records, logs and sign-offs must be kept per cycle. A consistent test record template and automated job logs reduce manual collection.
External review or testing	Independent reviewer or assessor, if the organization buys a review of its restore testing	Optional and usually recurring if bought each cycle	Driven by scope and whether the review is a readiness check or a formal assessment. Ask for the scope in writing and whether results are reported as findings or advice.
Auditor sampling	Independent auditor or certification body, billed under its own engagement terms	Recurring with each audit cycle	Driven by how many restore tests the auditor samples and how well records are indexed. Clear test records mapped to assets reduce the time spent answering sampling requests.
Remediation of failed restores	Internal staff or partner, depending on who fixes the defect	Variable, recurring when failures occur	Driven by the number of failed restores and how far they expose gaps in asset inventory or backup coverage. Keeping Safeguard 1.1 asset inventory current limits surprises.

Where organizations fall short on restore testing and how to close each gap

Most organizations run backup jobs and assume they can restore. Safeguard 11.5 asks for proof, so the gaps that matter are the ones that let a restore test look successful while the data, the sample or the people behind it fail under real pressure. The cards below pair each gap with a closing action you can check before an assessor does.

Testing job success, not restored content

A green backup job only shows that data was written. Safeguard 11.5 is about whether the data comes back usable. Check that each test restores files to a separate location, compares them with the source using checksums or known test files, and opens application data to confirm it loads. Record the comparison result, not only the job status. For restic repositories, restic check --read-data-subset reads pack files back to confirm the stored data is unmodified, which is stronger evidence than a job log alone.

Sampling from an incomplete inventory

The sample of restored assets is only as representative as the list it is drawn from. If backups cover servers but miss endpoints, virtual machines spun up outside change control or SaaS tenants, the sample misses exactly the assets most likely to fail. Safeguard 1.1, the detailed enterprise asset inventory, is a prerequisite for measuring 11.5. Before each test cycle, reconcile the inventory against backup policies and select the sample from the reconciled list, documenting which assets were excluded and why.

Tests that lapse between quarters

The assessment specification measures Safeguard 11.5 as failing when more than three months pass between backup recovery tests. Teams often run one strong test and then let the schedule slip under operational pressure. Put recovery tests on the same change calendar as patching and certificate renewals, assign a named owner for each cycle, and set an alert when the next test date passes without a logged result. Keep the calendar itself as evidence of cadence.

Untested cloud and SaaS restores

Teams frequently assume that cloud snapshots or SaaS vendor retention cover their data without ever restoring it. Restoring a cloud volume into a new account, or recovering a mailbox or repository from a backup copy, can expose missing permissions, unavailable keys or undocumented dependencies. Include at least one cloud or SaaS data source in the sample when it is in scope, and confirm the restore path with the provider's documentation. Where a provider's recovery terms are unclear, ask for them in writing before relying on them.

No record of who approved results

An assessor will look for evidence that a person reviewed each test and accepted or rejected the outcome. A restore log with no reviewer, or a spreadsheet edited after the fact, does not show that. For each test, record the assets sampled, the restore method, the comparison results, the failures and their remediation, and the name and date of the approver who is independent of the engineer who ran the restore. Store these records where they cannot be silently changed.

Restores that depend on one engineer

When only one person knows the restore procedure, quarterly testing stops the moment that person is unavailable. A restore runbook that exists only in someone's head will also fail during an incident, when Safeguard 11.1 and the isolated copy under 11.4 matter most. Write the runbook with exact commands, credentials locations and decision points, have a second engineer execute one test from it, and record any step that needed tribal knowledge so it can be written down.

Who does what for Safeguard 11.5: your team, a partner and the auditor

Your organization owns Safeguard 11.5. That means the enterprise decides which in-scope enterprise assets are sampled, who approves each restore test, and whether a failed restore is accepted as a finding or remediated. The Safeguard is measured against a Backup Integrity Quality metric, the share of restored backup sampling deemed to be properly working, and the assessment specification fails the Safeguard at zero if more than three months pass between tests. Someone on your staff must therefore own the test calendar and the sign-off.

Ownership: Name an accountable owner for the Safeguard, usually in the security or infrastructure function, who answers to the auditor for the result.
Sample selection: Choose the sampled assets from the detailed asset inventory described in Safeguard 1.1, which the assessment specification lists as a prerequisite.
Test execution and approval: Run or supervise restores, record who approved the outcome, and decide what happens when a restore does not complete.
Evidence ownership: Keep restore logs, screenshots or job output, and the test calendar in a location you control and can produce on request.
Remediation: Fix the causes of failed restores, such as catalog gaps, expired keys or missing credentials, and retest.

Before engaging any partner, confirm internally who will sign the test records and how long those records are retained.

Questions buyers ask about CIS Safeguard 11.5 test data recovery

Does CIS Safeguard 11.5 apply to an IG1 organization?

No. Safeguard 11.5 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises and not to IG1. IG1 organizations still need working backups under the earlier Control 11 safeguards, but the quarterly restore test is an IG2 expectation. Check your Implementation Group against the CIS Implementation Groups pages before you scope the work, since the group determines which Safeguards your assessment covers. Organizations that already run a restore test on a regular cycle may find that the effort is mostly documentation and evidence capture.

How much effort does the quarterly restore test take, and what drives it?

Effort depends on how many in-scope assets fall into the sample, how many different backup types you run, how large the restored data sets are, and whether restores need manual steps or can be scripted. The assessment specification measures the share of sampled restores that work properly, so every additional system type in the sample adds setup and verification work. Recurring effort is the quarterly cycle itself plus the evidence record. Ask any partner to break the quote into one-time build work (test runbooks, sampling method, scripts) and recurring work (each quarterly run, reporting and remediation of failed restores).

How long does it take to set up a restore test?

The setup time depends on the state of your backup estate, not on the test itself. The prerequisite is an accurate enterprise asset inventory under Safeguard 1.1, because you cannot sample assets you have not listed. Teams with a current inventory, documented backup jobs and a known restore procedure can set up a first test faster than teams that must discover what is being backed up. Agree a duration in the written scope before work starts, and ask for the assumptions behind it, such as the number of backup platforms and whether test environments already exist.

What does the work need from our own team?

Your team owns the controls, so it must supply several inputs. Someone must confirm the asset inventory and which assets are in scope, a backup owner must provide access to job logs and catalogs, and a system owner must agree that a restored copy can be opened and checked without touching production. Security or compliance staff need to define the sample and the pass criteria, and the people who handle exceptions need time to review failed restores. Plan for these people in advance, because most delays come from waiting for access and sign-off rather than from the restore itself.

Can we run the restore tests in-house with open-source tools?

Often yes, if your team already operates the backup platform. Bareos provides a Director that schedules and supervises backup and restore jobs and keeps a SQL catalog of backed-up files, which you can use to select and restore files from a chosen backup. restic's check command verifies the structural consistency of snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack files back to confirm the stored data is unmodified. Confirm that each tool covers your systems, and treat a structural check as supporting evidence only. The assessment looks for restored data that works, so keep records of actual restore runs, not only integrity checks.

What should we ask a partner for in a quote?

Ask for a written scope that names the assets and backup platforms in the sample, the restore method for each, the pass criteria, and the evidence the partner will hand over. Request a split between one-time setup and recurring quarterly testing, a list of what the client must provide, and the terms for failed restores. Confirm whether the partner will document the test procedure, retain run records and support a re-test after remediation. DeployOpen does not publish a price list, and a quote follows from the written scope, so the clearer the scope, the more comparable the quotes will be.

Who signs off that Safeguard 11.5 passes?

Your organization decides whether it meets the control, and the independent assessor or auditor who reviews your evidence reaches the formal conclusion. DeployOpen prepares systems, test runs and evidence but does not issue audit reports, attestations or certifications. Inside your organization, the control owner should review the quarterly results, accept or reject exceptions and record remediation. Ask a partner to show you the evidence package it will produce, including dated restore records, the sample used, and the outcome of each test, so your assessor can trace each result back to its source.

How DeployOpen prepares restore testing evidence for CIS Safeguard 11.5

DeployOpen plans, implements and documents self-hosted open-source backup platforms inside your own infrastructure, then prepares the restore testing records that show Safeguard 11.5 Test data recovery is working. We prepare systems and evidence; your organization owns the control and an independent assessor reviews it.

How we scope

Agree in writing which in-scope enterprise assets are sampled for quarterly restore tests and which are excluded.
Confirm the Safeguard 1.1 asset inventory is current so every sampled asset can be traced to its backup job.
Define the test cadence, the maximum gap allowed between tests and who signs off on each restore result.

How we build

Configure Bareos or restic jobs so each sampled asset has a documented backup and a repeatable restore procedure.
Schedule restore tests and integrity checks, such as restic check with read-data options, and capture their output as records.
Record restored data validation steps, including how restored files are compared against known-good originals.

How we hand over

Deliver restore test runbooks, sampling records, test logs and a Backup Integrity Quality calculation worksheet tied to each test.
Document failed restores, root causes and retest dates so the assessor can see how gaps were closed.
Walk your team through the evidence set so your staff can repeat the tests and explain the results to an assessor.

How we support

Fixed-scope engagements set deliverables and timelines in writing before any work starts, and quotes follow from that scope.
Ongoing support, upgrades and continuous testing are available as a retainer to keep quarterly restore testing on schedule.
Ask us to confirm which parts of the testing cadence your organization will run itself and which a retainer will cover.