RTO and RPO Explained: Setting Realistic Recovery Targets for a Small Business

What RTO and RPO mean, and why they come before any backup product

RTO is the longest you are prepared to wait to get something working again after an incident. RPO is how far back in time you can afford to lose data. One is about waiting, the other is about losing. They are separate questions and they usually have separate answers.

Microsoft defines RTO as the maximum acceptable time an application can be unavailable after an incident, and RPO as the maximum acceptable duration of data loss. NIST describes RTO as the length of time a system's components can be in recovery before the organisation's mission or business processes are harmed, and RPO as the point in time to which data must be recovered. These are two ways of saying the same thing. In practice, write both as plain durations: 'back within one working day' and 'no more than four hours of work lost'.

There is a third figure sitting behind them. NIST calls it maximum tolerable downtime: how long a business process can be disrupted before significant harm is done. Your RTO has to sit comfortably inside that figure, because the clock runs from the moment things stop, not the moment someone starts pressing restore.

The exercise below is a lightweight business impact analysis. You need no special tooling and the first half involves no technical access at all. The targets come from the business. The technical team then tells the business honestly whether current backups can meet them. Microsoft's guidance on reliability targets makes the same split: business stakeholders set the broad requirements and technical people assess the current state, and both must agree the targets are realistic.

Before you begin

You do not need administrator rights for the first half. You do need the right people in the conversation, which is harder than any command.

• Someone who can make spending decisions, usually the owner or a director.
• The person who runs each main activity - sales, finance, production, customer service. They know what a bad day looks like. IT usually does not.
• The person who looks after IT, whether in-house or a supplier. They answer for what exists and how it is backed up.
• Read-only access to your backup software's job history. You will need this in the second half, not the first.
• A single document or spreadsheet to record everything. A one-page table is the target.

Set the targets with the people who own the work

Start with what the business does, not with servers. People can tell you what they cannot live without. They cannot always tell you which server it runs on, and asking them to will get you vague answers.

Everyone's first answer is 'immediately'. It is also the most expensive thing on the menu. Offering bands (a couple of hours, half a day, a day, a few days, a week or more) gets you more honest answers than asking for a number.

1. List the things your business does in a normal week: taking orders, invoicing, paying staff, answering customer email, producing the work you sell. Describe them in words a non-technical colleague would recognise. Around ten is plenty.
2. For each activity, ask its owner how long it could stop before the harm becomes real, such as lost customers, missed payments or broken commitments. Also ask what they would do in the meantime, because a workable paper or phone fallback changes the answer. This is the tolerable downtime for that activity.
3. Ask the second question separately: if we had to go back to the last good copy, how much recent work could you re-create, and from where? Re-keying from sent emails or a notebook is possible. Re-creating a card payment or a web order the customer entered themselves is not. Anything that cannot be rebuilt from another record needs a tighter RPO.
4. For each activity, note what it depends on: the application, wherever its data lives, user sign-in, the network, the internet connection and any outside service involved. A dependency has to be back before, or alongside, the thing that relies on it. So sign-in and the network inherit the tightest target of anything that needs them. Also note where the recovery instructions and backup logins are kept. If they live only on the system that is down, you have found a problem worth fixing now.
5. Turn the answers into targets. Set each RTO shorter than the tolerable downtime, with real margin, because recovery time includes noticing the fault, deciding what to do, finding the right credentials, restoring and checking the result. Set each RPO no longer than the tolerable data loss. How much margin is a judgement call. Use more for systems you have never restored.
6. Group the activities into three or four tiers by recovery order, for example 'first', 'same working day', 'within the week' and 'can wait'. Fewer tiers are easier to follow when people are stressed. Have the owner of each activity and the person who controls the budget agree the list and put their names against it.

Worked example: setting recovery priorities

Consider a 15-person signage business with an order system on one server, shared design files and a cloud accounts package. The following example targets show how to rank recovery priorities; choose the actual numbers with the people who own each activity.

The interesting part is where the answers differ from what IT might have guessed.

• Order processing: the owner says the team can take orders on paper for a day but not much longer. Tolerable downtime is about a day, so the RTO is set at one working day. Staff can re-key orders from emails and phone notes for roughly half a day, so the RPO is four hours.
• Current job files: designers can usually redo a morning's work but not a week of it. RTO of one working day, and an RPO of the end of the previous working day.
• Accounts: invoicing can wait a few days and everything can be re-entered from sent invoices and bank statements. RTO of three working days, RPO of one working day.
• Completed-job archive: needed only when a customer asks for a reprint. RTO of a week, RPO of a week.
• User sign-in and the office network: nobody asks for these by name, but every other activity needs them. They go in the first tier because the order system cannot come back without them.

Check your targets against what your backups can really do

Targets are only wishes until you compare them with reality. This half needs read access to your backup software and, for the restore test, permission to run restores. Nothing in this section changes live data if you follow it as written.

RPO is limited by how often you create a restore point, meaning a saved copy you can roll back to. A backup that runs once a night means a worst case of roughly a day's work lost, and more if a job fails and nobody notices. The NCSC makes the same point in its backup rules: backing up more regularly means less data is lost in recovery.

RTO is limited by everything between 'something has broken' and 'people are working again'. Data size and storage speed are only part of that, which is why a timed test tells you more than arithmetic does.

If you use Microsoft 365, the platform has its own recovery features that affect your real numbers. Microsoft's SharePoint and OneDrive documentation says users can restore an entire OneDrive to any point within the past 30 days, and that deleted items can be recovered from recycle bins. Treat these as inputs rather than guarantees. Check the current documentation and how your tenant is configured before you rely on them for a target.

1. In your backup software's job history, find the last successful restore point for each tier-one and tier-two item, and note the gaps between restore points over the past few weeks. If the usual gap is longer than the RPO you set, or recent jobs have failed, the target cannot be met as things stand. Record that as a gap. Do not quietly change the target to match.
2. Look at where the copies are kept. Ask whether one compromised administrator account, or one piece of ransomware on a connected device, could reach every copy. The NCSC advises keeping at least one backup offline or otherwise out of reach, and warns that ransomware has encrypted connected USB and network drives holding backups. A backup that has been encrypted meets no RPO at all.
3. Pick the most important tier-one item and run a timed restore to a separate location. Never restore over live data. Do it outside working hours, because it uses storage and network bandwidth and may slow production systems. If you are restoring a whole server or virtual machine, keep it off the live network so it cannot clash with the original. Restores can take anything from minutes to most of a day depending on the size of the data and the hardware, so start the clock and carry on with something else if it is running unattended.
4. Stop the clock only when the restored system is actually usable: it starts, you can sign in and the data looks right. Note the total elapsed time. Then find the newest record in the restored data. The difference between that record's time and the moment the incident would have happened is your measured RPO.
5. Delete the test restore when you have finished. It contains real business data and has no business sitting around in an unmanaged location. Check that the original system and its data are unchanged.

When the numbers do not match

They often will not, and that is the useful finding. A gap between what the business wants and what the backups deliver is much better discovered on a quiet afternoon than during an outage.

You have three honest options for each gap. Relax the target, if the owner agrees the harm is tolerable. Improve the capability, for example by backing up more often, restoring from faster storage or writing a proper manual fallback for the gap. Or accept the risk in writing, so everyone knows what they decided and why.

Cost climbs steeply as targets tighten. Microsoft's guidance cautions against overengineering and says to aim for a practical, cost-effective solution. It also says that anything not thoroughly tested for recovery should not carry guaranteed commitments to others. We would apply the same caution to small businesses: keep your internal targets and anything you promise customers separate, and do not quote a recovery time externally until you have tested it.

Check it worked

You are done when the business could pick up the page and use it on a bad day.

• One page lists each activity, its owner, tolerable downtime, RTO, RPO, dependencies and tier.
• The owner or director has agreed it, including any gaps they have chosen to accept.
• At least one timed restore has been completed, with the elapsed time and the age of the newest restored record written beside the target.
• Every tier-one and tier-two item has a recent successful restore point in the backup history, or a recorded gap with a decision attached.
• A review date is set, and a reminder to revisit the page whenever you adopt a new system, change a supplier or move data to a new location.

If it does not work

Most problems here are about people and not about technology.

• Everything is 'critical' and every target is 'immediately': ask what each activity would cost per day and what the fallback is. When something has a workable fallback, it can usually wait. If everything still sits in the first tier, the budget conversation is the real finding.
• Nobody can say how much data they could re-create: sample a typical day. Ask someone to list the records created on it and where else each one is recorded.
• The timed restore takes much longer than the RTO: you have found a real gap. Decide between relaxing the target and changing the recovery method. Do not shave the number to make the table look tidy.
• You cannot find a restore point, or the backup login relies on the system that is down: stop here, record it as a priority issue and get specialist help before relying on that backup.