Checklist
Backup and Disaster Recovery Checklist: 96 Checks
The same 96 checks in 8 domains we use in every backup and disaster recovery audit. Use them to see where you stand.
Eight domains
From inventory to insurance evidence
Coverage, recovery targets, architecture, immutability, security, restore testing, DR planning and compliance.
Self-check vs audit
A checklist tells you what to ask; an audit checks the answers
The audit verifies each item with evidence and ranks what to fix first.
25+ yearsIT & cybersecurity experience
Certified expertsCISSP · C|CISO · Microsoft · Cisco
Southern CaliforniaLocal and on-site, based in Irvine
NationwideRemote audits & advisory
How to use it
96 checks in 8 domains
Work through each domain with your IT lead. Mark each check yes, partly or no, and keep a note of the evidence. In the audit, each check is rated Pass, Partial, Fail or Not applicable with the evidence behind it.
Prefer a guided version? Try the backup and disaster recovery self-assessment.
Domain 1 of 8 · IN
1. Inventory and coverage
Every server, VM, database, endpoint, NAS, SaaS app and Microsoft 365 workload, and what is not protected. More on inventory and coverage
| ID | Check |
|---|---|
| IN-01 | A current inventory lists every server, VM, database, NAS and cloud workload that holds business data |
| IN-02 | Each inventory item is marked protected or not protected, with the backup job that covers it |
| IN-03 | Microsoft 365 mailboxes, OneDrive, SharePoint and Teams are covered by a backup, not only retention policies |
| IN-04 | Line-of-business SaaS apps (accounting, EHR, CRM) have an export or backup arrangement |
| IN-05 | Laptops and remote endpoints that store unique data are backed up or redirected to a backed-up location |
| IN-06 | Active Directory, Entra ID configuration and DNS are included in the backup scope |
| IN-07 | Network device configurations (firewalls, switches, wireless) are backed up after every change |
| IN-08 | New servers and VMs are added to backup jobs as part of the build process |
| IN-09 | Excluded folders and file types are documented and approved |
| IN-10 | Backup job success and failure is reported daily to a named person |
| IN-11 | Backup capacity and retention growth are reviewed at least quarterly |
| IN-12 | Shadow IT and departmental storage (USB drives, personal cloud) are identified and addressed |
Domain 2 of 8 · RO
2. Recovery objectives
RPO and RTO per system tier, compared with what the business says it can tolerate. More on recovery objectives
| ID | Check |
|---|---|
| RO-01 | A business impact analysis names the critical systems and their owners |
| RO-02 | Each critical system has an approved recovery point objective (RPO) |
| RO-03 | Each critical system has an approved recovery time objective (RTO) |
| RO-04 | Systems are grouped into recovery tiers with a restore order |
| RO-05 | Backup frequency matches or beats the RPO for each tier |
| RO-06 | Measured restore times have been compared with each RTO |
| RO-07 | Dependencies (identity, DNS, network, licenses) are included in the restore order |
| RO-08 | Uptime or availability targets for key services are written down |
| RO-09 | Vendor and cloud service SLAs are compared with internal RTOs |
| RO-10 | Leadership has signed off on the RPO and RTO targets and the gaps |
| RO-11 | Targets are reviewed after major system or business changes |
| RO-12 | Manual workarounds for downtime are documented for critical processes |
Domain 3 of 8 · AR
3. Backup architecture
Copies, media, off-site location, retention and the 3-2-1-1-0 test. More on backup architecture
| ID | Check |
|---|---|
| AR-01 | At least three copies of critical data exist (production plus two backups) |
| AR-02 | Backups are stored on at least two different types of media or platforms |
| AR-03 | At least one copy is kept off-site or in a separate cloud region or account |
| AR-04 | At least one copy is offline, air-gapped or immutable |
| AR-05 | Backup verification runs automatically and reports zero errors, or errors are tracked |
| AR-06 | Retention periods meet legal, contractual and compliance requirements |
| AR-07 | Long-term retention (monthly, yearly) is defined where records rules require it |
| AR-08 | Application-consistent backups are used for databases and transactional systems |
| AR-09 | Backup encryption is enabled for off-site and cloud copies |
| AR-10 | Bandwidth and restore paths from the off-site copy have been sized and tested |
| AR-11 | The backup platform version is supported and receives security updates |
| AR-12 | Architecture is documented with a current diagram |
Domain 4 of 8 · IM
4. Immutability and isolation
Object lock, hardened repositories, retention lock, air gap and separate accounts. More on immutability and isolation
| ID | Check |
|---|---|
| IM-01 | Immutable retention (object lock, hardened repository or vendor equivalent) is enabled on at least one copy |
| IM-02 | The immutability period covers the time an attacker could stay undetected |
| IM-03 | Immutability settings cannot be shortened by a single administrator account |
| IM-04 | Cloud storage for backups sits in a separate account, subscription or tenant |
| IM-05 | Off-site credentials are not stored on production systems |
| IM-06 | Offline media, where used, is rotated and stored securely |
| IM-07 | Backup storage is not reachable from user networks or open file shares |
| IM-08 | Snapshots are not the only protection for critical systems |
| IM-09 | Soft-delete or recycle-bin protection is enabled on cloud backup vaults |
| IM-10 | Deleting backups requires a second approval or a delay |
| IM-11 | An isolated or clean recovery environment is planned for ransomware events |
| IM-12 | Immutability is verified by evidence, not only by configuration screens |
Domain 5 of 8 · BS
5. Backup security
Console MFA, separate admin accounts, domain separation, encryption, delete protection and alerts. More on backup security
| ID | Check |
|---|---|
| BS-01 | The backup console requires multifactor authentication |
| BS-02 | Backup administrators use separate accounts from their daily accounts |
| BS-03 | The backup server is not joined to the production domain, or uses a separate management domain |
| BS-04 | Backup service accounts have only the permissions they need |
| BS-05 | Default and vendor accounts are disabled or have changed passwords |
| BS-06 | The backup server and repository hosts are patched and hardened |
| BS-07 | Remote access to the backup console is restricted to admin networks |
| BS-08 | Backup encryption keys and passwords are stored outside the backup system |
| BS-09 | Alerts fire on failed jobs, deleted jobs, retention changes and mass deletion |
| BS-10 | Backup logs are sent to a central log or SIEM |
| BS-11 | Malware or anomaly scanning of backup data is enabled where the product supports it |
| BS-12 | Access reviews of backup administrators happen at least twice a year |
Domain 6 of 8 · RT
6. Restore testing and evidence
Test records, restore times against your RTO and what an auditor or insurer will accept. More on restore testing and evidence
| ID | Check |
|---|---|
| RT-01 | File-level restores are tested at least quarterly |
| RT-02 | Full server or VM restores are tested at least annually for each critical tier |
| RT-03 | Database and application restores are tested with application owners |
| RT-04 | Microsoft 365 or SaaS restores are tested |
| RT-05 | A domain controller or identity restore has been planned and tested |
| RT-06 | Restore tests record the start time, end time, data restored and result |
| RT-07 | Measured restore time is compared with the RTO and gaps are tracked |
| RT-08 | Restored data is checked for integrity and malware before use |
| RT-09 | Failed restore tests have a remediation ticket and a retest |
| RT-10 | Test evidence is stored where auditors and insurers can be shown it |
| RT-11 | A restore from the off-site or immutable copy has been tested |
| RT-12 | Restore tests run after major platform or version changes |
Domain 7 of 8 · DR
7. Disaster recovery and continuity plan
Written plan, runbooks, contacts, failover options and exercise history. More on disaster recovery and continuity plan
| ID | Check |
|---|---|
| DR-01 | A written disaster recovery plan exists and has an owner |
| DR-02 | The plan covers ransomware, hardware failure, site loss and cloud outage scenarios |
| DR-03 | Runbooks give step-by-step restore instructions for critical systems |
| DR-04 | Contact lists for staff, vendors, insurer and legal counsel are current and available offline |
| DR-05 | Roles and decision authority during an outage are defined |
| DR-06 | A communication plan covers staff, customers and regulators |
| DR-07 | A failover option (secondary site, cloud or DRaaS) exists for top-tier systems |
| DR-08 | The plan is stored where it can be reached when the network is down |
| DR-09 | A tabletop or recovery exercise ran in the last 12 months |
| DR-10 | Lessons from exercises and real incidents are fed back into the plan |
| DR-11 | The DR plan links to the incident response plan |
| DR-12 | Third-party and cloud providers’ continuity commitments are reviewed |
Domain 8 of 8 · CE
8. Compliance and insurance evidence
What HIPAA, PCI DSS, SOC 2, NIST CSF, IRS WISP and your insurer ask for, and whether you can prove it. More on compliance and insurance evidence
| ID | Check |
|---|---|
| CE-01 | Backup and recovery controls are mapped to each framework the organization follows |
| CE-02 | HIPAA contingency plan elements are documented for systems with ePHI |
| CE-03 | PCI DSS backup media and incident plan requirements are met for cardholder data |
| CE-04 | SOC 2 availability evidence (backup and recovery testing) is retained |
| CE-05 | NIST CSF 2.0 PR.DS-11 and Recover outcomes are assessed |
| CE-06 | Cyber insurance application answers about backups match reality |
| CE-07 | IRS WISP or FTC Safeguards backup and recovery items are addressed for tax and financial data |
| CE-08 | Record retention and legal-hold needs are reflected in backup retention |
| CE-09 | Backup reports are retained for the audit period |
| CE-10 | Exceptions and accepted risks are documented and approved |
| CE-11 | Evidence of restore testing is ready to share with auditors |
| CE-12 | Backup and DR responsibilities are written into vendor and MSP contracts |
This series
Page 14 of 16: Backup & DR checklist
Previous · page 13 of 16Sample reportFirst · page 1 of 16Backup & Disaster Recovery Audit (hub)Next · page 15 of 16Pricing →
- 1. Backup & Disaster Recovery Audit (hub)
- 2. Backup strategy: 3-2-1 and 3-2-1-1-0
- 3. Immutable & air-gapped backups
- 4. RPO, RTO, uptime & availability
- 5. Backup security hardening
- 6. Cloud backup for business
- 7. Microsoft 365 backup
- 8. Server, VM & database backup
- 9. Restore testing & evidence
- 10. Disaster recovery plan & DRaaS
- 11. Backup vendor selection guide
- 12. Backup compliance requirements
- 13. Sample report
- 14. Backup & DR checklist (this page)
- 15. Pricing
- 16. How to audit backups
Implementation partner
OC Security Audit stays independent and read-only, and does not resell any backup product. If you want hands-on help installing or reconfiguring the product you choose, adding immutable storage or running restore tests, IT Perfection can do that work and support ongoing operations.
Want the 96 checks verified with evidence?
Schedule a consultation. We scope the backup and disaster recovery audit in 30 minutes and quote one fixed price: $3,500, any organization size.
Read-only audit. No changes to your systems. Irvine, Orange County and Southern California on-site; remote nationwide.