Availability / Resilience
Tier 0 and Tier 1 recovery procedures are tested at least annually and high-value backups are sampled for restore or validation at least quarterly unless an approved alternate cadence exists.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
Recovery exercises demonstrate that selected systems, data, dependencies, people, and instructions can restore a usable service within the business's documented recovery expectations.
First SOC 2 program
On a documented, risk-based schedule, restore a critical data set into an isolated environment, validate its integrity, walk through a broader service-recovery scenario, and track every finding to completion.
As the company scales
Rotate technical restore, regional failure, dependency loss, credential loss, and continuity scenarios across service tiers while measuring recovery time, recoverable data point, manual steps, and unresolved risk.
Select a service, failure condition, backup or replica, dependencies, and participants based on business impact and previous test coverage.
You should end up with: Approved recovery test plan and scope
Record expected recovery time, acceptable data point, validation checks, decision owners, safety boundaries, and evidence to capture.
You should end up with: Measurable recovery acceptance criteria
Use the documented procedure and realistic access path to recover the selected data or service without relying on undeclared knowledge.
You should end up with: Timestamped restore and activity record
Confirm completeness, data consistency, application behavior, permissions, dependencies, and the ability to resume the intended business process.
You should end up with: Signed recovery validation results
Record actual timing, data loss, failed steps, missing access, stale contacts, and manual workarounds against the planned criteria.
You should end up with: Recovery test report with measured variance
Assign each finding, update procedures or systems, and repeat failed or high-risk portions until the corrective action is demonstrated.
You should end up with: Closed findings with retest evidence
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Documents that define the control, its scope, ownership, and expected way of working.
Confirm what the record proves
Before execution, the team defined a specific recovery scenario, participants, source copy, safety boundary, timing targets, validation checks, and evidence to capture; the plan alone does not prove recovery succeeded.
Include this context
Scenario and scope
Include this context
Planned date and participants
Include this context
Source copy or recovery path
Include this context
Success criteria
Include this context
Safety boundary
Include this context
Approver
Weak evidence to avoid
A blank recovery checklist or a plan written after the exercise that contains no selected copy, measurable criteria, participants, or approved date.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
Participants worked through a defined recovery scenario, made role and escalation decisions, and identified procedural or dependency gaps; it does not substitute for a technical restore result.
Include this context
Scenario
Include this context
Exercise date
Include this context
Participants and roles
Include this context
Decisions and timeline
Include this context
Observed gaps
Include this context
Facilitator
Weak evidence to avoid
A calendar invitation showing a continuity meeting occurred without the scenario, decisions, participants' roles, findings, or action record.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
A selected backup or recovery path was actually used and produced identifiable data or service capability whose integrity and usability were validated.
Include this context
Exercise and source-copy ID
Include this context
Start and completion times
Include this context
Restore target
Include this context
Actions performed
Include this context
Integrity and usability results
Include this context
Operator and verifier
Weak evidence to avoid
A screenshot of a restore button or successful job message with no source copy, target, elapsed time, data validation, or service check.
Confirm what the record proves
Recovery exercises record specific deviations from success criteria, their impact, priority, owner, and required corrective action.
Include this context
Exercise ID
Include this context
Failed criterion or observed gap
Include this context
Impact
Include this context
Owner
Include this context
Due date
Include this context
Status
Weak evidence to avoid
A lessons-learned paragraph with no link to the exercise, affected criterion, accountable owner, due date, or tracked status.
Confirm what the record proves
The team corrected recovery weaknesses and repeated the failed or high-risk step until the expected result was demonstrated.
Include this context
Original finding
Include this context
Corrective change
Include this context
Owner and completion date
Include this context
Retest scope and date
Include this context
Retest result
Include this context
Verifier
Weak evidence to avoid
A runbook edit marked complete without evidence that the failed restore step or dependency was tested again.
Type 1
The current risk-based recovery exercise schedule and procedures, an approved upcoming or recently executed test plan, and the latest completed technical restore or recovery exercise with validation, findings, and retest state at the review date.
Type 2
Every recovery or restore exercise expected under the period-effective exercise schedule during the review period, including technical restores, service-recovery exercises, and explicitly scheduled recovery table-tops, with completed, failed, missed, cancelled, rescheduled, and retested occurrences. Routine backup job executions are excluded from this record set.
Start with the approved recovery exercise schedule effective during each part of the review period, including documented additions and changes, and reconcile every expected exercise ID to a plan and a completed, missed, cancelled, rescheduled, failed, or retested result; do not use routine backup run history as a substitute for recovery-exercise completeness.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: Recovery exercises demonstrate that selected systems, data, dependencies, people, and instructions can restore a usable service within the business's documented recovery expectations.
Compare the documented owner with the intended role (Operations Lead / Infrastructure Owner), then compare dated records with the stated cadence: Continuous for backups/monitoring; quarterly/annual testing as defined.
Start with the approved recovery exercise schedule effective during each part of the review period, including documented additions and changes, and reconcile every expected exercise ID to a plan and a completed, missed, cancelled, rescheduled, failed, or retested result; do not use routine backup run history as a substitute for recovery-exercise completeness.
The current risk-based recovery exercise schedule and procedures, an approved upcoming or recently executed test plan, and the latest completed technical restore or recovery exercise with validation, findings, and retest state at the review date.
Every recovery or restore exercise expected under the period-effective exercise schedule during the review period, including technical restores, service-recovery exercises, and explicitly scheduled recovery table-tops, with completed, failed, missed, cancelled, rescheduled, and retested occurrences. Routine backup job executions are excluded from this record set.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Before execution, the team defined a specific recovery scenario, participants, source copy, safety boundary, timing targets, validation checks, and evidence to capture; the plan alone does not prove recovery succeeded.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates Participants worked through a defined recovery scenario, made role and escalation decisions, and identified procedural or dependency gaps; it does not substitute for a technical restore result.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates A selected backup or recovery path was actually used and produced identifiable data or service capability whose integrity and usability were validated.
For each selected record, confirm it demonstrates Recovery exercises record specific deviations from success criteria, their impact, priority, owner, and required corrective action.
For each selected record, confirm it demonstrates The team corrected recovery weaknesses and repeated the failed or high-risk step until the expected result was demonstrated.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.