RPO and RTO for management: how much data and time the company can afford to lose

Ask a small business what happens if the server does not come up tomorrow morning, and the most common answer is “we have a backup”. Ask what time the last backup was taken and how long it would take to get the system working again, and the search begins for the person who set it up years ago. The backup exists, but nobody knows what it actually promises.

These two unknowns have names. RPO tells you how much data the business can lose. RTO tells you how long it can wait for the system to come back. Both numbers are a business decision that management should make consciously, before the IT person chooses the hardware and schedule to match.

What RPO and RTO mean

In its SP 800-34 guide to contingency planning for information systems, the US NIST defines RPO (Recovery Point Objective) as the point in time before an outage to which process data can be restored from the most recent backup. In practice it is the distance between the last good backup and the moment of failure. If the backup runs daily at 22:00 and the server fails the next day at 15:00, the business loses 17 hours of changes: invoices, orders, stock corrections, everything the team entered since the morning.

RTO (Recovery Time Objective) is, according to the same document, the maximum time a resource can remain unavailable before the impact on business processes becomes unacceptable. It is counted from the failure to the moment people are working again. Not to the moment the files finished copying.

NIST adds a third concept that small businesses rarely talk about: MTD (Maximum Tolerable Downtime), i.e. the total downtime the process owner is prepared to accept, taking all consequences into account. RTO must fit within MTD with a margin, because after the system is restored the backlog still has to be cleared and lost data re-entered. RPO, on the other hand, is not part of MTD, because it describes the process's tolerance for data loss.

Why management sets these numbers

The IT person knows how long it takes to restore a database from backup. They do not know what a day without issuing invoices in the last week of the month costs the business, or whether the sales team can survive four hours without access to orders. NIST puts it plainly: acceptable downtime is set together with process owners and management, and only then are recovery methods chosen.

The same logic underlies ISO 22301, which sets out requirements for a business continuity management system. ISO states that the requirements of the standard are generic and apply to organisations of any type and size. A small business does not need certification to use its basic order: first the business impact of downtime, then restoration targets, and finally the technical solutions.

The reverse order ends in one of two ways. Either the business buys expensive solutions that protect unimportant systems, or management assumes that “if anything happens, we will be back in an hour”, while the current backup only allows recovery after two days.

Separate targets for each process

A single RPO and RTO for the whole business is almost always a mistake. Email, the ERP system, project files and the scan archive have different value and change at different rates. It makes more sense to divide processes into three groups:

• Critical: stopping them blocks sales, shipping, production or payments.
• Important: a break is costly, but for a limited time there is a workaround, for example working on paper.
• Supporting: they can be restored later without stopping the core business.

For each process in the first two groups, it is worth recording the owner, the systems it depends on, the acceptable data loss, the acceptable downtime and the workaround during an outage. Backups are then designed on the basis of this material.

Example calculation for a small business

The example below is a typical illustrative scenario, with figures assumed for the purpose of the calculation. We assume a trading company with 15 employees: an ERP system with a database on a server in the office, files on a NAS, email in the cloud. After talking to department heads, management sets these targets:

Process	Systems	Impact of downtime	RPO	RTO
Sales and invoicing	ERP, database	No documents, shipping halted	1 hour	4 hours
Documents and quotes	Files on the NAS	Work hampered, partial workaround	4 hours	1 working day
Communication	Cloud email	Contact hampered, phone as a workaround	24 hours	1 working day
Scan archive	NAS, archive folder	No noticeable impact for a week	24 hours	5 working days

These targets directly determine the backup schedule:

• RPO of 1 hour for the ERP means a database backup at least every hour during working hours. A nightly backup will not meet this target, because in the worst case it will return data from a dozen or more hours earlier.
• RPO of 4 hours for files is met by snapshots (i.e. records of the state of a volume at a given moment) taken on the NAS every two hours, with a margin for a failed job.
• RPO of 24 hours for email a daily backup of mailboxes to an independent location is enough.

RTO, in turn, determines where the backup must be kept and what must be ready. Take 2 TB of data to restore from the cloud over a 100 Mb/s connection. Even with the connection fully used, the download alone takes about 44 hours (2 TB × 8 = 16,000,000 Mb, divided by 100 Mb/s gives 160,000 seconds). With an RTO of 4 hours for the ERP, you therefore need a local backup in the office, hardware on which the database can be run, and a documented procedure. The cloud backup remains the safeguard in case the whole office is lost.

How RPO and RTO translate into cost

The cost of downtime in this example is easy to estimate in person-hours. Four hours without the ERP with 15 people means up to 60 person-hours of work halted or done on workarounds. On top of that comes the time to re-enter data from the lost hour and delayed shipments. You can plug in your own business's salaries and margin in downtime cost calculator.

On the other side is the cost of the solution. NIST shows this as two curves: the longer the outage, the more it costs the business, and the shorter the RTO, the more expensive the recovery solution. The point where they cross is different in every organisation. As a rough guide it looks like this:

Target	What you usually need	Relative cost
RPO 24 h, RTO several days	Nightly backup, restore to hardware bought after the failure	Low
RPO a few hours, RTO 1 day	Snapshots during the day, local and off-site backup, a spare disk or server	Medium
RPO 1 h, RTO a few hours	Frequent database backups, virtualisation, hardware ready to run the backup, a rehearsed procedure	Higher
RPO and RTO in minutes	Replication to a second server, automatic failover, on-call cover	High

The conversation about cost then stops being abstract. Management compares the annual cost of maintaining an option with the cost of one realistic outage. It often turns out that it is worth paying for a shorter time for one system, while the basic option is enough for the rest of the business.

A test turns a target into a confirmed capability

A document that declares an RTO of four hours is only an assumption until someone has measured a full restore. In its CPG 2.0 cybersecurity performance goals, the US CISA recommends testing backups and restores at least once a year. In its ransomware guide, CERT Polska points out that regular tests help avoid a situation where, despite having backups, the pre-infection state cannot be restored because of an error in the backup itself.

A good test measures two things that correspond to the two targets:

1. Time. From the decision to restore to the moment a user signs in to the system and issues a document. This is your actual RTO.
2. Data point. Which is the last document in the restored database and what time it is from. This confirms the RPO.

The result is compared with the target. NIST allows for a situation where the target cannot be reached straight away: the gap is then recorded in an action plan with deadlines. For a small business this can be one page with a list: what is missing, who will do it and by when.

Where the target most often drifts from reality

The first restore test in a small business usually reveals the same gaps. None of them is visible in the backup job report, and each one lengthens the RTO or undermines the RPO.

• A database backed up like ordinary files. Files of an open database copied while it is in use can be inconsistent. The backup “succeeded”, but the database will not start after the restore.
• No installer, licence or configuration for the software. Data alone, without the application that reads it, does not restore the process.
• Only one person knows the backup password. An encrypted backup without the key is useless, and the key is sometimes in the head of a former employee.
• A backup permanently connected to the network. CERT Polska recommends that the backup should not be connected as a network resource on the working network, because ransomware can then reach it together with the server.

Each of these can be fixed with relatively little effort, provided it comes to light during a calm test.

Decision sheet for management

On a single sheet, the following fields are enough for each critical and important process:

• the process name and its owner on the business side,
• the impact of downtime after 1, 4, 8 and 24 hours,
• target RPO and RTO,
• the systems, data, people and suppliers needed for recovery, including passwords and backup encryption keys,
• the fallback mode during downtime,
• the date of the last test and the measured result,
• the gap between the target and the confirmed capability.

Such a sheet does not need specialist software. It needs one conversation between management and department heads, and one restore test. After that conversation it is also easier to judge whether the current backup configuration, described in more detail in our post on data backup in the company, meets your needs at all.

Where to start in your business

Start with the one process that hurts most when it stops. Set its RPO and RTO, check what time the last backup is from, and time a restore on separate hardware. That one test will tell you more than months of green “job completed successfully” reports.

Once the targets are known, choosing backups becomes a technical task: how many copies, on what media and where, which we describe in our post on the 3-2-1 rule. We design servers, virtualisation and backups around the agreed targets as part of our service servers, self-hosting and backup.

Sources

• NIST, SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, May 2010, updated 11.11.2010, https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final (accessed 02/10/2026)
• NIST Computer Security Resource Centre, Glossary: Recovery Time Objective, https://csrc.nist.gov/glossary/term/recovery_time_objective (accessed 02/10/2026)
• ISO, ISO 22301:2019 Security and resilience. Business continuity management systems. Requirements, https://www.iso.org/standard/75106.html (accessed 02/10/2026)
• CISA, Cross-Sector Cybersecurity Performance Goals, Version 2.0, December 2025, https://www.cisa.gov/cybersecurity-performance-goals-2-0-cpg-2-0 (accessed 02/10/2026)
• CERT Polska, Ransomware guide (Poradnik ransomware), https://cert.pl/uploads/docs/CERT_Polska_Poradnik_ransomware.pdf (accessed 02/10/2026)

As of 2 October 2026.