How to answer
What are your recovery time and recovery point objectives?
Two numbers with no scenario attached mean nothing, and a reviewer who has to guess will assume the flattering reading and hold you to it.
Recovery time objective is [4 hours] and recovery point objective is [1 hour] for the production database, based on continuous backup with point-in-time recovery. Restores are tested [quarterly]; the most recent test completed on [date] and met both targets.
Square brackets are yours to fill in. FillTrust grades an answer like this not in your documents when your documents support it.
- Answered from
- Your business continuity or disaster recovery plan, which should state both numbers and the scenario they apply to.
- Evidence to attach
- The date and outcome of the most recent restore test. Not the plan itself, which is long and answers a question nobody asked.
- Where it is asked
- CAIQ v4.0SIG LiteISO 27001 Annex A · A.5.30
Both numbers are commitments, so the useful discipline is to write down the one you could actually meet at three in the morning on a Sunday, not the one that sounds professional. Recovery time is how long until service is back. Recovery point is how much data you would accept losing. They are separate, they are often confused, and confusing them in an answer is a tell.
Attach a scenario, because the numbers are meaningless without one. Restoring a table somebody dropped is a different exercise from rebuilding in another region after a provider incident, and the same four hours cannot honestly cover both. The clearest version of this answer gives the targets for the ordinary case and says plainly what happens in the extraordinary one, even when the honest sentence is that a full regional loss would take a day and has never been rehearsed. A reviewer can accept that. What they cannot accept is finding out afterwards.
The arithmetic has to work. If backups run nightly, the recovery point objective is up to twenty-four hours, whatever the plan says. If the database supports point-in-time recovery, the RPO is close to the replication lag and it is worth saying which mechanism gives you the number, because "one hour" backed by an explanation is credible and "one hour" on its own is a target somebody typed.
The part of this answer that carries the most weight is the test. A plan with two numbers in it is a document; a restore performed last quarter that met them is evidence. If you have never done one, the answer that works is the one that says the targets are design targets and the first restore test is scheduled, with a date. That is a risk a reviewer can price. An untested plan presented as an operational capability is a claim that fails the moment anyone asks a follow-up question, and this is a question that attracts follow-ups.
How this one goes wrong
Specific to this question, not general advice.
- Giving two numbers with no scenario attached. An RTO of four hours means something different for a single corrupted table and for the loss of a region, and a reviewer who has to guess which one you meant will assume the flattering one and hold you to it.
- Quoting your cloud provider's numbers as your own. Their durability figure is not your recovery time, because your recovery time includes noticing, deciding, and running the restore.
- Never having tested a restore. A backup that has not been restored is a hypothesis, and this is the question where that shows.
- An RPO shorter than the backup interval. Hourly snapshots cannot deliver a fifteen minute RPO, and the arithmetic is the first thing a careful reviewer checks.