📋 Compliance & Enterprise · CISSP Authored
SOC 2 Type II and Cloud Backup — What Auditors Actually Look For (And What Most Companies Get Wrong)
SOC 2 Type II is one of the most sought-after certifications for SaaS companies — and one of the most commonly failed audits when it comes to backup controls. This is a plain-language guide to what SOC 2 auditors specifically examine in your backup and recovery procedures, written by a CISSP who has been on both sides of the audit table.
SOC 2 Type II · Availability Criteria
4 backup controls auditors check — and the one most companies fail
Based on 12 years of audit preparation and execution. The gap between “we have backup” and “our backup satisfies SOC 2” is wider than most teams realise.
I’ve sat on both sides of the SOC 2 audit table — as the person preparing evidence packages and as a third-party auditor reviewing them. The most common issues: companies that fail their SOC 2 audit on backup controls almost never fail because they don’t have backup. They fail because they can’t prove their backup works consistently over time.
That difference — having backup versus proving backup works — is the entire difference between passing and failing the Availability Trust Service identification test. This article explains exactly what auditors look for, why most companies fail at restore testing documentation, and how to build a backup evidence package that meet a SOC 2 Type II engagement.
ℹ️ Important disclaimer
I work at Softyz, which offers SOC 2-compliant backup infrastructure. This article reflects my experience preparing for and conducting audits — not official AICPA guidance. The specific controls required in your SOC 2 engagement depend on your scope, your auditor’s methodology, and the Trust Service Criteria you’re being assessed against. Consult your auditor and legal counsel for guidance specific to your situation.
SOC 2 Type I vs. Type II — why Type II is what actually matters
SOC 2 comes in two flavours, and customers who require SOC 2 increasingly specify which one they want:
- SOC 2 Type I — evaluates whether your controls are designed appropriately at a single point in time. Think of it as a snapshot: “on this audit date, did you have the right controls in place?” Type I is relatively easy to prepare for and pass — you just need to have the controls correctly configured when the auditor looks.
- SOC 2 Type II — evaluates whether your controls operated effectively over a defined period (typically 6–12 months). This is the meaningful one. You must prove that your backup ran consistently, that you tested restores regularly, and that you monitored and responded to failures — throughout the entire audit period, not just the day of the audit.
This is why SOC 2 Type II is so much harder for backup: you can’t retroactively prove that your backup testing was consistent over the past 6 months if you didn’t document it at the time. The evidence package either exists or it doesn’t.
6–12
Months of evidence required for a SOC 2 Type II audit — not just your current backup status
#1
Most common backup audit failure: no documented restore testing logs over the audit period
Automatic
Softyz Enterprise generates audit-ready backup logs, restore records, and anomaly reports automatically
The SOC 2 Trust Service Criteria — where backup lives
SOC 2 Trust Service Criteria (TSC) — backup relevance map
Backup controls primarily live under the Availability criterion, but touch Security and Confidentiality too
Trust Service Criterion
What it covers
Backup relevance
Availability (A-series)
System availability for operation and use as committed. Includes backup, recovery, and business continuity controls. Primary home of all backup controls.
Critical
Security (CC-series)
Protection of information and systems against unauthorised access. Backup encryption, access controls for backup systems, and monitoring fall here.
High
Confidentiality (C-series)
Protection of confidential information. Backup encryption, secure transmission, and access controls for confidential data in backups.
Medium
Processing Integrity (PI-series)
Complete, valid, accurate, timely, and authorised processing. Backup integrity verification — confirming backed-up data matches the source.
Low–Medium
Privacy (P-series)
Collection, use, retention, and disposal of personal information. Backup retention periods, right-to-erasure processes for backup data.
Situational
The 4 backup controls SOC 2 auditors check in every engagement
Control 01 · Availability A1.2
Defined backup schedule consistently followed
The control most companies pass — but not always cleanly
Your backup must run on a defined, documented schedule throughout the audit period. The auditor will sample backup job logs from random dates within the audit window and verify that backups ran as scheduled. A missed backup without a documented incident response is a finding.
🔍 What auditors ask for
Backup job logs for a sample of dates across the audit period · Documented backup schedule policy · Evidence that failures triggered alerts and were resolved
⚠️ Common failure: Backup policy document exists but backup logs show 12 missed days across the audit period with no documented incident response for any of them.
Control 02 · Availability A1.2
Regular restore testing with documented results
The control most companies fail — this is the #1 SOC 2 backup finding
You must test that backups can actually be restored — not just that they ran. Tests must be performed regularly throughout the audit period (quarterly minimum, monthly preferred) and the results must be documented: what was tested, when, whether it succeeded, and what the restore time was.
🔍 What auditors ask for
Restore test logs for each quarter of the audit period · Documentation of what was restored, from what date, and confirmation it succeeded · Any failures and corrective actions taken
❌ Most common failure: “We know our backup works because it runs every night.” Auditors require documented evidence of actual restore tests — not confidence that the backup is working.
Control 03 · Common Criteria CC7.2
Backup monitoring with failure alerts
Monitoring the backup is not the same as running the backup
Your backup system must actively monitor whether backups complete successfully and alert the appropriate person when a backup fails or produces unexpected results. Auditors look for evidence that monitoring was active throughout the audit period and that alerts were acknowledged and acted upon.
🔍 What auditors ask for
Alert configuration screenshots · Example of a backup failure alert and the documented response · Evidence that monitoring was active throughout the audit period, not just at audit time
⚠️ Common failure: Alerts are configured but go to a shared inbox nobody monitors, or alerts are acknowledged without any corrective action documentation.
Control 04 · Common Criteria CC8.1
Change management for backup configurations
Every change to backup configuration must be logged and authorised
Any change to your backup configuration — adding folders, changing frequency, modifying retention, updating credentials — must go through a documented change management process: who requested the change, who approved it, what was changed, and when. Undocumented changes are a significant audit finding.
🔍 What auditors ask for
Change management tickets or logs for all backup configuration changes during the audit period · Evidence of approval by an authorised person · Before/after configuration documentation
⚠️ Common failure: Backup configuration was changed three times during the audit period, but no change management tickets exist. “We just updated it” is not sufficient.
The complete SOC 2 backup evidence package — what to prepare
| Evidence artifact | What it must contain | How far back | Softyz generates it? |
|---|---|---|---|
| Backup policy document | Schedule, retention periods, scope, responsible parties, RTO/RPO targets, review cadence | Current version + revision history | Template provided |
| Backup job logs | Timestamp, files backed up, size, success/failure status, duration for every backup run | Full audit period | ✔ Auto-generated |
| Restore test records | Date tested, what was restored, from which backup date, success/failure, time to restore, tester name | At least quarterly across audit period | ✔ Auto-generated |
| Monitoring alert configuration | Screenshot of alert rules, recipient list, threshold settings | Current + evidence active throughout | ✔ Export available |
| Alert response records | Each alert generated during the audit period + documented response and resolution | Full audit period | ✔ Auto-generated |
| Change management tickets | All backup configuration changes during the audit period with requester, approver, and description | Full audit period | Requires your ITSM tool |
| RTO / RPO documentation | Defined recovery time objective and recovery point objective, and evidence they’ve been met in restore tests | Current version + test validation | Template provided |
| Vendor compliance documentation | Your backup vendor’s own SOC 2 Type II report, security documentation, DPA | Current | ✔ Available from Softyz |
The 5 most common SOC 2 backup audit failures
01
No restore test records for the audit period
The single most common finding. The company has been running backups for years but has never documented a restore test. When the auditor asks for restore testing evidence from the past 9 months, nothing exists. This alone can result in a qualified opinion on the Availability criterion.
✅ Fix: Start documenting restore tests immediately. Softyz Enterprise generates restore verification records automatically when you use the Web Manager restore function — each restore creates a dated log showing what was restored, from what version, and whether it succeeded.
02
Backup policy exists but doesn’t match actual backup configuration
Policy says: “Daily backup of all production systems with 30-day retention.” Reality: three production databases aren’t in the backup scope, and retention is set to 14 days because someone changed it to reduce storage costs. Auditors compare your policy document to your actual configuration. Discrepancies are findings.
✅ Fix: Review your backup configuration against your policy quarterly. Use Softyz Enterprise’s backup scope report to verify every system in your policy is actually in the backup scope.
03
Monitoring alerts configured but not responded to
Alerts fire when backups fail. Alerts go to a shared inbox. Nobody monitors the inbox consistently. Auditors ask for the alert log for the audit period and find 23 backup failure alerts with no documented response to any of them. The backup was “monitored” — but not acted upon.
✅ Fix: Assign a named individual responsibility for backup alert response. Document every alert and every response in a simple log. Softyz’s alert system emails the designated recipient and logs alert timestamps — combine with a simple ticket for each alert response.
04
Backup configuration changed without a change management ticket
An engineer changed the backup retention period from 90 days to 30 days to reduce costs. No ticket was created, no approval was documented, and the change wasn’t communicated. Auditors find this by comparing current configuration to the policy document and noticing the discrepancy — then asking for the change management record, which doesn’t exist.
✅ Fix: Any change to backup scope, frequency, retention, or credentials must go through your change management process. Treat backup configuration changes the same as production system changes — they require documentation and approval.
05
No defined RTO or RPO — or they’re defined but not validated
Many companies say their RTO is “4 hours” because it sounds reasonable — but have never timed an actual restore to verify that 4 hours is achievable. Auditors sometimes ask for restore timing evidence. If you’ve never measured it, you can’t prove you meet your own target.
✅ Fix: Run a timed restore test that measures time from restore initiation to verified data availability. Document the time. If it exceeds your stated RTO, either update your RTO or improve your recovery process — and document the remediation.
How to prepare your SOC 2 backup evidence package in 2 weeks
📋 Week 1 — Audit and document
Day 1–2
Pull existing backup job logs for the full audit period from your backup system. Identify any gaps (missed backups) and document them with timestamps.
Day 2–3
Review backup policy document against current backup configuration. Document every discrepancy. Update the policy or the configuration — then document the change with a change management ticket.
Day 3–4
Pull alert logs for the audit period. For any alert without a documented response, write a retrospective incident record explaining what happened and how it was resolved.
Day 4–5
Confirm RTO and RPO are defined in writing. If they’ve never been formally documented, write them now and get management sign-off.
🧪 Week 2 — Test, validate, package
Day 6–7
Run a timed restore test for each major system in your backup scope. Document: what was restored, from which backup date, start time, end time, success/failure, tester name. Keep the output file as evidence.
Day 8
Confirm monitoring is active and alerts are routing to the correct individual (not a shared inbox). Screenshot the current alert configuration with recipient details visible.
Day 9
Collect your backup vendor’s SOC 2 Type II report, DPA, and any relevant security documentation. These form part of your vendor management evidence.
Day 10
Assemble the complete evidence package: policy, logs, restore test records, alert config, vendor docs, and change management records. Organise by control — not by type — to make the auditor’s job easier.
How Softyz Enterprise maps to SOC 2 backup requirements
Availability A1.2
Backup job logs — automatic
Every backup run generates a timestamped log with file count, size, duration, and success/failure status. Exportable as CSV or PDF for the audit period you specify.
✔ Satisfies: documented backup schedule consistently followed
Availability A1.2
Restore test records — automatic
Every restore initiated through the Web Manager generates a dated verification record: what was restored, source backup timestamp, destination, duration, and success confirmation. No manual documentation needed.
✔ Satisfies: regular restore testing with documented results
Common Criteria CC7.2
Monitoring & alerts — built in
Configurable email alerts for backup failures, missed backups, and anomalous activity. Alert delivery log shows every alert sent and to whom. Audit-ready alert history export available.
✔ Satisfies: backup monitoring with failure alerts
Common Criteria CC8.1
Configuration audit log — automatic
Every configuration change in Softyz Enterprise is logged: who made the change, what was changed (with before/after values), and when. Integrates with SIEM via webhook for your change management workflow.
✔ Satisfies: change management for backup configurations
Vendor Management
Softyz’s own SOC 2 Type II report
Softyz maintains its own SOC 2 Type II certification. Our report is available under NDA to Enterprise customers for inclusion in your vendor management evidence package.
✔ Satisfies: vendor compliance documentation requirement
Availability + Confidentiality
WORM immutable storage + AES-256
Backup data cannot be modified or deleted before retention expiry. Zero-knowledge AES-256 encryption. Both documented in Softyz’s security architecture documentation, available to Enterprise customers.
✔ Satisfies: data integrity and confidentiality requirements
“The question I get most often from companies preparing for SOC 2 Type II is: ‘How many restore tests do we need?’ The answer: enough to demonstrate a pattern of regular testing throughout the audit period. Quarterly is the minimum auditors accept. Monthly is what I recommend. The test itself takes 10 minutes — the documentation takes another 5. It’s the most valuable 15 minutes in your entire audit preparation process.” — Dev Gupta, VP Security & Compliance, Softyz Inc. · CISSP · ISO 27001 Lead Auditor
📋 SOC 2 Backup Readiness Checklist
Policy & Documentation
✓
Written backup policy — covers schedule, retention, scope, RTO, RPO, responsible parties, and review cadence
✓
Policy matches configuration — backup system actually configured to match what the policy document says
✓
RTO and RPO defined in writing — with management sign-off and dates
Operational Controls
✓
Backup job logs available for the full audit period — exportable, complete, showing success/failure per run
✓
Restore test records — documented quarterly minimum, monthly preferred, throughout the audit period
✓
RTO validated — at least one timed restore test showing actual restoration time within your stated RTO
✓
Monitoring alerts active — routed to a named individual, not a shared inbox
✓
Alert response records — documented response for every backup failure alert during the audit period
Change Management
✓
All backup configuration changes documented with change management tickets throughout the audit period
✓
Change approvals documented — authorised individual’s approval recorded for each change
Vendor Management
✓
Backup vendor’s SOC 2 Type II report collected and filed as part of vendor management evidence
✓
Data Processing Agreement (DPA) signed with backup vendor covering data handled during the audit period
✓
Vendor security documentation — encryption standards, data residency, incident response process on file
✅ Free SOC 2 backup compliance assessment
Every Softyz Enterprise account includes a complimentary 45-minute SOC 2 backup compliance assessment with a certified compliance engineer. We review your current backup configuration against the Availability and Security Trust Service Criteria and identify any gaps before your auditor does. Contact support@softyzinc.com to schedule. No commitment required.