Backup and recovery: SOX ITGC requirements and evidence

Backup and recovery for SOX ITGC: what auditors test and why

When a finance system holds data that feeds ICFR, the auditor's question is not whether backups run. It is whether the organization could restore that data completely and accurately if it were lost or corrupted. A successful backup job log is weak evidence on its own. Auditors look for three things: that the backup set is complete for the financially significant data, that the copies are protected from unauthorized change or deletion, and that restoration has been tested and produced usable results. Management owns this control, even when a provider runs the infrastructure.

The risk is spelled out in the PCAOB's risk standards. AS 2110 lists potential loss of data or inability to access data as an IT risk to internal control over financial reporting, so the auditor will ask how that risk is addressed for each system whose output feeds a reporting control. Two gaps cause most findings. The first is restore testing that is planned but skipped, so no one has seen a restore of a ledger, subledger or reconciliation extract succeed. The second is ownership: backups of financial data often sit under an infrastructure team's job list with no named business owner who defines what must be recoverable and how fast. Ask each system owner to confirm in writing which datasets are in scope, who approves the retention period, and who signs off on each restore test.

A practical starting point is to compare the backup catalog with the list of in-scope financial systems and confirm that every dataset is covered. Confirm with your backup tooling vendor which features support the evidence you need, such as catalog records of what was backed up and the ability to restore a file from a chosen point in time. For repositories, confirm whether the tool can verify data integrity by reading pack files back, not only checking metadata. Then schedule restore tests on a defined cadence, record who ran them, what was restored, and whether the restored data reconciled to the source. Your auditor will likely request those records for the period under review.

Which systems, data and providers fall inside backup and recovery scope

Backup and recovery scope starts with a simple test: which systems and data could change a financial statement if they were lost or could not be restored. The cards below cover the decisions that expand or shrink that scope, from financial applications and reporting files to copies held by providers and archives.

Financially significant applications and databases

Start from the applications and databases that hold the general ledger, subledgers, and the transactions that feed them. Each one that supports a key control needs a documented backup schedule, a retention period, and a named owner. Check that the backup job covers the database itself, not only the application server, because a restore that brings back the application without its data does not support the reporting process. Confirm the list against the ICFR scoping documentation so that the two stay consistent.

Reporting files and end-user spreadsheets

Reports, extracts and spreadsheets that management uses to prepare or review financial figures often sit outside the core systems. If a lost file would prevent a control from operating or would change a reported number, it belongs in scope. Ask where these files are stored, who can overwrite them, and whether shared drives or collaboration tools are backed up on a schedule that matches the reporting calendar.

Data that only affects operational efficiency

SEC guidance says management needs to evaluate only the IT general controls necessary for other controls over financial reporting to operate properly and consistently. Systems whose loss would slow operations but leave reported figures intact can usually stay outside the backup control, though they still need recovery planning for business continuity. Document the reasoning for each exclusion so that an auditor can see why the system was left out.

Backup copies held by cloud and managed providers

When a SaaS platform, cloud database or managed hosting provider keeps the only copy of financial data, management still needs to know what is backed up, how often, and how restores are requested and approved. Obtain the provider's description of its backup controls, including its SOC 1 report where one exists, and map the controls that your organization must perform, such as reviewing restore logs or confirming retention settings. Do not assume that the provider's backup covers your recovery objectives until the contract or report says so.

Offsite and archive copies

Offsite copies protect against the loss of a data center, and archive copies preserve closed fiscal periods for later reference. Both need the same restricted access as primary backups, because a copy that anyone can open or overwrite does not protect the data. Confirm where each copy is stored, who holds the encryption keys and repository credentials, and how long archives are kept relative to the record retention rules that apply to your company.

How an assessor tests backup and recovery controls

This table compares what an assessor does, what evidence they request and where exceptions usually appear for each part of backup and recovery. Read each row as a control element the organization must be able to show working over the period under review. The main takeaway is that a backup job log alone rarely satisfies an assessor; restore results and access records usually decide the outcome.

Element	Test approach and sample	Evidence requested	Common findings
Backup schedule and completion	Obtain the schedule for each financially significant system and select sample dates across the period. Compare each sampled date to job logs to confirm the backup ran and completed.	Schedule configuration, job run logs or catalog entries for sampled dates, and the list of in-scope systems.	Systems missing from the schedule, jobs reported as completed with warnings that were never reviewed, and gaps on weekends or month end.
Monitoring and failure follow-up	Trace a sample of failed or partial backup jobs to the alert, ticket and rerun that followed. Confirm the alert reached a person who could act on it.	Alert rules, notification history, incident or ticket records and evidence of successful reruns.	Alerts that fire but have no owner, failures closed without a rerun, and monitoring that does not cover every in-scope system.
Access to backup repositories and catalogs	Obtain the list of users and service accounts with rights to the backup server, catalog and storage. Compare it to the access review and test a sample of changes.	User and role listings, access approval records, periodic access review sign-offs and privileged activity logs.	Former employees or shared administrator accounts still holding restore or delete rights, and backup deletion permitted to the same people who run production.
Restore testing and results	Select a sample of restore tests in the period. Confirm the restored data was checked against the source, and that results were reviewed and any failures resolved.	Test plans, restore job records, reconciliation or checksum results and sign-off by the data owner.	No restore test for a system during the period, tests that restored a sample file rather than the financial data set, and failed tests without follow-up.
Backup integrity verification	Ask how the organization confirms stored backup data has not been altered or corrupted. Test a sample of verification runs against the stated frequency.	Verification job configuration and logs, and documented results of integrity checks on sampled repositories.	Integrity checks described in procedures but never run, and verification that only confirms metadata rather than the stored data.
Retention and recovery objectives	Compare documented retention periods and recovery targets to the organization's records retention and continuity requirements, then confirm the configuration matches.	Retention policy, backup configuration showing retention settings and approval of recovery objectives by management.	Retention settings that differ from the approved policy, and recovery objectives that were never approved or reviewed.

Implementing backup and recovery controls in sequence

This sequence moves from knowing which financial data matters to proving that it can be restored. Each step produces a record that an auditor can test, so the controls operate as designed before year end and continue to operate during the fiscal year.

Inventory financially significant data and owners
Start from the in-scope applications, databases and reports identified in your SOX ITGC scoping work, and list the data stores that feed them, including interfaces, file shares and reporting databases. Record a named business owner and an IT custodian for each store. Done means the inventory is approved by the owners and reconciled to the scoping documentation, so an auditor can see that no financially significant store was left out of backup coverage.
Define recovery objectives with business owners
Work with each business owner to document how much data loss and how much downtime the financial process can tolerate, and which systems must be restored first if several fail at once. The business owner signs these objectives, because they decide the required backup frequency and retention. The output is a signed recovery requirements record that later restore tests can be measured against.
Configure scheduled backups and retention
Configure backup jobs for each inventoried store at the frequency and retention set in the recovery requirements. Where you use Bareos, the Director schedules and supervises backup, restore, verify and archive jobs and keeps a catalog of backed-up files. Where you use restic, snapshots are created by the backup command. Record the job definitions and retention rules in configuration under change control, so the output is an exported schedule that matches the signed requirements.
Restrict who can change backup schedules
Limit the ability to create, modify, disable or delete backup jobs and retention rules to a small set of named administrators, separate from the people who run financial applications where practical. Changes to schedules should flow through the same change process used for other production configuration. The output is an access list for the backup platform and a sample of change tickets showing approval before any schedule change.
Restrict access to backup copies and restore rights
Apply access controls to backup repositories, catalogs and encryption keys so that only authorized staff can read, copy, restore or delete backup data. Restore rights should be separate from the ability to alter backup jobs, and restores of financial data should be authorized by the data owner. The output is a documented access matrix and the repository permission settings, which the auditor will compare against the list of people with administrative or restore access.
Monitor job results and resolve failures
Review job status for every scheduled backup and verification run, and alert the responsible team when a job fails, is skipped or runs beyond its window. Grafana Alerting can build alert rules from queries across multiple data sources, and Prometheus can collect metrics from instrumented jobs, though you should confirm which metrics your backup tool exposes. Each failure should create a ticket that records cause, fix and rerun. The output is a job report log and the ticket trail for exceptions.
Run and document restore tests
Restore selected financial data to an isolated environment on a defined schedule, and compare the results with the source, using record counts, control totals or reconciliation to reports. Integrity checks such as restic check with --read-data or --read-data-subset can confirm that stored pack files are unmodified. Record who ran each test, the data restored, the result and any defects, with the restore date. The output is a signed test report per test that the auditor can sample across the fiscal year.

What a restore test must prove to satisfy the auditor

A successful backup job does not prove that the data can be recovered. A job that reports success shows only that the job ran and wrote something to the backup target. It says nothing about whether the files are complete, readable by the application that owns them, or consistent with the general ledger, subledgers and interfaces that depend on them. Auditors reviewing backup controls for financially significant systems look for a restore test with a defined scope, a named data set, a recorded timestamp of the backup restored, and a comparison of the restored result to the source. Without those four elements, a test log showing that a restore completed cannot be tied to a specific financial data set or period, and the auditor cannot conclude that the control operated.

Checking stored data for integrity and restoring it to a working state answer different questions. Integrity verification confirms that the backup repository has not been corrupted and that the stored data still matches what was written. For example, 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. Bareos's Director can schedule verify jobs and restore files from the current backup or from one taken before a given date and time. Integrity checks show the backup is intact; only a restore into a working environment, followed by reconciliation of balances or record counts against the source, shows the financial system can be recovered. Keep both in the control design and record which one each test evidences.

Before the year begins, confirm with your external auditor how many restore tests they expect and which data sets they consider in scope, since this depends on your risk assessment and system landscape. Document the restore test plan, the person who approved it, the reconciliation method and the disposition of any mismatch. A mismatch is a finding to investigate, not a reason to delete the test record. Ask whether the auditor will accept evidence generated by your monitoring tools, such as alert history from Grafana Alerting for failed backup jobs, alongside the restore records themselves.

Evidence that passes a backup and recovery audit

An auditor testing backup and recovery wants proof that the backups existed, ran as designed, could be restored, and were protected from change. The six artifacts below connect those questions, and each one is only useful if it is refreshed through the year rather than assembled before fieldwork.

Backup policy and retention settings

The written policy states which financial systems and data sets are backed up, how often, and how long copies are kept. Pair it with the actual configuration exported from the backup platform, such as the retention rules and job definitions in the Bareos Director, so the auditor can see that the policy and the running system agree. Between audits, review the policy annually and export the configuration after every approved change, then compare the two for drift.

Job schedules and change history

Schedules for backup, verify and archive jobs are part of the control environment, so anyone who can alter them must be authorized. Keep a dated record of each schedule change with the requester, approver and reason, and link it to the change ticket. Check quarterly that the change log matches the live schedule, because a schedule edited outside the change process is a common finding.

Job success and failure logs with follow-up

Auditors sample daily job results and expect each failure to have a visible resolution. Retain the job logs, alerts raised for failed or missed runs, and the tickets showing root cause and rerun. Grafana Alerting can route failed-job alerts into a single view, so reviewers can show that each alert was acted on. Sample a set of failures monthly and confirm each has a closed ticket with a dated rerun.

Access lists for backup systems and catalogs

Backup repositories and catalogs hold copies of the same financial data as production, so access to them is in scope for the access controls too. Maintain a current list of administrators and operators for the backup server, storage repositories and catalog database, with the business reason for each entry. Review it at least quarterly and remove leavers and role changes promptly. Confirm that backup administrators cannot also approve their own restore requests.

Restore test records with outcomes

Auditors look for evidence that backups can be recovered, not only that they were written. Record each restore test with the system restored, the date, the restore point used, who performed it, the comparison performed against source data, and the result. Integrity checks such as restic check with --read-data or --read-data-subset can provide supporting evidence that stored pack files are unmodified. Schedule tests across the year so every in-scope system is restored at least once, and log failed tests as findings with remediation dates.

Recovery objective sign-off by the data owner

The recovery point and recovery time targets for each financial system should be agreed and signed by the data owner, not by IT alone. Record the targets, the reasoning behind them, and the date of sign-off, and check that the backup schedule and restore tests actually meet them. Revisit the sign-off when systems change or when a restore test shows a target cannot be met, so the signed record always reflects current operations.

What meeting backup and recovery controls costs in money and effort

This table lists the cost components of backup and recovery controls for SOX ITGC, who is paid for each one, whether it is one-time or recurring, and what pushes it up or down. Use it to build a like-for-like quote request and to see where the recurring spend sits. No prices are shown because none were supplied; ask each provider for the figures in writing.

Cost component	Who is paid or who bears it	One-time or recurring, and what drives it	What to ask for in a quote
Backup tooling or licenses	Software vendor or open-source support provider, plus the company's own platform team	Open-source tools such as Bareos or restic carry no license fee but need hosting and support; commercial licenses often scale with systems or data volume. Recurring if subscribed.	Confirm license model, support tier, and whether pricing scales with protected systems, data volume or retention
Engineering time to configure and monitor	Internal platform engineers or an implementation partner under a fixed-scope agreement	Mostly one-time for initial setup of jobs, catalogs and alerting; recurring for job changes, onboarding new financial systems and alert tuning. Driven by number of systems in scope.	Itemized effort by system, the deliverables list, and what is handed over for internal operation
Storage for backups and archives	Cloud provider, data center operator or storage vendor	Recurring. Driven by data volume, change rate, deduplication and retention length, including offsite or immutable copies.	Storage tier and price per unit, retention schedule, egress charges for restores, and how growth is billed
Restore test effort	Internal operations staff, application owners and any partner running the tests	Recurring at the chosen test frequency. Costs rise with the number of financial systems, database size and how many restores must be documented.	Restore test plan, frequency, sample scope, and who signs the test record
Evidence upkeep	Internal control owners, sometimes supported by the partner	Recurring. Job logs, catalog reports, alert history and restore records must be retained and indexed for each audit period.	Evidence list by control, retention period, and where the records are stored and reviewed
Monitoring and alerting	Internal operations team or managed monitoring provider	Setup is one-time; alert review and on-call response are recurring. Driven by job count and the number of alert channels.	Alert coverage for failed, late and unverified backup jobs, and the response time agreed with the business
External testing or review	Independent assessor, internal audit or a consultant	Periodic. Scope depends on how many restore scenarios and systems are reviewed, and whether the review is advisory or attestation.	Defined scope, sampling approach, and confirmation that the reviewer does not issue the SOX opinion
Auditor sampling time	External auditor, paid by the company under its audit engagement	Recurring each audit cycle. Driven by the number of backup and restore samples the auditor selects and how well evidence is organized.	Ask the auditor which backup and restore populations they will sample and what evidence they expect

Self-hosted open-source tools that produce backup evidence

Backup and recovery evidence comes from three things: a job scheduler that proves backups ran, a repository check that proves stored data is intact, and monitoring that proves failures were seen and handled. The four tools below cover those functions, but each one produces only part of the evidence auditors ask for, so confirm the fit against your own retention, access and restore requirements before relying on them.

Bareos job scheduling and catalog

The Bareos Director schedules and supervises backup, restore, verify and archive jobs, and keeps a SQL catalog of the files it has backed up. For SOX purposes, the job history and catalog are the records that show which financial systems were backed up, when, and to where. Restores can target the current backup or one taken before a given date and time, which lets you test recovery to a specific point. Confirm the catalog retention and job log settings in your environment, and confirm with counsel that the AGPL-3.0-only license terms work for your deployment.

restic integrity checks

The restic check command verifies the structural consistency of snapshots, trees and pack files. With the read-data options, it reads pack files back to confirm the stored backup data is unmodified. This supports the evidence that a backup can be relied on at restore time, not only that a job completed. Read-data checks take longer and use more I/O on large repositories, so decide how often to run them and record the results as evidence of the verification schedule.

Grafana Alerting on backup failures

Grafana Alerting builds alert rules from queries and expressions across multiple data sources, so backup job failures and missing backup runs can be alerted alongside other operational metrics and logs. Teams can create, manage and act on these alerts from one view, which helps show that failures were detected and assigned. Define who receives each alert, how acknowledgment is recorded, and how alert history is retained. Confirm the AGPL-3.0-only license terms with counsel before deployment.

Prometheus metric retention

Prometheus collects metrics from instrumented jobs over HTTP using a pull model, and stores them as time series on local storage. Backup job duration, success counts and last-success timestamps can be recorded this way and queried with PromQL to show a continuous operating history. Local storage is autonomous, so confirm how long metrics are kept, whether they are copied off the host, and how the retention period matches the evidence window your auditor will sample.

Who owns backup and recovery, who the partner supports, and what the auditor does

Management owns the backup and recovery controls over financially significant systems and data. Under SEC guidance on management's ICFR evaluation, the company decides which systems matter to financial reporting, documents how those controls operate, and evaluates whether they work. A partner can build the mechanics, but the company is the party that answers for them. Finance and application owners need to state how much data loss the business can tolerate for each ledger, subledger and reporting database, because that decision drives retention and restore design.

Data owners and scope: Name the owner of each financial system and dataset, and confirm which backups fall inside SOX scope.
Retention decisions: Approve retention periods and archive rules, and record why they meet financial record-keeping needs.
Restore approvals: Define who may request a restore, who approves it and how restores into production are logged and reviewed.
Restricted access: Decide who holds backup administration, encryption keys and catalog rights, and review those accounts periodically.
Sign-off on restore tests: Management reviews restore test results, records exceptions and tracks remediation to closure.

Confirm with your internal audit or SOX program lead which evidence they expect management to retain for each of these decisions before tooling is configured.

Where backup and recovery controls usually fail the audit

Auditors test backup and recovery as part of computer operations because data loss or an inability to access data is a recognized IT risk to financial reporting. The gaps below tend to appear together: backups run, but nobody checks them, restores are assumed to work, and the people and retention settings around the data were never designed against recovery needs.

Backup failures go unreviewed

Backup jobs report success or failure, but nobody is assigned to review that output on a set cadence. An auditor will ask for records showing that failed or partial jobs were identified, investigated and rerun. Start by naming the owner of the daily backup review, set up alerts for failed jobs that reach a person, and keep a log of each failure with its resolution. Bareos keeps job status in its Director, and Grafana Alerting can route failure signals from your metrics and logs to the responsible team.

Restores never tested or unrecorded

A backup is only evidence of recovery if a restore has been performed and the result written down. Schedule restore tests for financially significant systems and data sets, record who ran each test, what was restored, the time taken and whether the restored data matched expectations. Where you use restic, run restic check with --read-data-subset on a rotating basis so that stored pack files are read back and confirmed unmodified, and keep the output with the test record.

Excess access to backup data

Backup administrators often hold rights to read, restore and delete every system, which means they can extract or alter financial data outside the application controls. Limit backup console roles to the duties each person needs, separate the ability to change retention or delete backups from the ability to run jobs, and require a second approver for restores to a different location. Review these assignments on the same cycle as application access reviews and keep the approvals.

Retention not matched to recovery needs

Retention periods are often left at defaults chosen for storage cost rather than set from the recovery point and recovery time objectives the business has agreed for each financial system. Document those objectives per system, then configure retention and archive rules so that a backup from each required point in time still exists. Confirm with your backup platform how pruning and expiry work, and test that a restore from the oldest retained point succeeds.

Provider-hosted backups without evidence

When financial systems run in cloud, SaaS or managed hosting, the provider may run backups that your team cannot see. Auditors then ask how you know backups exist, where they are stored and whether they were restored successfully. Obtain the provider's description of backup and restore controls, confirm which of those controls are your responsibility, and request restore test results or a SOC 1 report that covers the period. Record any gap in coverage and your compensating step for it.

Backup and recovery questions buyers ask before hiring help

How much effort does a SOX backup and recovery control take to run?

Most of the effort is recurring, not the initial setup. Backup jobs need to run on schedule, failures need to be detected and resolved, and restore tests need to happen at a frequency management defines and can evidence. The initial build covers defining which financial systems and data are in scope, configuring backup jobs and catalogs, restricting access to backup storage, and documenting the procedure. Effort rises with the number of in-scope systems, the number of storage locations and the complexity of recovery sequences across applications and databases. Ask any provider to break the scope into one-time build work and recurring operating work, and to state who performs each task.

Can our team implement SOX backup controls without an outside partner?

Often yes, if the team already runs backups and has engineers who can document and test them. The harder part is evidence: auditors need a clear design, consistent operation over the audit period and proof that restores worked. Teams that have not previously been through an ITGC audit commonly underestimate how much documentation and sample-ready evidence the work requires. A partner can help prepare systems and evidence, but the organization owns the control and must be able to explain it. Independent auditors, not implementation partners, issue the audit conclusions. Decide internally whether you have the capacity to operate the control every period, not only to build it.

How long does it take to implement backup and recovery controls for SOX?

Timing depends on the current state of your backups, not on a fixed duration. The main drivers are how many financial systems and databases are in scope, whether backup tooling already exists, how mature the restore process is, and how many teams must approve access and retention decisions. Controls also need to operate for a period before an auditor can test them, so implementation should finish well before the audit period starts. Ask for a written schedule with milestones for scope confirmation, build, first restore test and handover, and confirm which dependencies sit with your change and access teams.

What do finance and IT teams need to provide for backup and recovery work?

Finance defines which reports, ledgers and data sets are significant to financial reporting and how far back their history must be recoverable. IT provides system inventories, current backup configurations, storage locations, retention settings, access lists for backup administrators and the recovery runbooks for each in-scope system. Both teams should agree on recovery priorities and who signs off restore test results. Gaps in these inputs are the most common cause of delayed work, so ask the provider to list every input it needs, the owner of each input and the date it is required.

What should a backup and recovery implementation partner deliver in writing?

A written scope should name the in-scope systems and data, the backup and restore tooling covered, and the control design the organization will operate. It should list deliverables such as the backup and restore procedure, access restriction design for backup storage, job monitoring and alerting configuration, restore test scripts and results templates, and an evidence index that maps each artifact to the control it supports. The document should also state what the partner will not do, such as issuing audit conclusions, and who is responsible for operating each control after handover. DeployOpen works from fixed-scope written agreements, and quotes follow from that scope.

How does restore testing affect the SOX audit?

Restore testing is usually where auditors look for proof that backups are actually recoverable. A successful backup job log is not enough on its own. Auditors generally expect a documented restore of a sample of financial data, performed on a schedule management defines, with results compared against expected outcomes and any failures tracked to resolution. Open-source tools can help produce this evidence. For example, Bareos keeps a SQL catalog of backed-up files and can restore files from the current backup or from one before a given date and time, and restic's check command with --read-data or --read-data-subset reads pack files back to confirm stored data is unmodified. Keep the test records, not just the tool output, as the evidence.

How do we monitor backup failures so they are caught before an audit?

Failed or missed backups should generate alerts that someone reviews and resolves, with the resolution recorded. Prometheus collects metrics from instrumented jobs through a pull model over HTTP and stores them as time series, and Grafana Alerting can build alert rules from queries across multiple data sources, covering metrics and logs together. Configure alerts for missed schedules, job errors, verification failures and storage capacity, and route them to a named queue. Confirm with your own environment which backup jobs can export metrics, since not every tool exposes them directly. Auditors will want to see that alerts were reviewed, so the ticket trail matters as much as the alert rule.

How DeployOpen works on this

DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so backup and recovery evidence is produced from your environment. We prepare the systems, restore tests and records; your management owns the controls and an independent auditor decides what the evidence supports.

How we scope

Agree in writing which financial systems, databases and data stores fall under the backup and recovery scope.
Record retention periods, backup frequency and restore objectives that management has approved for each in-scope system.
Confirm which backup jobs, storage locations and administrator roles the written scope covers, and which sit with a provider.

How we build

Configure Bareos to schedule backup, restore, verify and archive jobs with a catalog of backed-up files.
Set restricted access to backup servers, repositories and encryption keys so only authorized operators can restore data.
Configure restic repositories and scheduled check runs, including read-data verification of pack files on a defined cadence.

How we hand over

Deliver job schedules, access configurations and monitoring rules as documented, version-controlled configuration.
Provide restore test records showing the systems restored, the point in time used, and who reviewed the results.
Hand over runbooks for failed jobs and failed restores, with alert routing to Grafana and metrics collected in Prometheus.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Schedule recurring restore tests and backup integrity checks so evidence covers the whole audit period, not only one date.
Confirm with your auditor which evidence formats and sample periods they expect before the first test cycle begins.