What SOC 2 A1.3 asks you to prove about recovery
SOC 2 criterion A1.3 requires the organization to test the recovery plan procedures that support system recovery. The points of focus for this criterion name two areas an auditor will look at: tests of the business continuity plan, and tests of the integrity and completeness of backup data. If an auditor asks how your team knows the recovery plan works, the honest answer has to be a dated test with recorded results, not a description of the plan. A1.3 is an availability criterion, so it applies only when the availability category is included in the examination. When it is in scope, the work covers the full recovery path: the continuity plan, the runbooks engineers would follow during an outage, and the backups those runbooks depend on.
The risk is simple. A recovery plan that has never been exercised often fails at the point it is needed most, because restore steps are out of date, credentials have rotated, a backup job has been silently failing, or the people named in the plan have left. Backups that appear to run successfully can still hold incomplete or unusable data. Confirm with your auditor which tests they expect to see, how often, and whether a tabletop exercise of the continuity plan counts alongside a technical restore. Ask them which sample of systems they will select, since that choice shapes what you need to prepare.
This is where teams most often fall short. Many organizations have backup jobs, runbooks and a continuity document, but no record that anyone restored data from them in the review period, what was restored, how long it took, or what went wrong. For a Type 2 report, the auditor needs evidence across the observation period, not a single test run the week before fieldwork. Start by deciding which systems are in scope, who owns each recovery procedure, and where test records will be kept. Then run restores on a schedule, keep the output with the date, and log every failed test and the fix that followed. Those records, rather than the plan itself, are what the auditor will test.
How an assessor tests SOC 2 A1.3
This table walks through the steps an assessor takes to test A1.3 recovery plan testing, from reading the plans to sampling test exercises and backup integrity checks. Read each row as a test step with the evidence it requests and the findings that commonly follow, and note that the assessor examines your controls without performing the recovery work.
| Test step | Evidence the assessor requests | Common findings |
|---|---|---|
| Review the recovery and business continuity plans | Current recovery and business continuity plans, approval records, and the system scope they cover | Plans that do not match the current system description, or plans with no named owner or approval date |
| Inspect the test schedule and plan | Annual test calendar, written test plans with objectives, scope and success criteria, and the tester for each exercise | Tests planned in the calendar but never scheduled or run, and test plans without defined pass or fail criteria |
| Inspect test results over the period | Test reports for each exercise in a Type 2 observation period, or the most recent exercise before the Type 1 date, with timestamps and participants | No test run during the period, or results that record only that a test occurred with no outcome |
| Check backup integrity and completeness tests | Logs of integrity checks such as repository consistency checks or data read-back, and restore test records showing which data was restored and how completeness was confirmed | Restore tests that confirm a job finished but not that the restored data was complete or usable |
| Trace failures to follow-up | Issue tickets, remediation records, retest results and any changes made to the plan after a failed test | Failed restores or missed recovery objectives with no follow-up, or no retest before the next period |
| Sample test exercises | Auditor-selected samples from the population of tests and backup verifications, with supporting evidence for each sample | Samples that cannot be produced because test records were stored in personal folders or not retained |
| Confirm management responsibility | Evidence that management reviewed test results and approved any plan changes | Test results never reviewed by an accountable owner, so the plan is not updated from lessons learned |
Implementing A1.3 step by step
This sequence turns A1.3 from a statement in a policy into tested recovery procedures, dated test records and tracked fixes that an auditor can sample across the observation period. Each step ends with a document or record the organization can hand over.
Name the recovery procedures in scope
Start by listing every recovery procedure that supports the in-scope system: the business continuity plan, the disaster recovery runbooks, backup and restore procedures for each data store, and the incident recovery steps that CC7.5 also touches. For each procedure, record the named owner, the systems it covers and the dependencies on cloud accounts, data centers or third-party services. Management approves the list. The output is a recovery procedure inventory with owners and system boundaries that matches the system description and the control matrix.
Define the test schedule and test types
Write a schedule that covers two test families: business continuity plan exercises, such as tabletop walkthroughs or simulated outages, and integrity and completeness checks on backup data. For each test, state the objective, the scope, the expected result, the person who runs it and the reviewer who signs off. Set the frequency in the schedule itself, and record who approved it and when. The output is an approved test calendar that the auditor can compare against the tests actually performed.
Configure backup verification in the tooling
Set up the tools that produce verification evidence before the first formal test. In Bareos, confirm that the Director runs verify jobs against the catalog and that restore selections from the current backup and from an earlier point in time work as documented. In restic, schedule repository checks, and use the read-data or read-data-subset options at a frequency the schedule sets, so pack files are read back and checked against stored data. Keep the job logs and the exit status of each run. The output is a configured verification job set with retained logs.
Run and record the first tests
Execute the scheduled tests as written. For a backup test, restore a defined sample to an isolated location, compare file counts, checksums or application-level checks against the expected state, and record what was restored and from which point in time. For a business continuity exercise, walk through the plan with the named roles, note decisions, timing observations and gaps, and file the attendance list. Each test produces a dated record with the objective, the result and the reviewer's signature. The output is a completed test record for every scheduled test.
Log failures and track fixes to closure
Treat every failed verification, missed step or unclear instruction as a finding. Open a ticket that names the procedure, the failure, the root cause if known, the owner and the corrective action. Retest after the fix and record the retest against the original finding. Note any deviation from the schedule with a reason and an approval. The output is a findings log where each item shows an open date, a fix, a retest result and a closure approval. Auditors commonly sample these records, so incomplete entries are worth correcting before fieldwork.
Set a review cadence that keeps results current
Establish a recurring management review of recovery test results, open findings and schedule adherence, with minutes that record decisions. Update the recovery procedures when systems, cloud accounts, backup targets or staff change, and reflect those changes in the inventory and the test calendar. Confirm that each review covers the full period since the last one, so the Type 2 observation window contains continuous evidence. The output is a set of review minutes and updated procedures that show the program is maintained, not created once for the audit.
Open-source tools that support backup restore and integrity testing
Bareos is an open-source backup system built around a central Director. The Director schedules and supervises backup, restore, verify and archive jobs, and it keeps a SQL catalog of the files it has backed up. That catalog is what lets an operator restore selected files from the current backup or from a backup taken before a given date and time. Each restore and verify run leaves a job record in the Director, which gives the team a starting point for test evidence.
- Scheduled verify jobs: Verify jobs compare backed-up data against the catalog or the source, so the team can show that jobs ran and what they checked.
- Restore job records: Every restore test creates a job record that can show the date, the job type and the outcome.
- Point-in-time selection: Restores from an earlier backup let the team test recovery to a known prior state, not only the latest copy.
- Catalog protection: The SQL catalog is itself a dependency. Confirm how it is backed up and whether a catalog loss would block recovery.
- License terms: Bareos is licensed under AGPL-3.0-only. Confirm with counsel what those terms mean for your distribution model, especially if you modify the software or provide it to third parties.
Before you rely on Bareos job records as audit evidence, confirm that the scheduled test jobs match the recovery procedures your business continuity plan describes.
restic is an open-source backup program licensed under BSD-2-Clause. Its check command verifies the structural consistency of snapshots, trees and pack files in a repository. Run without options, check confirms structure. With --read-data or --read-data-subset, it reads pack files back from storage to confirm that the stored backup data has not been modified. That second step is the part most relevant to an integrity test of backup data.
- Structural checks: The default check run confirms that snapshots, trees and pack files are consistent with each other.
- Full data reads: The --read-data option reads every pack file, which gives the strongest integrity result but takes longer and costs more in storage egress and time.
- Partial data reads: The --read-data-subset option reads a portion of the data on each run, which can spread the work across a test schedule. Confirm the subset approach covers the data your recovery plan depends on over time.
- Logged output: Save the check output and exit status to a log store that the team can review and retain.
- Permissive license: BSD-2-Clause allows broad use, but confirm the notice and attribution terms that apply to your build.
Confirm that your check schedule, read scope and retention of the output are written into the backup test plan, and that someone reviews and signs off on the results.
Backup tools produce logs and job records. They do not decide what should be tested, how often, who reviews the results or what happens when a test fails. An assessor looking at A1.3 will expect a documented plan that covers business continuity plan tests and integrity testing of backup data, with evidence that the plan was followed and that exceptions were handled. Neither Bareos nor restic performs business continuity exercises such as tabletop walkthroughs, failover of dependent services, or coordination with business owners, so those activities need their own records.
- Test plan: Define which systems, data sets and recovery objectives each test covers, and the criteria for pass or fail.
- Scheduling: Document the frequency of restore tests, verify jobs and check runs, and who owns each one.
- Reviewed results: Keep tool logs alongside a dated review, the reviewer's name and the follow-up actions.
- Exceptions: Record failed restores or integrity errors, the root cause and the retest that closed the issue.
- Continuity exercises: Plan and record business continuity tests separately, using your own runbooks and participants.
Before the audit period begins, check that each tool's logs can be exported, retained and tied to a named test plan entry.
Which evidence passes an A1.3 test
An assessor testing A1.3 wants to see that the recovery plans exist, were approved, were exercised on a schedule, and that failures were fixed and fed back into the plans. The cards below cover the artifacts that tie those steps together, and each one needs to be kept current between audits, not assembled the week before fieldwork.
Written recovery and continuity plans
Keep the business continuity plan and the disaster recovery procedures as dated, versioned documents that name the systems in scope, recovery roles, recovery time and recovery point objectives, and the backup sources each procedure depends on. Record the approver and approval date on every version. Store the approved copies in a location with access logging and review them at least once a year and after any material change to the platform, such as a new database cluster or a move to a different backup tool. An assessor will compare the plan to the systems actually running, so a plan that names retired hosts is a finding.
Test schedule and owners
Maintain a written calendar that lists each recovery test, its scope, the system owner, and the date it is due. The schedule should cover full restores, partial restores, tabletop exercises of the continuity plan, and integrity checks on backup sets. Review it each quarter and record the review, including any test that moved and why. Assessors use the schedule to check whether tests happened as planned across the whole observation period, so gaps between the schedule and the test records are usually the first thing they query.
Dated test records with restore verification
Each test should produce a record with the date, the tester, the systems and data in scope, the backup set used, the steps performed, and the measured outcome. For restores, record the restored target, the file counts or checksums compared, and whether the application started and passed a functional check. For integrity testing, keep the output of the verification run. With Bareos, the restore job log and catalog entries show which backup was restored; with restic, the output of restic check and any --read-data-subset run shows whether pack files were read back and found unmodified. Store the raw logs alongside the summary.
Tickets for failed tests and corrective actions
A failed restore or an incomplete backup is expected to happen at some point, and what the assessor looks for is how it was handled. Open a ticket for every failed or partially successful test, record the root cause, the owner, the corrective action, and the closure date with evidence of the fix. Link the ticket to the test record it came from. Tickets that stay open across several test cycles without explanation will draw questions, so track their age and escalate those that pass the agreed closure period.
Plan updates after each test
Every test should feed back into the plans. Record what the test showed, which procedure steps were wrong or missing, and the version of the plan that was revised as a result, with its new approval date. This closes the loop an assessor is checking: test results change the documented recovery procedure. Keep a change history that links each revision to the test or incident that prompted it. Plans that never change after several years of tests suggest the tests are not being evaluated.
What meeting A1.3 costs in money and effort
This table breaks down the cost components of running recovery plan tests for A1.3, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to see where open-source tooling saves license spend but not operating effort.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Backup tooling | Internal platform team or implementation partner; no license fee for self-hosted open-source tools such as Bareos or restic | One-time setup, then recurring operation | Removes license spend, but installation, configuration, upgrades and monitoring still need staff time |
| Restore test design | Internal engineers or implementation partner who scope which systems and data sets are tested | One-time design, revised when systems change | Number of recovery procedures, number of systems in scope and how often architecture changes |
| Running and recording restore tests | Operations staff, plus whoever signs off on results | Recurring, per test cycle | Restore frequency, data volume restored, and whether checks are automated or manual |
| Backup integrity verification | Operations staff configuring verify and check jobs in the backup tool | Recurring, with setup as a one-time task | Data volume to verify, depth of read-back checks, and retention period of backup sets |
| Business continuity exercise facilitation | Internal continuity lead or an external facilitator if bought | Recurring, per exercise | Number of scenarios, number of participants, and whether exercises cover more than one site |
| Remediation of failed tests | Engineers who fix the gap, then retest | Unpredictable, recurring when failures occur | Quality of earlier tests, documentation of recovery steps and dependency complexity |
| External testing or review, if bought | Independent security or resilience firm, under a written scope | Usually one-time per engagement, sometimes recurring | Scope breadth, number of environments and whether the firm reviews evidence or runs the tests |
| Auditor sampling and fieldwork | The CPA firm conducting the examination, under its engagement letter | Recurring each examination period | Number of recovery tests in the period, quality of test records and how many samples the auditor selects |
| Evidence preparation | Internal compliance lead or implementation partner assembling records | Recurring, per examination period | How well test results are logged at the time they occur rather than reconstructed later |
Why a backup job log does not satisfy A1.3 on its own
A successful backup job shows that data was copied on a schedule. It does not show that the copy can be restored intact, that it is complete, or that the people named in the recovery plan can carry out the steps. A1.3 asks the organization to test the recovery plan procedures that support system recovery, so the backup log is an input to the test, not the test itself. A backup job log proves the copy step ran, and nothing more. Auditors will ask for evidence that recovery was exercised, and a green job history alone will not answer that question.
Close the gap by linking three kinds of evidence. First, verify the backup data itself: restic's check command with --read-data or --read-data-subset reads pack files back to confirm the stored data is unmodified, and Bareos verify jobs compare backed-up files against the catalog. Second, run restore tests that bring selected files or a full system back into an isolated environment and compare the result with the expected state, recording who ran it, when, and what was compared. Third, include backup failure and restore scenarios in business continuity exercises so that staff follow the documented procedure under realistic time pressure. Confirm with your backup vendor which verify and restore operations your version supports and how they log their results, because the auditor will want those logs preserved.
Note the boundary with A1.2, which covers the backup processes, offsite storage and recovery infrastructure that make recovery possible. A1.3 covers testing those processes. Decide before fieldwork which restore tests will run, how often, and who signs off on the results, and keep the test plans, scope, exceptions and remediation tickets as evidence. The auditor will test whether the tests happened as described during the examination period, so a schedule that exists only on paper will surface as an exception.
Who owns A1.3: your team, a partner and the auditor
Your organization owns A1.3. The recovery plans, the business continuity plan and the decision to accept or fix a failed test all sit with management, and an auditor will look for named owners who can show they reviewed each test. Your team decides what the test scope covers, which systems and data sets are in it, and how often tests run. Someone on your team runs or witnesses each test, signs off the recorded results, and decides what remediation follows when a restore is slow, incomplete or fails the integrity check.
- Plan ownership: Named owners maintain the business continuity and recovery procedures, and they approve changes after each test.
- Test scope approval: Management signs off which systems, backup sets and recovery objectives are tested and why those were chosen.
- Execution and witnessing: Staff run restores or watch a partner-run test, and they record who was present and what was observed.
- Results and remediation: Your team records pass, fail and partial outcomes, opens tickets for gaps, and tracks them to closure.
- Management representations: Leaders provide the written representations an auditor requires, so the statements about test history must be accurate.
Before the observation period starts, confirm that each of these owners can explain their test results to the auditor without relying on a partner.
An implementation partner such as DeployOpen can prepare the technical side of recovery testing. For a self-hosted platform, that usually means setting up backup and restore tooling inside your own cloud accounts, data centers or air-gapped network, writing test scripts and record templates, and running integrity checks that produce output your team can review. The partner prepares the systems and evidence. It does not own the controls, decide the scope of the business continuity plan, or issue any report.
- Backup tooling setup: Partners configure self-hosted tools such as Bareos for job scheduling and restores, or restic for repository checks, inside your environment.
- Restore test automation: Scripts can perform scheduled restores into an isolated target and log the results, which reduces manual effort for recurring tests.
- Integrity verification: Partners run checks such as restic's structural verification and its data read-back option, and they keep the output with the test record.
- Evidence preparation: Test templates, run logs, catalog exports and remediation tickets are organized so your team and the auditor can sample them.
- Documentation and handover: Runbooks explain how each test is executed, so your staff can repeat it after the engagement ends.
Confirm in writing which of these tasks are in scope, who approves each change to the test design, and who keeps the logs after handover.
The independent CPA firm conducting the SOC 2 examination tests whether A1.3 controls were designed appropriately and operated effectively during the examination period. It samples test records, inspects restore logs and integrity output, interviews the people who ran the tests, and reports exceptions. Only the auditor issues the report. Because the auditor must stay independent, it cannot design the controls it then tests, so it will not write your recovery plan or build the test scripts.
- Design testing: The auditor checks that the recovery plan and test procedures address business continuity and backup integrity.
- Operating effectiveness: For a Type 2 report, it samples tests across the period and checks that each was performed, reviewed and followed up.
- Record inspection: Auditors compare the logs with the scope your team approved, looking for gaps between planned and executed tests.
- Exceptions: Missed tests, unreviewed failures or unresolved remediation appear as exceptions in the report.
- Independence boundary: Setup work by a partner is acceptable, but the auditor will not accept a control it helped design as an independent test of that same control.
Ask your audit firm which evidence it expects for A1.3 and how it treats partner-prepared artifacts before you finalize the test design.
Questions buyers ask about A1.3 cost, time and effort
What does the A1.3 recovery plan testing work need from our team?
The work needs named owners, scheduled time for test runs, and access to the backup systems being tested. Assign one owner for the recovery plan, one for backup operations, and one for the business continuity exercises, and record who holds each role in the control matrix. Engineers need enough time to restore data into an isolated environment, compare results against expected outcomes, and document exceptions. Ask the auditor which test records they will sample, because a test that ran but was never written up will not count as evidence. Access should be granted through a controlled, logged process so the test itself can be shown to the auditor.
Can we do A1.3 testing ourselves without outside help?
Yes, a team can do A1.3 testing in-house if it has the skills to run restores and integrity checks and the time to run and record them on a schedule. The criterion asks the organization to test its recovery plan procedures, including business continuity plan tests and checks of the integrity and completeness of backup data, so the organization owns the outcome. Tools such as Bareos and restic can produce restore and verification output, but the team must decide what to test, run the tests, and keep dated records of results and follow-up actions. Outside help is most useful when the team lacks restore experience or capacity, and an implementation partner can prepare systems and evidence, but it cannot issue the audit opinion.
What drives the cost and effort of A1.3 testing up or down?
Cost and effort rise with the number of systems in scope, the volume of backup data, how many recovery scenarios the plan covers, and how many tests must be repeated after failures. Hosting model matters too: restores into isolated environments in your own cloud account or data center take more setup than restores into an existing lab. Effort falls when backup jobs already produce catalogs and verification logs, when runbooks are current, and when test results are captured automatically. Ask any provider to price each cost component separately: tool setup, test design, test execution, evidence capture, and remediation. Also ask which costs are one-time and which recur each test cycle.
How long does A1.3 recovery plan testing take to complete?
No supplied figure gives a duration for A1.3 testing, so this page will not state one. Duration depends on the number of systems, the size of the restore sets, the complexity of the business continuity exercises, and how quickly failed tests are fixed and retested. Ask any provider for a written scope and timeline before work starts, covering which systems are tested, which test types are included, what deliverables you receive, and what your team must supply and when. For SOC 2 purposes, the more important timing question is whether tests run across the full observation period of a Type 2 engagement, so ask your auditor how many test instances they expect to see.
Can a partner run our recovery tests, and can our auditor prepare the evidence?
A partner can help run the tests, design the test plan, and prepare systems and evidence, but the organization remains responsible for its controls. The auditor cannot prepare the evidence for you, because an independent auditor must stay independent of the work it examines. If the same firm designed and ran the tests and then issued the report, the independence of the examination would be compromised. Confirm in writing who performs each test, who signs off on results, and who keeps the records. Only an independent CPA firm issues a SOC 2 report. DeployOpen prepares systems, controls and evidence for compliance assessments, and it does not issue audit reports or attestations.
What should we confirm about open-source license terms before deploying backup tools?
Confirm the license of each backup tool before deployment, because license terms govern what you may run, modify, and distribute. Bareos is licensed under AGPL-3.0-only, and restic is licensed under BSD-2-Clause, and these terms differ in obligations if you modify the software or offer it to users over a network. Have legal or procurement review the license for your intended use, including any internal modifications and integrations. Also confirm the license of every add-on, plugin, or dependency in the recovery chain, since each can carry its own terms. Your auditor will not review licensing, but a clear record of approved tools and their license terms helps show the change management and vendor oversight that SOC 2 expects.
How DeployOpen prepares A1.3 test evidence
DeployOpen approaches A1.3 Recovery plan testing as an implementation task inside the client's own infrastructure. We prepare the recovery test procedures, the backup integrity checks and the records an auditor will ask to see, while the organization owns its controls and an independent CPA firm performs the examination.
How we scope
- Agree in writing which systems, backup jobs and recovery procedures fall inside the A1.3 test scope
- Confirm which business continuity plan tests and backup integrity tests the organization already runs
- Define the test cadence, owners and sign-off roles before any work starts, in a fixed-scope agreement
How we build
- Configure backup verification in the client's own environment, such as Bareos catalog checks and restic repository checks
- Set up scheduled restore tests with recorded inputs, outputs and pass or fail results for each run
- Prepare test scripts and runbooks that map each recovery step to the business continuity plan
How we hand over
- Deliver test records showing backup integrity results, restore outcomes and any corrective actions taken
- Document the recovery test procedures and the evidence trail an auditor would sample for A1.3
- Walk the control owners through the evidence so they can repeat the tests without outside help
How we support
- Offer ongoing support as a retainer for repeat recovery tests, upgrades and evidence collection between audits
- Revisit test scope when systems, backup tools or recovery sites change during the observation period
- Confirm with your CPA firm which evidence formats and sample periods it expects before tests begin
