Most disaster recovery plans collapse at the same point: the moment someone tries to use them. The numbers in the document don’t survive contact with a real restore — because the numbers were never tested, just typed. Below is how to set RTO and RPO targets that hold up at incident time, and where most SMBs end up promising more than they can deliver.
The definitions
Two metrics, both quoted in time, both flow from the same business-impact analysis.
RPO — Recovery Point Objective. The maximum acceptable amount of data loss, measured in time. An RPO of four hours means: when the system comes back, the most we can have lost is the last four hours of changes. RPO is a question about how often you back up.
RTO — Recovery Time Objective. The maximum acceptable downtime, measured from incident to service restored. An RTO of six hours means: from the moment the system goes down to the moment users can transact again, no more than six hours. RTO is a question about how fast you can restore.
The two metrics answer different questions. RPO is about what you’ve lost. RTO is about how long you’re without it. They are set independently per system, against the same business-impact analysis, and they almost never converge to the same number.
A worked example. Your customer transaction system has an RPO of 15 minutes and an RTO of two hours. Translated: you back up (or replicate) at least every 15 minutes, and when something breaks you can have the system back online within two hours of detection. The RPO drives infrastructure cost (frequent backups, replication, possibly hot standby). The RTO drives operational cost (runbooks, automation, tested restore procedures, people on call).
Why both matter
Plenty of plans get one and ignore the other. The most common failure mode is a strong RPO with no realistic RTO. The business has nightly backups, sometimes hourly, retained for 30 days — and a written-down RTO of “four hours” that has never been timed. The day the file server is encrypted, the restore takes 26 hours because no-one has rehearsed it, the backup system is on the same domain as the encrypted servers, and the documentation lives on the SharePoint that just got encrypted with everything else.
The opposite failure — strong RTO, weak RPO — is rarer but does happen. A business with a hot standby that fails over in minutes, but with replication broken for the last three weeks and nobody noticing. RTO met, RPO blown by three weeks of unreplicated data.
Both numbers need to be set, both need to be tested, and both need to come out of the business-impact analysis — not the IT team’s gut.
Setting RPO
The hard rule: you cannot have an RPO faster than your backup or replication interval.
If you back up nightly, your RPO is 24 hours, full stop. The document can say four hours all it wants — the data physically does not exist between backup windows. The first move when setting RPO is to align the document to the technical reality.
The second move is to push the business to actually engage with the number. Ask: “for the customer transaction system, how much data are we comfortable losing — one hour, four hours, a day?” Most non-IT leaders default to “as little as possible”. That’s not an answer; that’s a wish. The useful question is the inverse: “how much would it cost us, in dollars and reputation, to lose a day’s worth of data on this system? Now, an hour? Now, four hours?”. The cost curve isn’t linear, and the bend in the curve is the right RPO.
Once the target RPO is agreed, the infrastructure follows:
- Daily-or-better backups support an RPO of 24 hours or longer.
- Hourly backups or replication support an RPO of 1–4 hours.
- Continuous data protection / synchronous replication supports an RPO under an hour, sometimes near-zero. Expensive. Justified for systems where data loss equals customer harm or material financial loss.
A common SMB pattern: 24-hour RPO for general file shares, 4-hour RPO for the ERP or customer database, near-zero RPO for transactional systems where loss equals direct revenue impact.
Setting RTO
RTO is where plans fail at incident time. The mechanism is always the same: a number written down, never measured.
The way to set an RTO that holds up is to start from the measured restore time, not from the desired downtime. Run the restore. Time it. Then negotiate. If the measured restore is 16 hours and the business wants four — either invest in the infrastructure to close the gap (hot standby, automation, faster restore tier) or revise the documented RTO to something defensible.
In client environments we see the same gaps repeatedly:
- Restore documentation that assumes the backup system is reachable. It isn’t, if the network is compromised.
- Recovery procedures that depend on systems that are themselves down (the AD domain controller, the SharePoint runbook, the password manager hosted on the encrypted environment).
- Sequencing errors — restoring the application before the database it depends on, restoring the database before the storage it needs.
- “Restore” tested as “we can read the backup file” rather than “the system runs and users can transact”.
A documented RTO without a rehearsed restore is not an RTO. It is a target the business is going to miss, publicly, during an incident.
The minimum bar is one restore drill per quarter, end-to-end, on the systems with the most aggressive RTOs. Measure the wall-clock time from “decision to restore” to “system operational”. That number is the RTO you can defend. If it is higher than the business needs, the conversation is about closing the gap — not about adjusting the document.
Worked ranges
Indicative bands by workload type. These are not commitments — they are the rough territories most well-run SMB environments operate in. Your numbers depend on your infrastructure, your data classifications, and your appetite for spend.
| Workload | Typical RPO | Typical RTO |
|---|---|---|
| File shares (general) | 4–24 hours | 4–24 hours |
| Email (Microsoft 365) | minutes (M365 SLA) | minutes (M365 SLA) |
| Payroll | 24 hours | 24–72 hours |
| ERP / line-of-business | 1–4 hours | 4–12 hours |
| Customer-facing web | minutes | 1–4 hours |
| Transactional / payments | near-zero | minutes |
The point of publishing ranges is to frame the conversation, not to commit. Symsafe scopes DR engagements against the measured behaviour of the client’s environment — we do not publish a flat RTO/RPO commitment that ignores the system in front of us.
The 200-day cost cliff
The reason this matters in dollars: the IBM 2025 Cost of a Data Breach Report finds that breaches contained in under 200 days cost an average of USD $3.87 million globally, while breaches that take more than 200 days to contain cost USD $5.01 million — a 29 per cent premium for the slower response.
Containment time isn’t the same as RTO, but they are correlated. The same operational maturity that delivers a defensible RTO — rehearsed playbooks, named owners, working tooling, current documentation — also delivers faster containment when the incident is a breach rather than an outage. The organisations that hit a 24-hour RTO during a server outage are the same organisations that contain a ransomware incident in days rather than months.
Conversely, organisations whose written RTO has never been timed are the organisations whose breach playbook also doesn’t exist. The cost cliff is what happens to the second category.
The shortest path to defensible numbers
Three steps, in order, that move RTO/RPO from documented fiction to operational reality.
- Map the systems. List every system, classify by criticality, document current backup interval and current measured restore time. Most SMBs cannot produce this list from memory — the act of producing it surfaces gaps.
- Run one restore. Pick the most business-critical system. Restore it to a test environment. Time it. The number you get is the floor for everything else.
- Set targets the business has signed off on. Not IT’s targets — the business owner’s targets, with the cost of meeting them quantified. If the gap between current capability and target is large, the document records the current capability and the roadmap to close it. Honest numbers beat aspirational ones every time.
Symsafe runs DR posture reviews as part of the Secure MSA plan and as a scoped engagement on its own. We don’t publish RTO/RPO commitments because the numbers depend on infrastructure we don’t know yet. We do measure, document, and rehearse the recovery — which is the substance underneath the numbers.
Related reading
- Cyber threats in 2026 — what business leaders need to know
- Essential Eight, explained for Australian SMBs
- MDR — what it actually means
Sources: IBM, “Cost of a Data Breach Report 2025”; general DR best practice as documented by NIST SP 800-34 and ISO 22301.