Minimum viable recovery exposes the enterprise recovery gap

At a glance

What this is: This is Commvault’s analysis of recovery planning research showing that most enterprises still struggle to translate resilience spending into confidence, and that minimum viable recovery shifts the model toward business-led prioritisation.

Why it matters: It matters because IAM, NHI, PAM, and infrastructure teams all depend on recovery order, access restoration, and operational dependencies that fail when business-critical identity and system priorities are not explicit.

By the numbers:

• 54% of enterprises lack confidence in their ability to recover from a major disruption or cyberattack.
• 96% of organizations surveyed support minimum viable recovery.
• 92% of comprehensive approach adopters can recover to minimum viability in under a week.
• 51% of organizations identify clear processes and roles as the highest priority for recovery readiness.

👉 Read Commvault’s research on minimum viable recovery and the recovery gap

Context

Recovery programmes often fail because they optimise for restoring systems, not restoring the business capabilities those systems support. In identity-heavy environments, that gap shows up quickly: access restoration, service account recovery, and privilege sequencing all depend on knowing which functions matter first.

The article argues for minimum viable recovery, a business-led approach that begins with the smallest set of functions required to operate and maps those functions to the supporting technology stack. That framing is useful for IAM teams because recovery order is also an identity-governance decision, especially where privileged access, workload credentials, and access dependencies must come back in a controlled sequence.

The recovery gap described here is typical of organisations that have invested in infrastructure and tooling without aligning recovery objectives to operating priorities. The methodology is not a niche resilience exercise; it is a governance reset for how enterprises decide what must be restored first.

Key questions

Q: How should security teams build a recovery plan around business-critical services?

A: Start by identifying the minimum set of business services that must return first, then map those services to the systems, identities, and dependencies that support them. Recovery planning should follow business value, not infrastructure convenience, so access restoration and service sequencing reflect operational priority rather than technical habit.

Q: Why do recovery programmes fail even after heavy resilience spending?

A: They often measure technical restoration while ignoring whether the organisation can resume critical operations. When plans are built around system completeness or fixed sequences, they miss dependency shifts, business priorities, and the identities that actually control access to restored services. Confidence drops because the recovery model does not match the business model.

Q: What breaks when recovery priorities are based on technical metrics alone?

A: Teams restore what is easiest to see, not what is most important to the business. That can leave revenue systems, customer workflows, or privileged access paths delayed while lower-value technical components come back first. The result is partial recovery that looks active but does not restore real operating capacity.

Q: Who should own recovery sequencing for identities and services?

A: Recovery sequencing should be owned jointly by security, infrastructure, and business stakeholders, with clear decision rights defined before an incident. Identity restoration, especially for privileged and operational accounts, needs named accountability so access comes back in the right order and with the right constraints.

Technical breakdown

Why technology-led recovery plans break down

Technology-led recovery plans start from systems, infrastructure, and tooling rather than from the business services those assets enable. That creates a mismatch between operational recovery and organisational value, especially when dependencies span identity, application, data, and security layers. Comprehensive recovery tries to restore everything, while staged recovery relies on a fixed sequence that may no longer match current business conditions. The result is planning that measures technical movement but not business continuity. In practice, this is why organisations can spend heavily on resilience and still lack confidence in recovery outcomes.

Practical implication: map recovery objectives to business services first, then assign identity and system restoration order to those services.

What minimum viable recovery changes in identity and access planning

Minimum viable recovery is a prioritisation model, not a pure technology tactic. It defines the smallest viable operating state by identifying the business functions that must return first, then linking them to the supporting identities, systems, and interdependencies. For IAM and NHI teams, that means recovery is not just about availability. It is about which accounts, tokens, roles, and privileged paths must be re-enabled first, which can remain delayed, and which should be quarantined until the operating baseline is stable. That is a governance decision with operational consequences.

Practical implication: classify identities by recovery criticality so the first restored access matches the first restored business capability.

Why recovery readiness depends on roles and process clarity

The research highlights that recovery fails when teams do not know who owns which decisions, approvals, and execution steps under pressure. Clear roles matter because recovery workflows require coordination across security, infrastructure, application, and business owners. In identity terms, this is the same problem seen in access governance: if ownership is unclear, controls become slow, inconsistent, or bypassed. Automation can help, but it cannot substitute for a recovery model that assigns accountable decision points and explicit restoration criteria before an incident occurs.

Practical implication: pre-assign recovery ownership for access, privilege, and service restoration before an incident forces improvisation.

Threat narrative

Attacker objective: The objective is to maximise operational disruption and extend recovery time until the organisation loses confidence in its ability to restore core services.

1. Entry occurs through a major disruption or cyberattack that interrupts normal business operations and exposes recovery dependencies that were never fully mapped.
2. Escalation happens when technical recovery sequences fail to restore critical access, services, and decision ownership in the order the business actually needs.
3. Impact is prolonged outage, slower restoration of revenue-bearing functions, and lower confidence in the organisation's ability to return to full operations.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Business-led recovery is now an identity governance problem, not just a resilience problem. Recovery order determines which identities, privileges, and service dependencies return first, so it cannot be separated from IAM and NHI governance. If the business cannot define what must come back first, the recovery programme will default to what is technically visible instead of what is operationally critical. Practitioners should treat recovery prioritisation as a control plane for access restoration.

Minimum viable recovery exposes the identity blast radius created by dependency sprawl. The more interconnected the environment, the harder it is to recover everything at once without overloading teams or restoring the wrong things first. This is where identity, application, and infrastructure dependencies collide. The concept gives practitioners a useful term for the problem: the recovery blast radius is the distance between technical restoration and business viability, and it must be actively constrained.

Recovery confidence is a governance outcome, not a tooling outcome. Organisations do not become more resilient simply by buying more recovery technology if their priorities remain technical rather than business-led. Clear roles, explicit service tiers, and pre-agreed restoration order matter more than broad promises of coverage. The practical conclusion is that recovery programmes should be judged by whether they can restore the right identities and services, not whether they can restore everything.

Static recovery runbooks age as quickly as the systems they describe. Change velocity makes fixed sequencing unreliable because application dependencies, cloud estates, and access models keep shifting. That is why business-led recovery has to be revisited as part of lifecycle governance, not filed away as a one-time resilience project. Practitioners should assume that recovery policy drifts unless it is reviewed alongside identity and infrastructure change.

Minimum viable recovery aligns resilience with PAM and privileged access sequencing. The same discipline used to govern high-risk access should apply when restoring administrative and operational control after disruption. If privileged access is restored too broadly or too early, recovery can create new risk while trying to reduce outage. Teams should use the recovery model to define which privileged paths are necessary, which are conditional, and which must stay closed until the environment stabilises.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• For a wider view of how identity failure patterns compound under pressure, see The 52 NHI breaches Report.

What this signals

Identity blast radius: recovery programmes increasingly fail where business restoration depends on access decisions that were never tiered by service criticality. With 19% of organisations giving AI systems dramatically more access than human employees, the broader pattern is clear, privilege is still being assigned faster than it can be governed.

Minimum viable recovery will force teams to connect resilience planning with identity governance, service ownership, and privileged access sequencing. That means recovery tiers, access tiers, and change-control tiers will need to line up, or the organisation will keep restoring the wrong things first.

Business-first recovery also changes how boards evaluate resilience: the question is no longer whether systems can be brought back, but whether the right business functions can be restored in the right order. That shift should push IAM, PAM, and infrastructure leaders into the same planning room.

For practitioners

• Define minimum viable business services first Identify the smallest set of business functions required to operate and map each one to its supporting applications, identities, and dependencies. Use that map to set recovery order before the next incident.
• Rank identities by recovery criticality Classify service accounts, administrator roles, and operational credentials by which business services they restore. Restore access in that sequence instead of following a generic infrastructure checklist.
• Pre-assign recovery decision ownership Assign explicit owners for access restoration, privilege approval, and service validation so recovery does not depend on ad hoc coordination during an outage. Clear accountability is part of the control design.
• Test recovery against business outcomes Run recovery exercises that measure whether revenue-bearing and customer-facing services return before lower-value systems. Use the results to revise restoration tiers and privilege sequencing.

Key takeaways

• The recovery gap is a governance failure as much as an operational one, because organisations still restore systems faster than they restore business capability.
• The strongest signal in the research is that recovery confidence remains low even where resilience spending is high, which means architecture alone is not closing the gap.
• Minimum viable recovery matters because it forces teams to define restoration order for identities, services, and privileges before an outage does it for them.

Key terms

• Minimum Viable Recovery: A recovery method that restores the smallest set of business functions needed to keep operating. It prioritises business viability first, then maps supporting systems, identities, and dependencies to that goal so recovery is fast enough to matter and controlled enough to avoid restoring the wrong things first.
• Recovery Gap: The distance between an organisation’s stated confidence in recovery and its actual ability to return to full operation after disruption. It often appears when planning is technology-led, dependencies are incomplete, or identity and business priorities are not aligned during restoration.
• Recovery Blast Radius: The amount of business and technical disruption created when recovery order is wrong or too broad. In practice, it describes how far a recovery failure spreads across services, identities, and decisions before the organisation reaches a stable operating state.
• Business-Critical Prioritisation: The discipline of deciding which services, identities, and processes must return first because they sustain core operations. It is a governance exercise, not a technical preference, and it becomes more important as systems, privileges, and workflows become more interconnected.

What's in the full report

Commvault's full research covers the operational detail this post intentionally leaves for the source:

• The full survey breakdown of how organisations split between comprehensive and staged recovery models.
• The methodology behind minimum viable recovery and how the research team translated it into a business-led framework.
• The underlying response data on recovery confidence, prioritisation, and organisational readiness.
• The practical comparison between technical recovery metrics and business-first restoration priorities.

👉 The full Commvault report explains the recovery model, survey findings, and business-priority framework in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.