Many SaaS teams can truthfully say they have backups. Fewer can clearly explain what those backups cover, how long they are retained, who can restore them, and when a restore was last tested.
That gap matters during customer security reviews, cyber insurance questions, board reporting and real incidents.
Scheduled snapshots are useful, but they are not the same as recovery confidence. Good backup evidence should show that the team understands what must be restored, how restoration works, and where the remaining risks are.
The practical question is:
If an important AWS system failed, was deleted, or had to be rebuilt under pressure, what could we actually recover?
1. Start with the recovery claim
Before collecting backup screenshots, decide what claim the evidence needs to support.
Common claims include:
- production databases are backed up;
- backups are retained for a defined period;
- restores are tested periodically;
- backup access is restricted;
- backup configuration is reviewed;
- recovery objectives are understood;
- important systems can be rebuilt from documented steps.
Each claim needs a different kind of evidence.
A screenshot of an RDS snapshot schedule may support the claim that database backups exist. It does not prove that the application can be recovered, that object storage is protected, that infrastructure state is available, or that anyone has performed a restore recently.
Keep the claim narrow enough to be true.
2. Map what actually needs to be recovered
Backups are not only databases.
For an AWS SaaS environment, recovery may depend on:
- relational databases;
- object storage;
- EBS volumes or instance state;
- configuration files;
- secrets and parameter stores;
- container images or deployment artefacts;
- infrastructure-as-code repositories;
- Terraform state or equivalent platform state;
- DNS and certificate configuration;
- CI/CD pipelines and deployment permissions;
- logging and monitoring configuration;
- third-party integrations.
A team may have excellent database snapshots and still struggle to restore the service if infrastructure state, secrets or deployment paths are missing.
Prepare evidence around the service, not only the storage layer.
A useful internal exercise is to ask:
If the production database was restored to a clean environment, what else would be needed before customers could use the application again?
That question often reveals gaps that snapshot evidence alone will not show.
3. Separate backup existence from restore confidence
Customer questionnaires often ask whether backups are performed and tested. Treat those as two different questions.
| Question | Evidence that helps | Evidence that is stronger |
|---|---|---|
| Are backups performed? | Backup policy, snapshot schedule, AWS Backup plan or service configuration | Coverage map showing which production systems are included |
| Are backups retained? | Retention settings or lifecycle policy | Retention summary reviewed by an owner |
| Are backups protected? | Access control notes, encryption settings, deletion controls | Separate backup administration and documented change process |
| Are restores tested? | Restore test calendar or ticket | Recent restore test notes with date, owner, result and follow-up actions |
| Can you meet recovery expectations? | Stated RTO/RPO targets | Restore test results that support or challenge those targets |
It is acceptable to say that restore testing is being improved. It is not acceptable to imply that restore testing is mature when the only evidence is a backup schedule.
4. Define RTO and RPO in plain English
Recovery objectives are often handled badly because they sound like compliance language.
For practical purposes:
- Recovery Time Objective is the maximum outage the business can tolerate before customers, revenue or operations are materially affected.
- Recovery Point Objective is how much recent data loss the business can tolerate.
Small teams do not always need formal enterprise targets on day one. They do need realistic expectations.
A weak answer is:
We can restore quickly.
A stronger answer is:
Our current recovery expectation for the production database is based on snapshot frequency, retention settings and the most recent restore test. The target is being reviewed as part of backup and recovery readiness work.
That wording avoids pretending the team has certainty it has not tested.
5. Review retention and deletion risk
Backup evidence should show not only that backups exist, but that they will still exist when needed.
Useful review questions include:
- How long are production backups retained?
- Does retention match customer, contractual or business expectations?
- Who can delete backups?
- Can the same compromised administrator delete both production data and backups?
- Are lifecycle policies documented and intentional?
- Are backups encrypted where appropriate?
- Are backup changes logged?
- Are old backups removed deliberately rather than accidentally retained forever?
The goal is balance. Very short retention may not support investigation or recovery. Unlimited retention may create cost, privacy and operational problems. Evidence should show that retention is deliberate.
6. Run and record restore tests
Restore testing is the evidence customers and leadership usually care about most.
A useful restore test record does not need to be a huge report. It should capture:
- system or dataset tested;
- date of test;
- person responsible;
- restore source used;
- environment restored into;
- steps followed;
- result;
- time taken;
- issues found;
- follow-up actions;
- whether the test supports current recovery expectations.
The test should be safe and scoped. Restoring a production database into a non-production environment, for example, may require data handling controls, access restrictions and careful cleanup.
The point is not to create theatre. The point is to learn whether the recovery path works before the business depends on it.
7. Prepare customer-safe backup evidence
Backup and recovery evidence can expose sensitive information if shared carelessly. Avoid sending raw backup inventories or internal architecture details unless necessary.
Customer-safe evidence may include:
| Evidence item | What it shows | Sharing note |
|---|---|---|
| Backup coverage summary | Which production services are covered | Use service labels rather than full internal names where possible |
| Retention summary | How long backups are retained | Avoid exposing sensitive bucket or snapshot identifiers |
| Restore test note | Restores are tested, not assumed | Redact dataset names, customer names and internal paths |
| Ownership note | Someone is responsible for recovery | Use role names where individual names are not appropriate |
| Gap summary | Remaining weaknesses are known | Separate implemented, partial and planned controls |
| Recovery runbook summary | The team has a restoration process | Share a summary rather than operational secrets |
For enterprise customers, a concise evidence pack is often more useful than a large export. It should be accurate, current and approved for external use.
8. Weak vs stronger backup answers
| Customer question | Weak answer | Stronger answer |
|---|---|---|
| Are backups performed? | Yes, backups are automatic. | Production databases are backed up according to the documented backup policy, with retention configured and reviewed by the platform owner. |
| Are restores tested? | We have not had issues with backups. | Restore tests are recorded with date, owner, result and follow-up actions. Where testing is incomplete, the improvement plan is tracked. |
| How long are backups retained? | We keep snapshots for a while. | Retention periods are documented for production data stores and reviewed against business and customer expectations. |
| Can you recover from accidental deletion? | AWS keeps our data safe. | Recovery depends on the affected service. We maintain backup coverage, access controls and restore procedures for production systems. |
| Who can restore backups? | The engineering team can. | Restore permissions are limited to approved roles, and the recovery process identifies the owner, approver and escalation path. |
The stronger answers are not necessarily more complicated. They are just more precise.
9. Common backup evidence gaps
Common findings in small AWS environments include:
- database snapshots exist, but restores have never been tested;
- object storage is not included in the recovery story;
- infrastructure state is not protected;
- backup retention is shorter than customer expectations;
- backup access is too broad;
- old production data is retained longer than intended;
- there is no recovery owner;
- restore steps depend on one engineer’s memory;
- backups are present but not monitored;
- no one knows how long restoration would actually take.
These are usually fixable. The first step is to make them visible without turning the exercise into a blame session.
10. Build a reusable backup evidence pack
A reusable backup evidence pack should include:
- backup coverage map;
- retention summary;
- restore test notes;
- recovery owner and escalation path;
- evidence screenshots or exports approved for external use;
- known gaps and remediation dates;
- recovery assumptions and limitations;
- date of last review.
Keep the pack current. Backup evidence ages quickly when databases, accounts, storage buckets or deployment models change.
What good backup evidence leaves behind
Good backup evidence should make recovery less mysterious.
The team should know what is backed up, what is not, how restoration works, who owns the process, how long recovery is expected to take, and where evidence supports those claims.
The best outcome is not a perfect-looking questionnaire answer. It is a recovery process that has been looked at, tested, documented and improved before the next customer review or incident forces the issue.