Backup audit evidence is what turns a claim that backups work into something an auditor can accept. Saying that backups run nightly and restores are tested is a statement. An auditor needs records that show it: reports with dates, configurations as they are set, test results with outcomes. Teams with sound backup practice sometimes do poorly in audits because the practice was never written down, and collecting proof after the request arrives takes weeks.
This post lists what auditors commonly ask for in relation to backups, where each item comes from and how to collect it as a by-product of normal operations.
What an auditor is trying to establish
Whatever the framework, whether it is ISO 27001, SOC 2, a sector regulation or a cyber insurance questionnaire, backup controls are assessed against the same few questions. Is there a defined policy? Is everything that should be backed up actually covered? Do the backups complete? Are they protected from tampering? Can they be restored, and has that been demonstrated? Is access to them controlled? The auditor samples evidence for each and compares what is documented with what is configured.
Common requests and where the evidence comes from
| What is asked | Evidence that answers it | Source |
|---|---|---|
| Backup policy and scope | Approved policy with retention tiers and review date | Document management |
| Coverage of in-scope systems | Inventory matched against protected machines | Asset list and backup software report |
| Jobs complete as scheduled | Job history for a sample period, with failures and follow-up | Backup software reports, ticket system |
| Retention is applied | Job and repository settings, list of oldest restore points | Configuration export or screenshots |
| Copies are immutable or offline | Object Lock or immutability settings, retain-until dates on sample objects | Repository configuration and object metadata |
| Restores are tested | Test records with date, system, result and duration | Restore test log |
| Access is restricted | List of accounts and roles, MFA status, review record | Backup server and repository user management |
| Changes are controlled | Change records for policy and configuration changes | Change management, audit logs |
Coverage: the gap auditors find most often
The most frequent finding is a system that should be backed up and is not. New servers get deployed without being added to a job, or a job is scoped to a folder the server was later moved out of. The evidence that prevents this finding is a periodic reconciliation: the asset inventory on one side, the list of protected machines on the other and a record of how each difference was resolved. Monthly is a reasonable frequency. Backup scopes based on tags or containers reduce the manual effort, though they still need checking.
Proof that jobs ran, and what happened when they did not
A year of green job reports is less convincing than a year that includes failures with a visible response. Auditors expect some failures. What they look for is that each was noticed, logged and resolved within a reasonable time. Linking backup alerts to the ticket system creates that trail automatically. Backup success versus recovery success explains why job status alone says little about whether a system can be recovered.
Proof of immutability
For immutability, auditors increasingly want to see the control itself. A policy statement that backups are immutable is a start. Stronger evidence is the repository configuration showing Object Lock enabled with its mode and default period, plus the retention metadata of a few sample objects showing retain-until dates in the future. A record of a deletion attempt being refused during a test is stronger still. What Object Lock actually guarantees sets out what the control does and does not promise, which helps in describing it accurately.
Proof of restore
Restore testing is where evidence is thinnest in most organizations. Tests happen informally whenever a user needs a file back, and nothing is recorded. An auditor will ask for a schedule and results. A simple log is enough: date, system restored, restore point used, where it was restored to, whether the result was verified and how, how long it took and who performed it. The log should cover different kinds of systems over the year, including at least one from the most critical tier. How often to test recovery and what to measure gives a way to set the schedule.
Access and separation of duties
Auditors ask who can delete backups or change retention, and how that access is protected. The evidence is a current list of accounts with administrative rights on the backup server and the repository, confirmation that they use multi-factor authentication where available and a dated record that the list was reviewed. Separation matters as well: the people who administer production should not be the only control over the copies that protect it. Separating backup admin accounts covers how to structure that.
Making evidence a by-product
The teams that pass audits with little effort collect evidence continuously. Job reports are scheduled to a mailbox or folder and retained. Configuration is exported monthly. The restore log is updated the day a test is run. Access reviews are calendar entries with a saved output. When the audit request arrives, the answer is a folder that already exists.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. Immutability is provided by S3 Object Lock on each object, and the lock mode and retain-until date can be read from an object's metadata through the standard S3 API, which gives direct evidence that a restore point is protected. In compliance mode no account, including ARTESCA administrators, can remove a lock before it expires.
The repository has its own administrative accounts, separate from the backup server and the production directory. ARTESCA grows within the same deployment from roughly 50 TB to 8.5 PB and is used as a target for Veeam and other backup software.
Before the next audit
A useful exercise is to take the table above and, for each row, find the evidence as if it had been requested today. Rows that take more than a few minutes show where a recurring export or a simple log is missing. Closing those gaps takes a few hours once and saves much more at audit time.