RPO and RTO: define them before the next ransomware

On the day ransomware encrypts your servers, nobody wants to find out, in real time, how much of the operation can be recovered and how long it will take. Those two answers have names: RPO and RTO. They are numbers you define in advance — calmly, on the table — or numbers the incident defines for you, at the worst possible moment.

This piece explains both concepts without beating around the bush, shows the backup rule that still holds (the 3-2-1), and why a carrier — which cannot go a single day without issuing CT-e or tracking freight — needs to think about this in a specific way. Clean definitions, the kind you'll wish you had read before.

RPO (Recovery Point Objective) is the maximum amount of data your operation can afford to lose, measured in time. If your RPO is 1 hour, it means that, after restoring, you may have lost up to the last hour of work — and that's acceptable. If the RPO is 24 hours, you can go back to yesterday morning's snapshot.

In practice, the RPO defines how often you run backups. You can't have a 15-minute RPO with a once-a-day backup — the math doesn't add up. The smaller the RPO, the more frequent (and more expensive) the backup.

The question that unlocks the definition is direct: if I lost everything that entered the system since the last backup, how much would that cost me? For a CT-e that was issued but not saved, the cost is re-keying the data and risking tax inconsistency. For a cargo manifest, it's not knowing what went onto the truck.

RTO (Recovery Time Objective) is the maximum time your operation can stay down before the restore is complete and the system is running again. If the RTO is 4 hours, you have 4 hours, from the incident until the operation is running again — not a minute more.

RTO isn't just the time to copy files back. It's the whole clock: detecting the problem, isolating what was compromised, finding a clean backup, restoring, validating that it's intact, and switching it back on. Whoever times only the copy discovers too late that validating and switching back on take longer than expected.

The question here is about money: how much does each hour of downtime cost? For a carrier, an hour of downtime means a delayed delivery, an SLA penalty, a truck sitting in line without its invoice, and a customer on the phone. That cost per hour is what justifies — or not — investing in faster recovery.

They're easy to mix up. The simple way to tell them apart:

• RPO looks backward — how much data, in the past, you're willing to lose.
• RTO looks forward — how much time, from now on, you're willing to stay down.

A system can have a great RPO and a terrible RTO: you lose almost nothing, but it takes three days to switch back on. Or the opposite: it's back in 20 minutes, but you've reverted to last week's snapshot. Both need to make sense together, for each system. The tax ERP demands tight RPO and RTO. A BI data warehouse, which rebuilds itself from the sources, can tolerate looser numbers.

RPO and RTO only exist if there's a real backup to restore from. The rule that still organizes this is the 3-2-1:

• 3 copies of your data (the original plus two).
• 2 different media or technologies (not both on the same disk, on the same server).
• 1 copy off-site — offline or immutable, one that ransomware can neither reach nor erase.

The detail that most often falls apart is the "1." A backup that sits on the same server, or on a NAS mounted on the network, gets encrypted along with everything else on the day of the attack. Modern ransomware seeks out and destroys backups first, precisely to force the ransom. That's why the off-site copy must be immutable (write-once, that nobody overwrites) or genuinely disconnected. Without that "1," the whole rule won't save you.

This is the sentence that hurts the most after an incident. A backup routine that runs every day, produces a file, shows green on the dashboard — and has never been restored — is an assumption, not a guarantee. It's on the day of the attack that many people discover the file was corrupted, that the right database was missing, or that the restore takes three times as long as planned.

A backup only becomes a backup when you actually test the restore, in a separate environment, and time it. That test answers, with fact rather than faith, whether your RTO is real and whether the RPO matches the configured frequency. Concrete recommendation: a documented restore test every quarter, and whenever you change something major in the system.

A carrier doesn't have the luxury of an RTO of "a few days." Without the ERP, there's no issuing of CT-e or MDF-e — no truck leaves the yard without a tax document. Without tracking, you lose the fleet's position and visibility of the cargo in transit. Every hour down turns into an SLA penalty, a delayed delivery, and a ringing phone.

How to think about this in practice:

• Separate systems by criticality. Tax document issuance and tracking (SASCAR, Autotrac, Omnilink) demand an RTO of hours and a low RPO. BI reports can tolerate more.
• A backup frequency that matches the RPO. If you can afford to lose at most 1 hour of invoices, the tax database backup can't be daily.
• An immutable, off-site copy — the ransomware that hits the ERP must not be able to reach its backup.
• A timed restore test, to know whether in 4 hours you can really go back to issuing documents.

The goal is simple: that a data hostage situation is a matter of hours of disruption, not days of downtime — and that paying a ransom is never the only option on the table. It's privacy and continuity by design, not by patch.