RPO and RTO: what they are, why they matter, and why almost no company actually monitors them

IT infrastructure is now the true backbone of every company. In fact, the moment systems stop, IT ceases to be a technical issue and becomes a business emergency. Whether due to a ransomware attack, a data center failure, or simple human error, in those moments backups become fundamental in determining the true resilience of an organization. At that point, attention focuses exclusively on two pragmatic questions:

  1. “How much data have we lost?”
  2. “How long until we are operational again?”

The answers to these questions are enclosed in two acronyms: RPO and RTO.

Too often, these parameters are confused with settings to simply “set and forget.” In reality, they are the only metrics that truly matter for operational continuity. They determine the difference between a manageable incident and a shutdown capable of causing enormous economic damage or contractual violations. Monitoring them isn’t about filling out a report; it’s about knowing how much risk we are facing every day.

The definitions (explained clearly)

To manage this risk, we first need to understand the substantial difference between the two concepts, which act on opposite vectors of time.

RPO (Recovery Point Objective): The cost of lost data

RPO looks to the past. It is the measure of tolerance for information loss. In practical terms, RPO answers the question: “If the system crashes now, to what point in time does the last secure copy of our data go back?”

If your RPO is 24 hours, you are implicitly accepting that a failure could wipe out an entire day of revenue, orders, or employee work.

  • Why it is critical: RPO dictates the necessary frequency of backups. If the business cannot afford to lose more than an hour of data, running a backup once a day is a violation of business needs, even if that backup technically works perfectly.

RTO (Recovery Time Objective): The cost of lost time

RTO looks to the future. It is the measure of reaction speed. RTO answers the question: “How long can this service remain down before the economic consequences become unacceptable?”

It is not just about “turning the servers back on.” RTO includes all the time needed to diagnose the problem, recover data from the backup, and make applications usable by users again.

  • Why it is critical: Because time is money. For an e-commerce site or a production line, the wrong RTO can cost thousands of euros per hour.

Step Zero: Who decides the numbers? (Spoiler: not IT)

Now that we have clarified the definitions, there is a crucial misunderstanding to dispel: RPO and RTO are not parameters that IT can decide alone.

Too often, this scenario occurs: the company buys backup software, and the manager tells the technician: “You configure it as best as you can.” The technician, based on available resources (disk space, bandwidth, time windows), sets a standard backup every 24 hours. No one asks the fundamental question.

Setting these objectives is also a Business responsibility: only management can know how much downtime would cost the company, and incident management—in terms of costs—must account for the technical limits imposed by the systems. Delegating this decision to the IT department prevents companies from being truly aware of how they will be able to handle potential issues.

To define a correct RPO/RTO target, the question is not “How much disk space do we have?”, but:

  • “Can we afford to lose the orders from the last 30 minutes?”
  • “If the ERP system stays down for 8 hours, do we lose clients or incur penalties?”
  • “How much does one hour of downtime cost us?”

If the cost of downtime is extremely high, the Business must mandate an RTO of a few minutes and provide the budget to achieve it. If the service is secondary, an RTO of two days might be acceptable. Without this strategic decision upfront, IT is flying blind. And flying blind in disaster recovery is dangerous.

The common mistake: the misalignment between Business and IT

Once (ideally) the Business has set the targets, a second structural problem arises. There is almost always a huge difference between “performing backups” and “being compliant with those targets.”

Usually, those managing IT control backups via dashboards that show green or red lights. If the backup was completed, the light is green, and everyone feels safe. However, these dashboards only show technical execution (the job), not adherence to the business objectives decided above.

Let’s look at a real-world example of this misalignment:

  1. The Business decides: “Client data is vital to us. We cannot lose more than 4 hours of work (Target RPO = 4h).”
  2. The Technical Reality: Due to an old habit or lack of clear directives, the backup is scheduled every 24 hours.
  3. The Result: The backup runs perfectly every night. The technical dashboard marks “Success.”

The paradox is served: you have a backup system that works perfectly from a technical standpoint, but the company is exposed to a risk 6 times higher than what the Business accepted. The report says everything is fine, but the data says you are not compliant.

Why almost no company actually monitors them

If RPO and RTO are so vital, why do few companies have this data under control in real-time?

  1. Infrastructure Complexity: Data today is scattered everywhere: on-premise servers, cloud (AWS, Azure), SaaS services. Every provider has its own reporting, and connecting the dots is difficult.
  2. Lack of Context: Backup software sees “file names” and “IP addresses.” The business sees “Services” (e.g., Logistics, Administration). An automatic translator between these two worlds is missing.
  3. The Excel Limit: Often, attempts are made to calculate compliance manually on spreadsheets. But an Excel sheet is static: the moment you finish compiling it, the backup situation has already changed. It is not a monitoring tool; it is an already outdated snapshot.

From theory to real data: the Salazar approach

To get out of this gray area, a change in perspective is needed. It is no longer enough to monitor if the backup “ran”; we must monitor if the data is safe according to the parameters established by management.

This is where Salazar comes in. Salazar is the compliance platform that sits on top of your current backup systems to finally give you the data that matters.

  • Audit always available: Salazar calculates the actual RPO of every single asset based on the last valid full backup image available, regardless of the software that performed it. It tells you immediately if you are achieving the RPOs/RTOs defined by the company or if you are at risk.
  • Service-based Vision: Abandon the logic of server names. With Salazar, you organize backups into Business Services. You can see at a glance if the “Sales” service is protected, without having to query technicians or Excel sheets.
  • Ready for Auditors: When you need to demonstrate compliance, you don’t have to build manual reports. RPO and RTO data is there, ready to be consulted and exported. Furthermore, thanks to user permission management, it is possible to assign specific services to an auditor, who can check them autonomously, in full respect of privacy.

Stop measuring the success of backups. Start measuring the security of your company.

Discover how Salazar calculates your real RPO

getsalazar.io