Nobody plans to leave a system unbacked up. It happens because a service was spun up outside the normal process, or because everyone assumed the SaaS vendor handles it. This matrix exists to make the gaps visible rather than discovering them during a restore.
What you get
A full inventory of data stores mapped to backup method and frequency
A SaaS section, where the shared-responsibility gap usually hides
An explicit 'not backed up' column, recorded as a decision rather than an oversight
A monthly reconciliation to catch newly created systems
How to use this template
1
Inventory data stores, not servers. A single host may carry a database, a config store, and a share with different requirements. Listing hosts rather than data stores is how a critical config directory ends up outside the backup selection.
2
Check what your SaaS vendors actually retain. Most SaaS providers protect their infrastructure, not your data from your own mistakes. Deleted records are often recoverable only within a short window, and a vendor-side restore usually restores the whole tenant rather than one object. Record the actual terms.
3
Record deliberate non-coverage as a decision. Some things genuinely should not be backed up: ephemeral build agents, reproducible caches. Record them with who decided and why, so the next person does not treat the absence as a finding or, worse, as coverage.
4
Reconcile monthly against what exists. Compare this matrix against your cloud inventory and asset register monthly. Newly created systems are the most common source of unbacked-up data, and they are easiest to catch within weeks.
What's inside
Here's a preview. Unlock the free download to get all 4 sections (3 more below).
Coverage matrix
One row per data store. 'Covered by' must name the specific job, not the product.
Most backup policies describe a schedule and stop. The clauses that decide whether you recover from ransomware are the ones usually missing: an immutable copy, an offline or logically-separated copy, and a stated obligation to test restores.
A backup job reporting success proves a file was written. It does not prove the file can be read, is uncorrupted, or contains what you think. This log records the only thing that answers that question: an actual restore, timed and verified.
Most asset registers die of one disease: nothing in the organisation forces them to be updated. This one is built around the three events that actually change an asset's state (assignment, repair, and disposal), so the register is maintained by the work rather than by an annual audit.
Often yes. Vendor resilience protects against vendor-side failure, not against your own deletion, a bad integration, or ransomware reaching synced storage. Check each platform's retention window and restore granularity: a tenant-wide rollback is frequently unusable in practice.
What should a backup coverage matrix track?
+
Each data store with its tier, backup method, the specific job covering it, frequency, retention, whether a copy is immutable, the last verified restore, and an owner. Deliberate non-coverage should be recorded as a decision with a name against it.
How do systems end up without backups?
+
Almost always because they were created outside the normal provisioning process, or because a SaaS platform was assumed to be covered by the vendor. A monthly reconciliation against your cloud inventory and asset register catches both while the gap is still weeks old.
