RPO and RTO Explained: What Your Business Can Lose

RPO and RTO are two acronyms that structure any continuity plan. Properly understood, they let you decide how much to invest in backup and recovery without overspending on what is not critical.

• RPO: how much data, measured in time, the business can lose.
• RTO: how long a system can stay down.
• Declared values are only reliable if measured in a drill.

The two concepts, simply

RPO (recovery point objective) answers how much work can be lost: if losing the last few hours or the last day is acceptable, that is the RPO. RTO (recovery time objective) answers how long you can wait to be operating again. Both are defined per system, not for the whole company.

How to define them

Talk to the people who use each system. Email, invoicing and the file server do not share the same urgency. A practical way to proceed:

1. List the systems that sustain operations.
2. Ask what happens if they stop for an hour, a day or a week.
3. Ask which information would be hard to rebuild.
4. Record an RPO and RTO per system, and who approves them.

These values drive backup frequency and the type of recovery solution; see also 3-2-1 backup.

Declaring is not the same as measuring

An RTO written in a document is an intention. It becomes data when a drill is run: the system is restored, the process is timed, information integrity is checked and the result is compared with what was declared. Synchronising device clocks with a reliable time source helps keep recorded times consistent, and the record is closed with the signature of whoever led the test.

For a formal reference on contingency planning, NIST SP 800-34 Rev. 1, "Contingency Planning Guide for Federal Information Systems", offers a detailed structure.

What to do

• Define RPO and RTO for the three or four most important systems.
• Schedule a recovery drill covering at least those systems.
• Record the actual time and the differences from what was declared.
• Adjust backup or infrastructure if the gap is significant.
• Repeat the exercise after major changes.

Frequently asked questions

Can each system have a different RTO? Yes, and that is advisable: it concentrates effort on what really matters.

What if the drill does not meet the declared values? That is a useful result: it lets you correct before a real incident, either by adjusting the solution or revisiting expectations.

Do I need a formal plan? A short, written, tested plan is enough to start.

In our work with Chilean organizations, we run drills with measured RPO and RTO, and see that the exercise clarifies the gap between what is declared and what is real.

IT Lab supports Chilean organisations in this. Contact us.

Sources

• NIST, SP 800-34 Rev. 1, "Contingency Planning Guide for Federal Information Systems": https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final