How to answer
Do you maintain a business continuity and disaster recovery plan, and is it tested?
Two numbers carry this answer, RTO and RPO, and they are the two a reviewer can hold you to during a real outage. Do not publish ones you have not measured.
Yes. We maintain a documented business continuity and disaster recovery plan covering our production environment, with a recovery time objective of [4] hours and a recovery point objective of [1] hour. The plan is reviewed annually and was last tested in [month, year].
Square brackets are yours to fill in. FillTrust grades an answer like this reused from your library when your documents support it.
- Answered from
- Your business continuity plan. The recovery objectives are the part a reviewer reads.
- Evidence to attach
- The date and outcome of the last test. Occasionally the plan's table of contents.
- Where it is asked
- CAIQ v4.0 · BCR-01SIG LiteISO 27001 Annex A · A.5.30
This question is really asking for two numbers and one date.
Recovery time objective is how long the service can be down before it becomes a business problem, or how quickly you intend to be back. Recovery point objective is how much data you can afford to lose, or how far back the last good copy may be. Four hours and one hour are common for a SaaS running on managed infrastructure with point-in-time recovery.
Do not publish numbers you have not measured. These are the two figures a customer will quote back during an actual incident, and the gap between an RPO written to sound good and a backup cadence that cannot support it is discovered at the worst possible moment. If your database has point-in-time recovery with a five-minute window, your RPO is five minutes and you should say so. It is better than the four hours you might have written to be safe.
The date is the third element and the one most often missing. A plan that has never been exercised is a document, not a capability, and restoring a backup into a scratch environment once a year is the cheapest possible way to find out that the restore path has a broken step in it. Teams that have done this have a date; teams that have not usually discover during the test that something no longer works, which is precisely the point.
One distinction worth getting right, because reviewers who know infrastructure will probe it: high availability is not disaster recovery. Running across multiple availability zones protects you against a machine or a rack. It does not protect you against a dropped table, a bad migration, ransomware, or an account compromise, all of which replicate perfectly to every zone you have. If your answer describes multi-AZ redundancy and calls it disaster recovery, an experienced reviewer will notice, and it is the kind of noticing that turns a questionnaire into a call.
How this one goes wrong
Specific to this question, not general advice.
- Publishing an RTO and RPO you have never measured. These are the two numbers a reviewer can hold you to during an actual outage.
- Answering yes for a plan that has never been restored from. An untested backup is a hypothesis.
- Confusing high availability with disaster recovery. Multi-AZ protects against a machine; it does not protect against a deleted database or a corrupted migration.