Tech Due Diligence OPS-3: Backup and Disaster Recovery
What This Control Requires
The assessor evaluates the backup strategy, disaster recovery plan, recovery time objectives, recovery point objectives, and the evidence of regular testing to ensure that recovery procedures actually work.
In Plain Language
Could your company survive a catastrophic data loss or a complete infrastructure failure? This control determines whether the answer is yes or an uncomfortable silence. Assessors evaluate not just whether backups exist, but whether they are comprehensive, tested, and capable of meeting defined recovery objectives. Untested backups are barely better than no backups at all.
Expect questions about what data and systems are backed up, how often and how long backups are retained, where backups are stored and whether they are isolated from production, your defined RTO (Recovery Time Objective - how quickly service must be restored) and RPO (Recovery Point Objective - how much data loss is acceptable), evidence of restoration testing, and your disaster recovery plan for different failure scenarios.
The single most critical finding in this area is untested backups. Too many organisations discover their backups are incomplete, corrupted, or impossible to restore only when they actually need them. Regular restoration testing is the only way to know your backups will work. Assessors look specifically for evidence of successful tests.
How to Implement
Build a comprehensive backup strategy covering databases (automated daily backups with point-in-time recovery), file storage (replication and versioning for user-uploaded content), application configuration (Infrastructure as Code provides implicit backup), secrets and certificates (backed up via your secrets management system), and code repositories (inherently backed up through distributed version control).
Define RTO and RPO for each critical system based on business impact. For a typical SaaS application: production database RPO should be measured in minutes (point-in-time recovery), database RTO should be under one hour, file storage RPO under 24 hours, and overall service RTO under four hours for the core product.
Store backups in a separate location from production. At minimum, use a different availability zone. For stronger protection, use a different region or cloud provider. Make sure backup storage is not reachable from the production environment - this protects against ransomware that specifically targets backups.
Test restoration regularly. Run monthly automated integrity checks to confirm backups are complete and uncorrupted. Do quarterly database restoration tests by restoring to a separate environment and verifying data integrity. Conduct annual full disaster recovery drills simulating complete infrastructure loss and recovery from scratch.
Document your disaster recovery plan for different scenarios: single component failure (database, app server, cache), complete region or data centre loss, data corruption or deletion (accidental or malicious), and ransomware or destructive attack. For each scenario, cover detection, recovery steps, responsible parties, expected RTO and RPO, and the communication plan.
Automate recovery as much as possible. If infrastructure is defined as code and backups are automated, recovery can be largely hands-off. Manual recovery steps are error-prone and slow, especially under the pressure of a real disaster.
Monitor backup health continuously. Alert on backup failures, backup age exceeding thresholds, size anomalies (a sudden drop may mean an incomplete backup), and restoration test failures.
Evidence Your Auditor Will Request
- Backup configuration for all critical data and systems
- RTO and RPO definitions for critical services
- Backup restoration test records with dates and results
- Disaster recovery plan covering multiple failure scenarios
- Backup monitoring and alerting configuration
Common Mistakes
- Backups exist but have never been tested for successful restoration
- No defined RTO/RPO; recovery expectations are undefined
- Backups stored in the same region/account as production; vulnerable to regional failure
- Database backups exist but file storage or configuration is not backed up
- Disaster recovery plan is theoretical; has never been drilled or tested
Related Controls Across Frameworks
Frequently Asked Questions
How often should we test backup restoration?
Should backups be encrypted?
Track Tech Due Diligence compliance in one place
AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.
Start Free Assessment