Give recovery time and recovery point targets you have tested, describe how backups are made and stored, and say when you last restored from one. Add what is covered, such as the application and database, and what is not. Tested numbers beat ambitious ones.
Definitions
- RTO (recovery time objective). How long the service can be down before the impact becomes unacceptable.
- RPO (recovery point objective). How much data, measured in time, you can afford to lose.
- Business continuity. Keeping critical work going during a disruption, including people and process.
- Disaster recovery. Restoring technology after a major failure.
NIST's contingency planning guide describes helping organizations understand the purpose, process and format of information system contingency planning, and to evaluate systems and operations to determine contingency planning requirements and priorities. That last point is useful: you set priorities first, then targets.
For a plain explanation of the two targets, see RTO vs RPO: what they mean for software teams.
Build the answer from five facts
- Targets. RTO and RPO per service tier, if they differ. Say which are commitments in contracts and which are internal goals.
- Backups. What is backed up, how often, where copies live, whether they are encrypted, and who can delete them. Describe protection against accidental or malicious deletion.
- Redundancy. Multiple availability zones or regions, and what happens to a failed node. Be exact about whether failover is automatic.
- Tests. The date of your last restore test and what it showed. Include time taken.
- Dependencies. Which suppliers must be up for you to recover, such as your hosting provider or identity provider.
Be careful with these claims
| Claim | Risk |
|---|---|
| "Zero downtime" | Nobody can promise it; a reviewer will not believe it |
| "Daily backups" without restore tests | Backups that were never restored may not work |
| "Multi-region" | Often means storage replicas only, not a running second region |
| "RPO of zero" | Needs synchronous replication; verify it exists |
Show a restore test
Pick a recent test and summarize it: what you restored, how long it took, the amount of data, and what you changed afterward. Even a modest test with honest results reads better than a promise. See disaster recovery testing best practices and where does a SaaS vendor keep your backups and failover copies.
Evidence to attach
- Continuity and recovery plan summary with owner and review date.
- Backup configuration export.
- Last restore test record.
- Status page history, if you publish one. Pair it with status page versus trust page: what goes where.
Think about people too
Continuity includes staff. Say who covers if the engineer who knows the database is out, and how credentials for recovery are held so that no single person is a point of failure. Mention an alternate way to communicate if your chat tool is down.
Align with contracts
If your agreement states an availability commitment, check that your recovery targets support it. A contract promise your architecture cannot meet is a problem for both teams. Legal wording is for counsel; the engineering facts are yours.
Safeguard's continuous monitoring and asset discovery can help you keep track of what is running, which supports accurate recovery planning.
Quick check
How often should we test restores?
At least yearly for the full service, and more often for critical data stores. Record each test.
Do we share our full recovery plan with buyers?
Usually a summary is enough. Keep detailed runbooks internal, or share them under NDA if asked.
Sources
Last reviewed: 19 October 2026.
