MHA Consulting Blog | Roadmap to Resiliency

Bridging the Gap: Aligning RTOs Between IT and the Business Units

Written by Richard Long | May 5, 2026 2:56:09 PM

When it comes to how quickly key technologies can be restored, many organizations are weakened by the existence of hidden gaps between the expectations of the business units and the capabilities of the IT department. Identifying and closing these gaps requires an ongoing, nuanced conversation between all parties.

Related: Learning to Talk to Your IT/DR Colleagues

When Business Expectations and IT Reality Diverge

Sometimes it seems as if the IT department and the business units live on different planets. This is especially true when it comes to RTOs and RPOs—Recovery Time Objectives and Recovery Point Objectives.

An RTO, of course, is the time window within which a business process or application must be restored after an outage in order to prevent an unacceptably high impact to the organization.

An RPO is the maximum amount of data in an application that can be permanently lost as part of the data protection and recovered manually (or ignored) as part of the recovery.

Complications arise when the business departments develop one set of RTOs and RPOs for their most important applications (associated with their processes), and IT comes up with a different set of objectives for the same apps.

A difference of opinion at this stage is normal. Where things get off track is when organizations leave out the next step: surfacing the areas of misalignment between the two teams and reconciling them.

When an outage strikes, the consequences of allowing these gaps to persist can be ugly. They frequently include rude surprises, frustration, and recriminations. They can also include substantial impacts to the organization’s finances, reputation, and compliance.

Alignment Requires More Than Assumptions

How can organizations uncover and close gaps between the business departments’ expectations regarding RTOs and RPOs and the objectives IT is capable of delivering? The answer can be summed up in one word: conversation.

A nuanced discussion must take place between the BC team, the business units , and IT. “Nuanced” because there may be a need to discuss the “why” behind the requirements or the implications (cost and time) for IT to implement a solution.

10 Steps for Aligning RTOs and RPOs

Here are 10 steps to follow in aligning RTOs and RPOs between the business units and IT:

1. Start by validating the requirements

Before engaging IT, organizations need to ensure that the RTOs and RPOs coming out of the BIA are accurate, justified, and grounded in reality. Business units often express what they want (“no downtime,” “no data loss”), but those expectations can be costly or impractical. A meaningful requirement reflects the actual impact of downtime, not just a preference for speed.

2. Understand how applications are really used

Not all applications supporting a process are equally critical. A nuanced understanding of how an application is used—and the degree of reliance on it—is essential in setting appropriate RTOs and RPOs.

3. Recognize that business expectations and IT capabilities often diverge

Gaps between required and achievable RTOs and RPOs are common. They often develop because IT questions the conclusions of the business units and implements solutions based on its own understanding of company needs. Meanwhile, the business units might assume IT capabilities already meet its expectations. Without deliberate alignment, these assumptions go unchallenged.

4. Treat alignment as a conversation, not a handoff

Alignment does not happen by sending IT a list of targets. It requires an exchange of perspectives on requirements, capabilities, constraints, and trade-offs. In some cases, the existing capability may be acceptable given available workarounds. In others, gaps will require action.

5. Be clear about the difference between availability and recovery

Business units often think in terms of day-to-day availability: “we can’t be down.” IT, meanwhile, distinguishes between uptime and disaster recovery. RTOs and RPOs apply to disruption scenarios, not routine outages. Clarifying this distinction is essential to setting realistic expectations.

6. Expect cost and complexity to be part of the discussion

Reducing RTOs and RPOs often requires additional investment—such as infrastructure, licensing, or architectural changes. Many systems were not originally designed with aggressive recovery targets in mind. Closing gaps may require a phased approach, prioritization, or acceptance of current limitations based on cost-benefit considerations.

7. Account for cloud and third-party dependencies

Applications delivered through SaaS or cloud platforms are sometimes assumed to be inherently resilient. In reality, organizations must still define their requirements and understand what vendors are contractually obligated to provide. Alignment must include both technical capabilities and vendor commitments.

8. Plan for workarounds when gaps exist

Not all gaps can be closed immediately. When required recovery times are shorter than what IT can currently deliver, business continuity plans must include practical workarounds to bridge the gap. This ensures the business can continue operating even if full system recovery takes longer.

9. Don’t overlook RPOs

Data loss is less visible than downtime but just as critical. Organizations need to understand what data might be lost in a disruption and how it will be recreated or recovered. This may involve manual tracking, re-entry processes, or additional technical solutions, all of which should be discussed and planned in advance.

10. Document gaps and revisit them regularly

Alignment is not a one-time exercise. Gaps between requirements and capabilities should be documented, with decisions made about how to address them. These gaps should be reviewed periodically as business needs, technologies, and priorities evolve.

Taken together, these practices help organizations move from assumed alignment to demonstrated alignment, ensuring that recovery objectives are both realistic and actionable.

How MHA Can Help Bridge the Gap

In many organizations, aligning RTOs and RPOs is less a technical challenge than a communication one. It requires bringing together different perspectives, clarifying assumptions, and working through trade-offs. An experienced outside advisor can help guide this process, ensuring that discussions lead to practical outcomes.

MHA Consulting has extensive experience helping organizations navigate these conversations. Our expertise in business continuity is complemented by deep experience in IT. CEO Michael Herrera and I both previously worked in IT (at Bank of America and PetSmart, respectively). This background enables us to see over both sides of the fence, evaluate contending claims, and serve as a translator in conversations between the business departments and IT.

Our working method in helping clients with their alignment challenges varies with the organization’s needs and culture. We typically begin with an upfront analysis, gathering BIA outputs, application inventories, and existing recovery capabilities to develop a preliminary view of where gaps are likely to exist. We prioritize efficiency, minimizing the requests we make for people’s time. In our experience, a great deal of work can be accomplished through brief working sessions and quick email queries.

We also bring a practical sense of reasonableness to the discussion. Organizations can get stuck debating whether an RTO should be four hours or eight, without considering the cost and effort required to close that gap. We help frame those decisions in terms of business impact, feasibility, and investment, so that outcomes are not only technically sound but defensible. At the same time, we look beyond the numbers, helping clients think through related issues such as data loss implications, workaround strategies, and dependencies on cloud or third-party providers.

Closing the Gap Between Expectation and Reality

During disruptions, gaps between business expectations and IT capabilities around RTOs and RPOs can cause unpleasant surprises, recriminations, and serious impacts. Such gaps persist primarily because organizations fail to surface and reconcile them through structured, ongoing conversation.

By validating requirements, engaging in meaningful dialogue, and working through trade-offs, organizations can align recovery objectives with reality. The result is fewer shocks during disruptions and a stronger business continuity capability.

Organizations that want to close these gaps and strengthen alignment between business and IT do not have to go it alone. MHA Consulting helps clients facilitate these critical conversations, identify practical solutions, and build recovery strategies that stand up under real-world conditions. Contact us to learn more.

Further Reading

Frequently Asked Questions

What are RTOs and RPOs?

Recovery Time Objectives (RTOs) define how quickly a business process or application must be restored after a disruption to avoid unacceptable impact. Recovery Point Objectives (RPOs) define how much data loss is tolerable, measured in time, before the impact becomes unacceptable.

Why is it important to achieve alignment on RTOs and RPOs between the business units and IT?

Misalignment creates hidden gaps between what the business expects and what IT can deliver. When a disruption occurs, these gaps often result in surprises, delays, and business impacts.

How can organizations close the gaps in recovery objectives between IT and the business units?

Closing these gaps requires structured, ongoing conversations between IT, BC, and the business units. Organizations must validate business requirements, understand IT capabilities, and work through trade-offs to arrive at recovery objectives that are both realistic and aligned.

What are some important areas that have a tendency to get overlooked when organizations are addressing the gaps in their recovery objectives?

Commonly overlooked areas include data loss implications (RPOs), the difference between day-to-day availability and disaster recovery, reliance on cloud and third-party providers, and the need for practical workarounds when gaps cannot be closed immediately.