M
MSP Workflows
Backup & Disaster Recovery

Backup Audit Checklist for MSPs

A structured checklist for auditing backup coverage, job health, and restore readiness across your client base. Designed to catch the gaps that only surface during a disaster.

Checklist · Updated Feb 2026

Why Backup Audits Are Necessary

Backup configurations drift. A server gets added and nobody assigns a backup policy. A retention policy expires and nobody renews it. A storage volume fills up and the backup tool starts overwriting older restore points silently. A SaaS migration moves data out of the backup scope. Backup audits catch these problems before a disaster reveals them. The audit should run quarterly at minimum, and after any significant infrastructure change (server migration, cloud adoption, new SaaS subscription, client offboarding).

Coverage Audit

  • Every server has an active backup policy assigned
  • Every workstation with local data has endpoint backup configured
  • SaaS data (M365, Google Workspace) is protected by a dedicated backup tool
  • Cloud workloads (Azure VMs, AWS instances) are backed up independently of provider snapshots
  • New systems added since the last audit have backup policies
  • Decommissioned systems have been removed from backup scope
  • Exclusions are documented with justification and owner sign-off
  • Backup agents are installed and reporting on all in-scope devices

Job Health Audit

  • All backup jobs completed successfully in the last 7 days
  • No backup job has failed more than twice in the last 30 days
  • Backup schedules align with RPO targets per client tier
  • Retention policies meet contractual and regulatory requirements
  • Offsite replication is current (no replication lag exceeding 24 hours)
  • Storage utilization is below 80% on all backup targets
  • Backup encryption is enabled at rest and in transit
  • Backup credentials are current and stored in the password vault

Restore Readiness Audit

  • Most recent restore test is documented and dated within the last quarter
  • Actual RPO and RTO from restore tests meet client SLA targets
  • Backup encryption keys are stored securely outside the backup system
  • Recovery runbooks are current and accessible to the on-call team
  • Recovery contact lists (client contacts, vendor support) are current
  • Bare-metal restore media or cloud recovery procedure is documented
  • Incident communication templates are prepared for disaster scenarios

The SaaS backup gap

The most common finding in backup audits is unprotected SaaS data. Microsoft 365 retention policies are not backups. Google Workspace Vault is a compliance tool, not a recovery tool. If a user deletes a SharePoint site or an admin purges a mailbox, native retention may not help. Verify that every SaaS tenant has independent backup coverage.

Build it into your calendar

Schedule backup audits as recurring PSA tickets with assigned owners. If the audit depends on someone remembering to do it, it won't happen consistently. Tie the audit cadence to your QBR schedule so results are fresh for client reporting.

How long should a backup audit take per client?

+

For a well-documented client with 5 to 10 protected systems, budget 30 to 45 minutes. For larger or poorly documented environments, budget 1 to 2 hours. The first audit for a new client always takes longer because you're establishing the baseline.

What should happen when the audit finds a gap?

+

Create a remediation ticket in the PSA with an owner and a due date. Classify the gap by severity: unprotected critical system (fix within 24 hours), expired retention policy (fix within 1 week), documentation gap (fix within 2 weeks). Track remediation to completion.

Should clients receive the audit results?

+

Yes. Include a summary in the next QBR showing coverage status, any gaps found, and remediation actions taken. Transparency builds trust and makes it easier to get client buy-in for investments in backup coverage.

Related Guides
← Back to all guides