Business Continuity Planning (BCP) is notoriously tricky for SMEs (and often Mid-Market Enterprise). Time, budget and resource constraints often mean it’s either rushed or sidelined. And when it does get attention, the theory behind it can feel like a maze of jargon and complexity. While that’s great for consultants, it’s not always helpful for businesses that just want a solid, workable plan.
Three acronyms that often cause confusion are MAO, RTO and RPO. Normally only rooted in IT recovery conversations, they should be part of the broader continuity and risk conversations. At their core, they’re all about timeframes for recovery — how long you can afford to be down, how quickly you aim to recover, and how much data you can afford to lose.
One common issue we see in SME BCPs is the lack of defined recovery timeframes. Plans might be detailed, but without clear timing, even the best strategies can fall short. Recover too slowly and you risk losing customers, revenue and reputation, sometimes irreversibly.
So where do you start? With your stakeholders. Understand what they expect, what they can tolerate, and how quickly your critical services need to bounce back. That understanding shapes everything else, from your recovery strategy to your backup schedule.
MAO is the maximum amount of time your business can be down before the impact becomes unacceptable. It’s the outer limit. Go beyond it and you risk serious damage. MAO applies to both organisational goals and individual resources.
In ISO 22301, this concept is referred to as the Maximum Tolerable Period of Disruption (MTPD). It’s essentially the same thing. You can find the formal definition in ISO 22301 Clause 3 – Terms and Definitions.
RTO is the target time to recover a business asset. It’s not the same as MAO. While MAO is the absolute deadline, RTO is the goal you aim for, ideally well within the MAO to allow for some breathing room.
RTOs aren’t just for IT systems. They can apply to services, teams, suppliers, infrastructure and more. The key is to base them on what’s acceptable to the business and what’s technically achievable.
For example, if MAO is “we must have this back within 24 hours”, then RTO might be “we aim to recover it within 8 hours”.
More on this can be found in PECB’s ISO 22301 definitions.
RPO is about data loss — specifically, how much data your business can afford to lose. It guides your backup strategy, how often you need to back up data to stay within acceptable limits.
Different teams may use the same data in different ways, so understanding their tolerance for data loss is key. The shorter the RPO, the more frequent the backups, and the higher the cost. It’s all about finding the right balance.
ISO defines RPO as the point in time to which data must be restored after a disruption. See ISO 22301 Clause 3 for more.
Here’s a practical, step-by-step approach to defining these recovery parameters.
Start with a Business Impact Analysis (BIA). This should be led by the business, not IT, and focus on identifying the services that are essential to your organisation’s survival.
For each critical service, map out the supporting systems, data, teams, suppliers and infrastructure.
Determine the maximum time each service can be unavailable before the impact becomes unacceptable.
Set a target recovery time for each resource, ideally well within the MAO.
Determine how much data loss is acceptable for each system or dataset.
Calculate the cost of downtime, financial loss per hour, reputational damage, regulatory penalties and so on.
Make sure IT recovery plans reflect business priorities, not just technical assumptions.
Recovery Time Objectives are often discussed in the context of IT systems, and for good reason. Applications, servers and data platforms are typically the most visible and measurable parts of a recovery plan. But RTOs should apply to any critical asset in the business, not just technology.
If a supplier is essential to delivering a core product, then the time it takes to restore that supply chain matters. If a key piece of equipment is needed to fulfil customer orders, then its recovery time is just as important as restoring a database. The same goes for people, processes, infrastructure and materials.
RTOs can and should be assigned to:
By broadening the scope of RTOs beyond IT, you ensure that your continuity strategy reflects the full range of dependencies that keep your business running. This also helps avoid blind spots in planning, where non-technical assets are assumed to recover automatically or without delay.
Ultimately, RTO is a business concept. It’s about how quickly you need something back to avoid unacceptable impact. Whether that “something” is a server, a person or a supplier, the principle is the same.
What is RPO in business continuity?
RPO is the amount of data a business can acceptably lose. It guides backup frequency and helps ensure data integrity during recovery.
What is RTO in business continuity?
RTO is the planned recovery timeframe for a business asset. It’s the target time to restore operations after a disruption.
What is the difference between RTO and RPO?
RTO is about how quickly you recover something. RPO is about how much data you can afford to lose.
How do you calculate RTO?
Use a BIA to identify critical dependencies and acceptable downtime. IT then sets an achievable recovery target based on tested capabilities.
How do you calculate RPO?
Assess how each team uses data and how much loss they can tolerate. Balance this against the cost and feasibility of frequent backups.
How often should you revisit your RTO and RPO values?
At least annually, or whenever there’s a major change in operations, systems or risk profile.
What are the core factors included in RTO/RPO calculations?
Business criticality, stakeholder tolerance, technical capability, cost of downtime and data usage patterns.
What are some simple ways to reduce RTO and RPO times?