The question “how long can the company work without the accounting system” usually gets the answer “not an hour”. The question “how many hours of work can you afford to lose if the system has to be restored from a backup” gets “none”. Both answers are understandable, but neither is useful: a backup system designed to those answers would cost more than the company itself.
The real answer is always somewhere between “not an hour” and “a week”, and it differs for every system. Email, accounting, production control and the file server each have different limits. To talk about these limits concretely, there are two metrics: RTO and RPO.
In this article we explain them without theory: what they mean, how to set them for a manager without an IT background, how they turn into backup frequency and recovery location, and how to write them down so that they suit a NIS2 or DORA audit.
RTO: how long you can wait
RTO (Recovery Time Objective) is the longest acceptable time from a system stopping to its being back in operation. Not the time in which IT promises to restore it, but the time after which the company starts to suffer real damage.
Examples from our clients’ day-to-day:
- Accounting. In a trading company, without the accounting system you cannot issue invoices or receive goods. RTO is four hours: for half a day you can work with paper delivery notes and enter them later, for a whole day you cannot.
- Email. In a service company where all communication with customers happens by email, RTO is one hour. In a logistics warehouse where orders arrive through a system and email is used for internal communication, it is a day.
- Production control system. If the line stops without the system, RTO is measured in minutes or tens of minutes, and restoring from a backup is not the first answer at all. The first answer is a duplicated system.
RTO is set by the business, not by IT. IT answers the question of whether the set RTO can be achieved and what it will cost.
RPO: how much work you can lose
RPO (Recovery Point Objective) is the longest acceptable period of data you can lose. In practice, it is how much time has passed between the last working backup and the incident.
The same examples:
- Accounting. If the backup runs every night, in the worst case a whole working day is lost: all the invoices, payments and warehouse movements of that day. Two accountants would re-enter them over a day or two. The company decides that RPO is four hours, and backups run every four hours.
- Email. Messages that arrived after the last backup do not disappear in a Microsoft 365 tenant, so RPO here is more often about deleted or encrypted data than about time. A day usually works.
- Production system. Lost hours mean it is unknown what was produced and from which materials. RPO is minutes, which means not backups any more but continuous replication.
RTO and RPO are independent of each other. You can have a system you restore in an hour but lose a day of data, and the other way around.
How to estimate the cost of downtime without euros
Managers often get stuck trying to put a price on downtime. That is not necessary. Three simpler questions per system are enough:
- How many people stop working when the system is down? Ten warehouse staff and two accountants are twelve people sitting and waiting. Multiply by hours.
- How many orders, shipments or invoices per hour go through this system? That is what will have to be re-entered or what will be lost altogether.
- What happens to the customer? They do not receive a shipment, do not get an answer, cannot pay. This is where contractual obligations and reputation begin.
Write the answers in a table with three columns: system, what stops after an hour, what stops after a day. RTO and RPO follow from it naturally, and it usually turns out that of twenty systems only four or five are really critical. Those are the ones that deserve most of the backup budget.
How RTO and RPO turn into technology
This is where the IT work begins. The two metrics drive two decisions.
RPO determines backup frequency
If RPO is a day, a nightly backup is enough. If it is four hours, backups or snapshots every four hours, which is already a requirement for storage and network. If it is minutes, backups no longer fit and you need real-time replication to a second location. Every step down is more expensive, so RPO should not be shorter than the business has actually decided.
RTO determines where and from what you restore
Recovery time has three parts: until you notice, until you find where to restore, and until you restore. If the server room has burned down, the second part may not exist at all, because there is nowhere to restore to. A short RTO therefore means a location prepared in advance.
| RTO | What it means in practice |
|---|---|
| A week | A backup is enough; a new server can be ordered and prepared |
| A day | You need a standby location where a server can be brought up from a backup |
| Hours | You need a pre-prepared environment and a tested procedure |
| Minutes | You need a duplicated system running all the time |
Our PlanB infrastructure recovery is designed exactly for the “day” and “hours” rows: backups of your servers are kept in our cloud, and next to them is a prepared environment where those backups are started as running servers while your infrastructure is being repaired. The backup side is covered by server backups at the frequency you set.
One more nuance: an RTO that nobody has measured is only a number in a document. You learn the real recovery time only by restoring the system into an isolated environment and looking at the clock.
How to document it for NIS2 and DORA
For both regulations RTO and RPO are management information, not technical information. NIS2 requires business continuity and backup management measures, and DORA requires an ICT business continuity policy with clear recovery objectives for important functions. In practice, one document with this structure is enough for an auditor:
- A list of systems with their criticality assessment.
- For each system, the RTO, the RPO and who approved them on the business side.
- Which technical measure delivers each metric: backup frequency, storage location, recovery location.
- When it was last verified that the metrics are achievable, and what the result was.
- When the document is reviewed: at least once a year and after major changes.
When we prepare companies for DORA requirements, we usually produce this document first, because all later decisions about backup and recovery depend on it.
Where to start
- List all the company’s systems and, for each, answer the question of what stops after an hour and what stops after a day.
- For the five most important systems, set the RTO and RPO together with their business owners, not with IT alone.
- Compare with how backups are made today: if RPO is four hours and the backup is nightly, you have a gap that only you know about.
- Restore one critical system into an isolated environment and measure the real RTO.
- If you would like us to do this work with you and prepare a document that suits an audit, get in touch through the contact form.
