Security questionnaire disaster recovery evidence checklist: RTO, RPO, backups and tests
A copyable BCP and disaster-recovery evidence worksheet for SaaS security questionnaires: separate RTO/RPO targets from observed restore-test evidence, record backup scope, owners, freshness, gaps and customer-safe proof.
No email gate. Copy this into your existing questionnaire workbook or evidence register. Record unknowns as unknowns: a recovery target, a written plan and an observed restore test are different kinds of evidence.
Copyable evidence register
Keep targets, tests and customer-safe proof in separate fields.
This makes it harder to accidentally present an aspirational RTO/RPO or an untested plan as an observed recovery result.
Customer question / control | System or service in scope | RTO target: stated / unknown | RPO target: stated / unknown | Backup scope and cadence | Restore / recovery test date | Observed test result | BCP / DR plan source | Evidence source | Evidence exposure: customer-safe / internal-only / unavailable | Gap / assumption | Evidence owner | Answer owner | Last reviewed
Review checklist
Answer the customer without manufacturing resilience evidence.
- [ ] Customer question and the exact service or system in scope are recorded before drafting an answer - [ ] RTO target is recorded from an authoritative source or marked unknown rather than invented - [ ] RPO target is recorded from an authoritative source or marked unknown rather than inferred from backup cadence alone - [ ] Backup scope, cadence and retention are recorded only where current evidence exists - [ ] Business-continuity and disaster-recovery plan sources are linked with owner and last-reviewed date - [ ] Restore, failover or recovery-test date is recorded separately from the written plan - [ ] Observed recovery-test result is kept separate from the RTO/RPO target and from an untested design claim - [ ] Evidence is classified as customer-safe, internal-only or unavailable before it is reused in a questionnaire - [ ] Assumptions, exceptions and missing evidence remain visible instead of being converted into confident customer claims - [ ] A named human reviewer approves the customer-facing answer and confirms evidence freshness before submission
Customer question and the exact service or system in scope are recorded before drafting an answer
RTO target is recorded from an authoritative source or marked unknown rather than invented
RPO target is recorded from an authoritative source or marked unknown rather than inferred from backup cadence alone
Backup scope, cadence and retention are recorded only where current evidence exists
Business-continuity and disaster-recovery plan sources are linked with owner and last-reviewed date
Restore, failover or recovery-test date is recorded separately from the written plan
Observed recovery-test result is kept separate from the RTO/RPO target and from an untested design claim
Evidence is classified as customer-safe, internal-only or unavailable before it is reused in a questionnaire
Assumptions, exceptions and missing evidence remain visible instead of being converted into confident customer claims
A named human reviewer approves the customer-facing answer and confirms evidence freshness before submission
A plan is not a test result. A target is not an observed recovery time.
Use the organisation's actual policies, backup configuration evidence, exercise records and restore-test records. If an RTO, RPO, test date or result cannot be supported, keep the field unknown or needs review rather than filling it with an industry-looking number.
VendorOS Rescue can organise approved wording, evidence references, owners, freshness and explicit gaps. It does not create a disaster-recovery capability, prove a control was tested, certify business continuity or turn a planned control into implemented evidence.