A software provider recently described a familiar exchange between enterprise IT and executive leadership during a disruption:
IT: Systems are down. We are confident we can achieve the company’s Recovery Time Objective of eight hours.
CEO: I need it sooner. What can you do?
IT: We can achieve a Minimum Viable Organization in three hours.
CEO: Do it.
The exchange captures what happens when a carefully negotiated recovery target encounters an operating business. Recovery time objectives (RTOs) are established through business impact analysis, technical dependencies, risk tolerance and recovery cost. Leaders review the assumptions and agree on the maximum acceptable period that a service or process can remain unavailable.
That consensus can weaken when a ransomware attack, destructive technology failure, cloud outage or other material disruption stops the enterprise from operating. The CEO has moved beyond evaluating the logic behind an eight-hour target. The immediate question is when the organization can perform essential work again.
ISG Research asserts that by 2028, 35% of large enterprises will supplement service-level RTOs with a defined minimum viable operating state based on essential business outcomes.
The apparent moral is that the planning required to establish an RTO becomes moot when something bad happens. The more useful interpretation is that a single recovery target is insufficient.
RTO remains necessary. It defines when a service or process must be recovered following a disruption. It may not, however, identify the earliest point when the enterprise can safely resume its most essential activities. Application-level RTOs also can obscure shared dependencies across identity, data, communications, infrastructure, integrations and third-party services. Several systems can meet their individual recovery targets without producing an organization capable of operating.
A Minimum Viable Organization (MVO) plan addresses this gap. MVO adapts established business continuity and disaster recovery practices into an enterprise-wide operating state. It is the smallest trusted configuration of people, data, technology, authority, workflows and external dependencies required to sustain essential outcomes during a disruption.
The three-hour promise in the opening exchange therefore requires more than a shortened recovery schedule. IT must know which business outcomes will be available, which services will remain constrained and how long the organization can operate in that condition. It also must determine what data can be trusted, which identities and emergency permissions will be active and what additional risk executive leadership is authorizing.
Data resilience is central to this determination. An available backup does not make data ready for operational use. The enterprise must identify the minimum datasets needed for essential outcomes and establish acceptable recovery points, integrity requirements, provenance and synchronization order. Actions should remain constrained when restored data cannot yet be trusted. Recovery testing must validate representative business transactions rather than confirm only that storage and applications are online.
Without these decisions, MVO becomes an improvised promise made under pressure. That can accelerate technical activity while introducing inconsistent priorities, excessive access, incomplete data and unapproved business risk.
A credible MVO gives the enterprise two planned recovery milestones. The first restores essential operations within predefined constraints. The second achieves the established RTOs for designated services and processes. Full normalization continues as temporary controls are removed and remaining capabilities return.
The sequence should begin by stabilizing the incident and establishing command authority. Recovery teams then restore identity, communications and essential control capabilities, validate minimum viable data and activate critical workflows and dependencies. The organization declares MVO only after it completes defined business outcomes successfully. Recovery continues toward broader RTOs and normal service levels.
ISG’s Enterprise Control Architecture (ECA) framework provides the operational control layer for this transition. Governance defines essential outcomes, risk tolerance, recovery priorities and authority to operate in a constrained state. ECA translates those requirements into controls through identity and trust, observability and context, policy enforcement, runtime control and response and remediation. Execution technologies perform the permitted work through restored applications, infrastructure, APIs, workflows and data.
This approach also creates a measurable target: time to MVO. Supporting measures should include the percentage of essential outcomes executable, percentage of minimum viable data validated, unresolved critical dependencies, verified identities and maximum sustainable duration of the MVO state. These measures complement RTO and recovery point objective by determining whether the enterprise can operate instead of reporting individual technology components as recovered.
The executive exchange should ultimately become more precise:
IT: We can resume essential enterprise operations in three hours using validated data and predefined recovery controls. Some services will remain constrained until the eight-hour recovery target. The MVO state can operate safely for a defined period while full recovery continues.
Every enterprise should test that statement before its next disruption. If IT cannot activate a predefined operating state without improvising data priorities, access rights, dependencies or acceptable risk, the organization has recovery targets but no Minimum Viable Organization.
Regards,
Jeff Orr