Somewhere in most security questionnaires is a box asking for your recovery time objective. The temptation is to write something that sounds responsible, like four hours, and move on. The person reading it may not challenge you. The outage will.
These two numbers are only useful when they describe what your infrastructure can actually do. Written that way they are genuinely valuable: they tell you what to buy, what to automate, and what to tell a customer during a bad afternoon. Written aspirationally, they are a promise you have not funded.
The two numbers, plainly
Recovery time objective is how long you can be down. The clock starts when the system fails and stops when customers can use it again. It includes noticing the problem, deciding what to do, doing it, and verifying it worked. Teams routinely measure only the last part and then wonder why real incidents run long.
Recovery point objective is how much data you can afford to lose. If you back up at 02:00 and the database is destroyed at 16:00, you have lost fourteen hours of work, whatever your document says. RPO is set by your backup arrangement, not by your intentions.
A useful way to hold them: RTO is about time without the service, RPO is about work that has to be redone.
Deriving the numbers instead of inventing them
Start from consequence rather than from a round number. Three questions get you most of the way.
What happens at each duration?
Walk forward through an outage and describe the actual effects.
- One hour: some users notice, support gets a handful of messages, nothing lasting.
- Four hours: every active customer has noticed. If you sell to businesses, some of them cannot do their own work.
- One day: customers start asking about the contract and whether they need a fallback.
- Three days: you are losing accounts and the outage has become the thing people know about you.
The point where the consequence stops being recoverable is roughly where your RTO belongs. For many B2B products that lands somewhere inside a working day, but the reasoning matters more than the figure.
What does losing an hour of data actually cost?
This varies enormously by product and is worth thinking about concretely. If your users write long documents, an hour of lost work is a serious injury to trust. If your product mostly reflects data that originates elsewhere and can be re-synchronised, the same hour is an inconvenience. If you take payments, losing transaction records is a different category of problem again, because the money moved even though your record of it did not.
What can you deliver today?
This is where the restore drill becomes load-bearing. You measured time to working system. That measurement, plus some honest margin for the fact that a real incident happens at an inconvenient hour and involves confusion, is your current achievable RTO. Your backup interval is your current achievable RPO.
Now compare. If what you need is materially better than what you can deliver, you have found a gap. That gap is the useful output of this whole exercise, and it is worth writing down even when you decide not to close it yet.
Writing it down
Keep it short and specific. A defensible statement covers the system, the two numbers, the basis, and the last test:
Primary application database. Recovery time objective: four hours. Recovery point objective: twenty-four hours. Basis: nightly automated backup at 02:00 UTC with thirty-day retention; restore drill on 14 August 2026 completed in one hour fifty minutes to a working system. Margin allows for detection and decision time outside working hours.
That paragraph does more for you in a security review than a page of generalities, because every claim in it can be checked. Note what it does not do: it does not promise a number nobody has tested, and it does not pretend detection is instant.
Tiering, briefly
Not everything deserves the same target. A short list is usually enough:
- The product itself. The tightest numbers, because this is what customers pay for.
- Things customers do not see but you need to operate: internal admin, analytics, reporting. Hours to days is usually fine.
- Things that can wait. Say so explicitly. "We would restore this within a week and accept the data loss" is a legitimate position, stated.
Giving everything the same aggressive target is a common instinct and it weakens the document, because it is obviously untrue and invites the reader to doubt the rest.
The detection gap
Recovery time is usually measured from the moment someone starts working on the problem. Customers measure it from the moment the product stopped working. The difference between those two is detection time, and it is frequently the largest single component of a real outage.
If your database fails at 02:00 and nobody notices until the first support email at 08:30, a technically excellent two-hour recovery still produced an eight-and-a-half hour outage. Nothing in the restore procedure can fix that.
Two things narrow it, and neither is expensive:
- An external check that alerts a human. Something outside your own infrastructure requesting a page that exercises the database, on a short interval, and paging someone when it fails. Monitoring that runs on the same infrastructure it monitors is the classic mistake.
- An alert path that reaches a person who is awake. An email to a shared inbox is not an alert. If your realistic answer is that nobody would see it until morning, your stated RTO should include that, or you should change the alerting.
Stating this honestly is better than hiding it. "Four hours during business hours, next business day outside them" is a defensible commitment for a small team. A flat four hours that quietly assumes somebody is always watching is not.
Where the numbers quietly rot
These figures decay. Three things change them without anyone revisiting the document:
- The database grows. A restore that took twenty minutes at 5GB does not take twenty minutes at 80GB.
- The architecture gains pieces. A new queue, a new cache, a new service. Each one is something that has to come back up, and the recovery is only as fast as the slowest part.
- The person who knew the procedure leaves. The technical recovery time is unchanged; the real one is now much longer.
Re-testing annually catches the first two. Writing the procedure down catches the third, which is why offboarding and recovery are more connected than they look.
The short version
Pick numbers you can meet, say how you know, and write down the gap between what you can do and what you would like to do. A modest objective with evidence behind it reads as competence. An ambitious one with nothing behind it reads as marketing, and the person reading your questionnaire has seen a great deal of both.