A1.2 SOC 2 backup and recovery: requirements and evidence

What SOC 2 A1.2 asks for before your first SOC 2 audit

If you are the compliance lead or engineer who has to show an auditor that backups and recovery work in practice, start here: A1.2 is an availability criterion that requires your organization to authorize, design or acquire, implement, operate, approve, maintain and monitor environmental protections, software, data backup processes and recovery infrastructure. The criterion exists because a fire, flood, power failure or hardware loss can destroy data or keep a service down for a long time if nothing was prepared in advance. An assessor is not satisfied by a backup policy alone. In a Type 2 examination, the CPA firm looks for operating evidence over the observation period, such as job logs, restore records and alert histories, which shows the protections ran continuously rather than being set up once for the audit.

The criterion is hard to satisfy because ownership is spread across teams. Infrastructure engineers usually own the facilities and hardware, security owns the threat model and the monitoring of environmental and storage alerts, and operations owns the backup schedules and restore procedures. Before your first audit, confirm in writing who approves each element and who reviews its output. Then map the points of focus that sit under A1.2 to your environment: identifying environmental threats to your sites and cloud regions, deploying detection and alerting for them, deciding which data needs backup, performing the backups, keeping copies offsite, and maintaining alternate processing infrastructure that can take over if the primary fails. Each of these needs a named owner and a record that it is operating.

DeployOpen plans, implements and documents the backup, monitoring and recovery systems in your own infrastructure, and prepares the evidence an assessor will request. It does not decide whether your controls meet the criterion, and it does not issue reports. Only the independent CPA firm performing your examination can do that. Ask the firm early which evidence it expects for each element, how far back it will sample, and whether it will accept restore test results from your own tooling. Those answers determine how much of the setup, and how much recorded operation, you need in place before the observation period begins.

Which systems, data and third parties fall under A1.2 scope

A1.2 applies only when availability is in the SOC 2 scope, and its reach depends on which systems hold production data and backup copies, where they run and who operates the underlying infrastructure. The cards below are the decisions that most change the size of the control set and the evidence an auditor will request.

Production data stores and backup copies

Start by listing every production database, file store, message queue and object bucket that holds customer data, then list every system that receives a copy of it. A1.2 requires the organization to determine which data needs backup, so the backup targets, catalogs and any replicas are in scope even when they are not customer-facing. Confirm that each store has a named backup job and that the job's source list matches the inventory.

Environmental threats at each location

Every physical or cloud location in scope needs a documented view of environmental threats such as fire, flood, power loss and temperature failure, along with the detection and protection measures that address them. For a self-hosted platform in your own data center, these controls sit with you. For a cloud deployment, they shift partly to the provider, and you must still show how alerts from those conditions reach your team.

Offsite storage and alternate processing sites

Decide which copies must leave the primary site and which processing capacity must exist elsewhere, such as a second cloud region or a secondary data center. Each choice creates a separate set of controls for transfer, encryption, access and location. Ask whether the alternate site is for backups only or also for running the service, because the answer changes what you must test and document.

Alerting on backup and environmental events

Backup failures, storage capacity warnings and facility alarms are only useful if someone receives them and acts. Identify the monitoring pipelines that cover backup jobs and environmental sensors, and the on-call routes that respond to them. Auditors commonly ask for alert rules, notification history and records showing how each alert was handled, so these pipelines belong in scope.

Cloud providers and colocation facilities

Cloud providers and colocation operators may hold controls over facility power, cooling, physical access and hardware replacement. Their SOC 2 or other assurance reports can cover part of your environmental controls, and you should map which points of focus those reports address. Confirm the report's period and scope against your own, and list any gaps the provider's report leaves for you to cover.

Backup configuration and restore testing

A provider's report does not replace your own backup configuration. You still own the retention settings, encryption keys, job schedules and restore tests that show backups can be recovered. Document who approves changes to backup policy and keep restore test results as evidence. Treat these items as in scope even when the facility beneath them is outsourced.

How to implement backup and environmental controls step by step

This sequence moves from identifying environmental threats and deciding what data must be backed up, through tooling, alerting and offsite copies, to a recurring review routine that produces evidence an auditor can test across the observation period.

Identify environmental threats for each location in scope
List every facility, cloud region, data center or office where in-scope systems and backup media operate, then record the environmental threats that could interrupt them, such as power loss, cooling failure, fire, flooding or regional outage. For each threat, note the detection measure and the protection mechanism already in place, and flag gaps. The output is a threat register with one row per location and threat, reviewed and approved by the control owner. The step is done when every in-scope location appears in the register and each gap has an owner.
Decide which data needs backup and document the retention rule
Work with system owners to identify which datasets, configurations, databases, secrets stores and infrastructure definitions the business cannot rebuild from source. For each, record the backup frequency, retention period, and who approves changes to that scope. The output is a backup scope document that ties each data class to a retention rule and a named owner. Your auditor will compare this document against the system description, so keep the two consistent. The step is complete when the scope document has been approved and linked from the control matrix.
Configure backup software and storage with clear ownership
Select the backup platform and storage targets that match the scope, then configure them. For example, a self-hosted Bareos Director can schedule backup, restore, verify and archive jobs and keep a SQL catalog of backed-up files, while restic offers snapshot-based repositories with a check command that verifies structural consistency. Record each configuration value, encryption setting and access role in a job configuration baseline under version control. Confirm the vendor's current capabilities for your chosen version before you commit to a design. The step is done when the baseline is approved and each job has a named operator.
Set up detection and alerting for backup and environmental signals
Instrument backup jobs and environmental sensors so that failures, missed schedules and threshold breaches generate alerts. Prometheus can collect metrics from instrumented jobs over HTTP and store them as time series that PromQL can query, while Grafana Alerting can build rules from queries across data sources and combine metric and log signals in one view. Define which events page on-call staff and which create tickets. The output is an alert rule set exported and stored with the configuration baseline. The step is done when a deliberately failed test job produces the expected alert and notification.
Define response procedures for each alert type
Write a short runbook for every alert in the rule set. Each runbook states the trigger, the first responder, the containment action, the escalation path, and the condition for closing the alert. Include environmental events such as power or cooling alarms, which may call for facilities staff rather than engineers. Link runbooks to the incident process used for other security events so that backup failures are handled consistently. The output is a response procedure library with version history. The step is done when each alert rule points to a current runbook and the on-call roster matches it.
Configure offsite and alternate processing copies
Place at least one backup copy outside the primary location, with separate credentials and access controls, and document where alternate processing can run if the primary site is unavailable. Confirm that encryption keys are recoverable without the primary environment. The output is an offsite storage and alternate infrastructure record that names the locations, the copy schedule and the recovery owner. Confirm the arrangements with your own legal and infrastructure teams and with any cloud or colocation provider, since contractual terms vary. The step is done when the record is approved and a copy has been restored from the offsite location.
Record the operating routine and ticket every exception
Establish a recurring review in which a named person checks job reports, verification results and alert history, then records the outcome. Define how an exception is raised, who triages it, how it is ticketed, and how a failed job is re-run and confirmed. The output is a review log and an exception register that link each failure to a ticket and its closure evidence. Keep the cadence you actually perform, because auditors test operating effectiveness across the period and will sample both routine reviews and individual exceptions. The step is done when the first review cycle is logged and each exception has a traceable ticket.

Which evidence passes A1.2 and how to keep it current

An assessor testing A1.2 looks for proof that environmental protections, backups and recovery infrastructure were designed, operated and monitored, not just described. The cards below cover the artifacts that usually carry that proof, and how to refresh each one between audits so the Type 2 observation period has no gaps.

Environmental threat register with review date

This register lists the environmental threats to the systems in scope, such as power loss, cooling failure, fire, flooding and regional outages, along with the detection and protection measure for each. A1.2 asks the organization to identify these threats, so the register is the starting point an assessor reads first. Confirm that each entry names an owner and that the review date is recorded. Re-review it on a fixed schedule and after any hosting change, and keep the prior versions so the register can be shown as it stood during the period.

Backup scope and retention documentation

This document states which data sets, systems and configurations are backed up, which are excluded and why, and how long each copy is retained. It answers the question an assessor asks first: how did the organization decide what needed backing up? Tie each scope decision to a data classification or a system inventory entry. When new services, databases or storage buckets appear, update the scope within the same change cycle so unprotected data does not exist for a period.

Backup job schedules and configuration exports

Exports of backup job definitions, schedules, retention rules and encryption settings show what the tooling was set to do. For a self-hosted stack, this may come from the Bareos Director configuration or restic repository settings, exported from version control or the running system. Export them on a regular cadence and store the output with a date. Compare each export with the previous one, so any change to a schedule or retention setting has a matching change record.

Backup job logs and failure tickets

Job logs show that backups ran across the full observation period, and failure tickets show what happened when they did not. An assessor will sample days and check for both the successful run and the response to any failure. Export logs on a fixed cadence to write-once or access-controlled storage, and link every failed or missed job to a ticket with a root cause and a closure date. Unexplained gaps are the most common reason an auditor raises an exception.

Restore and verification test records

Restore tests prove that backed-up data can be recovered, and verification records prove that the stored data has not been altered. Keep dated records showing which data was restored, to where, by whom, and whether the result matched the source. For restic, record the outcome of periodic checks, including any run with --read-data or --read-data-subset, which reads pack files back to confirm they are unmodified. Schedule restore tests across the whole period so the sample an assessor selects is covered.

Offsite and alternate-site replication records

These records show that copies left the primary environment and that an alternate processing location exists for the scope of the report. Keep replication logs, storage location configuration, and the date and result of any alternate-site failover exercise. Confirm the offsite copy is in a separate failure domain and that access to it is restricted. Review the records at the same cadence as the threat register, since a region change or new provider alters what is actually protected.

Alert rule definitions and notification history

Alert rules show what the monitoring stack watches for, such as failed backup jobs, storage capacity thresholds, replication lag and Prometheus scrape failures. Notification history shows that alerts reached a responsible person and were acted on. In Grafana Alerting, export the rule definitions and keep the notification log alongside the ticket system. Check that rules are tested after changes, because an alert that silently stopped firing is an unmonitored control.

How an assessor tests A1.2 and what findings usually appear

This table compares how an assessor approaches each part of A1.2, what evidence they ask for, and where organizations most often fall short. Read it as a checklist of what to prepare before fieldwork, and note that the Type 1 and Type 2 row changes what the auditor is looking for.

Area	Test approach and evidence requested	Common findings
Environmental threat assessment	Auditor reviews the documented list of environmental threats (for example fire, flood, power loss, cooling failure) and checks that it matches the facility and hosting locations in scope. Evidence includes the threat register, its review dates and the owner's sign-off.	Threat register not updated after a data center, cloud region or office change; threats listed without a named owner or review date.
Detection and protection mechanisms	Auditor inspects configured sensors and protections, such as temperature, power and disk health monitoring, and confirms they cover the in-scope infrastructure. Evidence includes configuration exports, monitoring dashboards and asset lists.	Monitoring covers production but not backup repositories or offsite locations; thresholds set once and never reviewed.
Alert and response handling	Auditor selects alerts from the period and traces each to a ticket, the response taken and closure. Evidence includes alert history, tickets, on-call records and post-event notes.	Alerts firing with no ticket or documented response; alert routing sent to a former employee's mailbox.
Identification of backup data	Auditor compares the documented list of data requiring backup against the system inventory and data classification. Evidence includes the backup scope document, job definitions and the mapping to systems.	New databases or object stores added to production without being added to backup scope; scope document dated before the last platform change.
Backup execution across the period	Auditor samples backup jobs across the audit period, checking that each sampled job completed, that failures were detected and that reruns or fixes are recorded. Evidence includes job logs from the backup server, catalog entries and failure tickets. Sample sizes follow the auditor's methodology, so confirm them during planning.	Failed jobs with no ticket or no evidence of rerun; gaps in job history during maintenance windows with no explanation.
Restore testing	Auditor asks for restore test records and checks that restores reached a usable state, not only that a job reported success. Evidence includes restore logs, integrity verification output and the person who approved the test.	No restore test in the period; tests that verify only that files exist without checking application integrity.
Offsite and alternate processing	Auditor confirms that offsite copies and alternate processing arrangements are documented, in scope and actually replicated or available. Evidence includes replication logs, storage location records and the description of the alternate site or region.	Offsite copies or a second cloud region not covered by the documented scope; replication silently paused for months.
Type 1 design versus Type 2 operation	A Type 1 report checks that the environmental protections, backup processes and recovery infrastructure are suitably designed as of a date. A Type 2 report adds testing of whether they operated effectively across the observation period, so the auditor samples evidence from the whole period.	Type 1 readiness covered only by documents; Type 2 failing because operating evidence is scattered across tools with no single record.

How self-hosted open-source tools produce A1.2 evidence

A1.2 asks for backup processes, recovery infrastructure and environmental protections to be designed, operated and monitored. The four tools below cover different parts of that chain: the backup jobs themselves, the verification of stored data, and the alerting and metrics history that show how the environment is watched. Each one produces records an auditor can sample, but none of them makes the control operate on its own.

Bareos backup scheduling and catalog

The Bareos Director schedules and supervises backup, restore, verify and archive jobs, and keeps a SQL catalog of backed-up files. The job records and catalog entries show which data was backed up, when, and to where, which is the core evidence for determining data that requires backup and performing backups. Check the license terms before deployment: Bareos is licensed under AGPL-3.0-only, so confirm with counsel how those obligations apply if you modify or distribute the software.

Restic integrity checks

The restic check command verifies the structural consistency of snapshots, trees and pack files. Adding --read-data or --read-data-subset reads pack files back to confirm that stored backup data is unmodified. Keep the verification output with your restore test records, because an auditor will ask whether backups were tested and not only created. restic is licensed under BSD-2-Clause, which is generally permissive, but confirm the terms for the version you deploy.

Grafana alerting on backup and environment signals

Grafana Alerting builds alert rules from queries and expressions across multiple data sources, and it alerts on metrics and logs together. Teams can create, manage and act on alerts from one view. This supports the alert and response evidence that A1.2 expects for environmental threat events, such as a failed backup job or a rising temperature reading. Grafana is licensed under AGPL-3.0-only, so confirm that AGPL obligations fit how you run and expose it internally.

Prometheus metric history

Prometheus collects metrics from instrumented jobs over HTTP using a pull model, stores them as time series on autonomous local storage, and queries them with PromQL. The retained series give a history of backup job outcomes, storage capacity and environmental readings that you can show an auditor for a period, not just a single day. Confirm how long your local retention is configured to keep data, and plan where longer history is archived, since local storage limits how far back the record reaches. Prometheus is licensed under Apache-2.0.

What meeting A1.2 costs in money and effort

This table separates the cost components of meeting A1.2 by who is paid, whether the cost is one-time or recurring, and what moves it up or down. The open-source tools named on this page carry no license fee in the researched facts, so the money usually goes to storage, hosting, staff time and outside review. Ask every provider for a written quote tied to a fixed scope before comparing figures.

Cost component	One-time or recurring	What drives it and how to keep it down
Tooling or licenses	Recurring (hosting and support)	Bareos, restic, Prometheus and Grafana carry no license fee in the researched facts, but the servers, storage and any paid support contract do. Confirm current license terms with each vendor.
Engineering time to design and configure backups and alerting	One-time build, then recurring upkeep	Driven by the number of systems, data classes and alert rules. Keep it down by standardizing backup policies and reusing alert templates across systems.
Offsite or alternate-site storage and bandwidth	Recurring	Driven by data volume, retention periods, change rate and the distance to the alternate site. Ask for storage and transfer estimates based on your actual retention schedule.
Evidence upkeep (log exports, reviews, restore tests)	Recurring	Driven by how often restores are tested and how many backup jobs need review. Automate job reports and schedule restore tests so evidence is produced as a byproduct of operations.
External review of the design before the audit	One-time, sometimes repeated after major changes	Priced by the review scope and the reviewer's time. Limit it to the backup and alerting design and agree the deliverable in writing before work starts.
Auditor testing and sampling	Recurring with each examination period	Set by the CPA firm through its engagement letter, including the sample sizes and the observation period. Ask the firm to state how it samples backup and restore evidence before you sign.

Who does what for A1.2: your team, a partner and the auditor

Your organization owns A1.2. The criterion asks the organization to authorize, design or acquire, implement, operate, approve, maintain and monitor its environmental protections, software, backup processes and recovery infrastructure, and no outside party can make those decisions on your behalf. Your team sets the risk picture and accepts the residual risk, so it must be able to explain why each backup exists and why it is kept for the period it is kept.

Environmental threat assessment: Your team identifies the environmental threats that apply to the facilities and cloud regions that host the system, such as power loss, fire, flooding and regional outages, and records the decisions taken about each.
Backup scope and retention: Your team decides which data requires backup, how often it is backed up, how long copies are kept and when they are disposed of. These decisions tie to your commitments to customers and to your data classification.
Offsite and alternate site decisions: Your team chooses where copies are stored and what alternate processing infrastructure is available, and signs off on the recovery design.
Restore testing sign-off: Your team reviews restore test results, decides whether a failed restore is acceptable or triggers remediation, and owns the record of that decision.
Operating routine: Your team runs the recurring review of backup job reports, alert responses and exceptions, and keeps the evidence of that review current.

Before the audit, confirm that named individuals own each decision and can show the records behind them.

Where A1.2 programs usually fall short and how to close each gap

A1.2 programs tend to fail in the gaps between designing a control and proving it works over time. The cards below name six common weaknesses, each paired with the evidence an auditor would expect to see for the observation period.

Backups configured but never restored

Many teams can show a backup job that reports success but cannot show a restore. A1.2 expects backup processes that are performed and maintained, and an assessor will ask whether recovered data is usable. Check that restores are run on a schedule, that a sample of files is compared with the source, and that each test is recorded with the date, the operator and the result. Restic's check command with the read-data option can confirm that stored pack files are unmodified, which supports this evidence.

Environmental threats listed once

A threat register that was written at implementation and never revisited does not show that the organization is identifying environmental threats. Flooding, fire, power loss, cooling failure and regional outages change as sites, providers and facilities change. Review the list on a set cadence and after any move, new data center or significant change, and record what was added, removed or re-rated. Link each threat to the detection measure and protection mechanism that addresses it.

Alerts routed to an unread inbox

Monitoring that emails a shared mailbox nobody watches produces no response, and an assessor will look for the response. Route backup failures, storage capacity warnings and environmental sensor alerts into a channel or on-call tool with a named owner. Grafana Alerting can build rules from metrics and logs together, and Prometheus can supply the underlying metrics. Confirm that each alert has a documented escalation path and that alert history is retained for review.

Offsite copies outside documented scope

Backups copied to a second region, a vendor account or removable media often sit outside the system description and the asset inventory. An assessor comparing the description with the storage locations will find the gap. Record every offsite target, its location, encryption and access controls, and the replication schedule. Confirm that the alternate processing infrastructure named in the plan matches what the description says, and that any third-party storage provider is covered by vendor review.

Backup failures closed without a ticket

A backup job that fails overnight and is quietly rerun the next morning leaves no trail of what was wrong or whether the data was protected in the gap. Each failure should open a ticket that records the cause, the data affected, the corrective action and the time the backup was confirmed complete. Bareos keeps a catalog of jobs and their status, which can serve as the source list when reconciling failures against tickets. Sample failed jobs across the period and confirm each one has a closed ticket.

Evidence gathered at audit time

Teams often rebuild backup and environmental evidence in the weeks before fieldwork, which invites exceptions because the auditor needs proof across the whole period. Collect job logs, restore test records, alert histories, threat register revisions and offsite replication reports on a fixed schedule throughout the observation period. Store them in a location with access controls and a retention rule. Ask the auditor early which samples they plan to draw so that the records can be retrieved quickly.

What buyers ask about A1.2 cost, effort and outside help

How much effort does A1.2 take compared with the rest of SOC 2?

A1.2 is usually one of the more operationally heavy availability criteria because it spans physical threats, software, backups and recovery infrastructure, but its effort depends on how much of that already exists. The work is concentrated in a few areas: deciding which data needs backup, running and watching backup jobs, storing copies offsite, and maintaining an alternate processing site. Organizations that already run automated backups with alerting need mostly documentation and evidence. Organizations with manual or undocumented backups need design and build work first. Ask any provider for a written scope that lists each environmental threat, backup set and storage location covered, because that list drives most of the effort.

Can we meet A1.2 ourselves with open-source tools?

Yes, in many cases, provided someone in the organization owns the design, the operation and the evidence. Tools such as Bareos for scheduled backup and restore jobs, restic for repository integrity checks, and Prometheus and Grafana for metrics and alerting can cover much of the technical work on self-hosted infrastructure. The tools do not decide what your organization must protect, set recovery expectations, or prove that controls operated over time. Those decisions and records remain the organization's responsibility. Confirm each tool's capabilities against its current documentation before you commit to a design.

How long does it take to be ready for a Type 1 or Type 2 report?

Readiness depends on the starting point, not on a fixed duration. A Type 1 report covers the design of controls as of a date, so it requires working environmental protections, backup processes and offsite storage in place at that date. A Type 2 report adds an opinion on operating effectiveness over an observation period, so the backup and alerting processes must run consistently across that period with records to show it. Ask your auditor for the observation window and sampling approach in writing, and ask any implementation partner for a timeline tied to a fixed scope rather than a generic estimate.

What does the work need from our engineers and operations staff?

The work needs named owners on three sides: infrastructure engineers who configure backup jobs, storage and monitoring; operations staff who respond to backup failures and environmental alerts; and a control owner who keeps the policy, the list of protected data and the evidence current. Expect time for initial design, a recurring share of time for monitoring and failure response, and periodic time for restore exercises and documentation reviews. Engineers also need access to the systems being backed up and the backup catalog, which should be governed through the access controls the organization already uses for production.

Does an implementation partner also satisfy the auditor?

No. An implementation partner prepares systems, controls and evidence, but only an independent CPA firm performing the SOC 2 examination can issue the report. The organization owns its controls and management's assertion, and the auditor tests them and forms an opinion. Some CPA firms also offer readiness or consulting work, but independence rules restrict what the same firm can do for an attestation client. Before you engage anyone, confirm in writing who performs which tasks, and check the auditor's independence position with the auditor directly.

Which parts of A1.2 are worth outsourcing?

Outsourcing is most useful where specialized design work is needed once and where internal staff lack time or experience. Common candidates include the initial design of backup architecture and offsite or alternate-site arrangements, the implementation of backup and monitoring tooling on self-hosted infrastructure, and an independent review of the evidence before the auditor arrives. Work that should stay internal includes approving the data classification that drives backup scope, responding to real alerts, and signing off on the recovery approach. A fixed-scope engagement with written deliverables makes it easier to see which parts you are paying for.

Do we need a restore test for every backup set?

The criterion asks you to monitor the backup processes you run and to have the infrastructure to recover, so the answer depends on how you designed your backup and recovery program and what your auditor expects to test. Practically, you should test restores often enough to show that backups can be recovered and that the data is complete, and you should be able to explain how you chose the sets to test. Restic's check command with the read-data option can confirm that stored pack files are unmodified, which supports integrity evidence but does not replace a restore exercise. Agree the sampling and restore frequency with your auditor before the observation period begins.

How DeployOpen scopes and prepares A1.2 evidence

DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure. For A1.2, that means building the environmental monitoring, backup and recovery components the organization owns, then preparing the records an independent auditor will test.

How we scope

The written scope lists which systems, data stores and environments fall under A1.2 backup and recovery controls.
Scope records the environmental threats the organization has identified for each facility or cloud region in use.
Scope names which backup jobs, retention periods and offsite or alternate processing arrangements are in and out of work.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure backup scheduling, catalogs and restore workflows with open-source tools such as Bareos and restic.
We set up monitoring and alert rules in Prometheus and Grafana for backup failures, storage thresholds and environmental signals.
We document how each backup set is selected, encrypted, stored offsite and verified against the organization's stated objectives.
We run restore and integrity checks so the organization can show that backup data can be read back and is unmodified.

How we hand over

Handover includes configuration files, runbooks and the alert routing the organization's operators will maintain.
We deliver evidence packs: job logs, verification output, alert history and restore test records, mapped to A1.2 points of focus.
The organization approves the control design and owns its controls, and we confirm the staff who will run them can operate them.
Only the independent auditor issues a SOC 2 report, so we prepare the evidence and walk the auditor through it on request.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover periodic restore tests and review of backup job failures between audit periods.
Confirm with us in the quote how changes to storage, cloud accounts or retention rules will be logged as evidence.