TL;DR: Enterprises are split between comprehensive and staged recovery strategies, yet 54% lack confidence they can recover from a major disruption or cyberattack and only 46% feel very confident, according to Commvault and GigaOm research. The core problem is that recovery planning remains technology-led when business continuity demands business-first prioritisation.
At a glance
What this is: This research argues that most enterprise recovery programmes remain technology-led, and that a minimum viable recovery model reframes resilience around business-critical functions and measurable restoration priorities.
Why it matters: For IAM and security practitioners, the lesson is that recovery governance must account for identity, access, and operational dependencies that determine whether a business can actually resume.
By the numbers:
- 54% of enterprises lack confidence in their ability to recover from a major disruption or cyberattack.
- Only 46% of enterprises feel very confident they could recover to full business operations after a major disruption.
- 96% of organisations surveyed support the minimum viable recovery approach.
- 44% of organisations use comprehensive recovery approaches, while 56% use staged or tiered approaches.
Context
Recovery planning fails when enterprises treat infrastructure restoration as the goal instead of business continuity. The article argues that most programmes are still organised around technical completeness, even though recovery is only meaningful when core business functions come back in the right order.
The identity governance angle is practical: recovery depends on knowing which access paths, privileged accounts, service accounts, and supporting controls are required for minimum business operations. Without that mapping, the organisation can restore systems and still remain unable to operate.
That is why the article's minimum viable recovery model matters to IAM, PAM, and NHI teams as much as to infrastructure leaders. A recovery plan that ignores identity dependencies can be technically successful and operationally useless.
Key questions
Q: What breaks when recovery planning is technology-led instead of business-led?
A: Technology-led recovery often restores the wrong things first. Teams may bring systems back in a technically correct order while missing the identities, access paths, and business functions needed to operate. The result is a recovered environment that still cannot support revenue, customer service, or core operations.
Q: Why do enterprises with strong resilience spend still lack recovery confidence?
A: Because spending on infrastructure does not fix prioritisation. If recovery plans are built around system uptime, downtime, or technical ownership rather than business capability, the organisation can invest heavily and still fail to restore the processes that matter most after a major incident.
Q: How do security teams know whether minimum viable recovery is actually working?
A: They should measure whether the organisation can restore its most critical services in the right order, with the right access, within tested service-level targets. If the team can only describe the plan but cannot execute it with valid permissions, clean infrastructure, and repeatable procedures, readiness is still theoretical.
Q: What should IAM teams do differently in recovery planning?
A: IAM teams should treat authentication and authorisation as recovery dependencies, not as separate control areas. That means identifying which accounts, secrets, and privileged pathways are required for first-wave recovery, and validating that they can be restored or reissued when the business needs them.
Technical breakdown
Why technology-led recovery plans break under business change
Technology-led recovery assumes that restoring systems in a predetermined sequence will restore the business. In practice, application dependencies, identity dependencies, and business priorities change faster than recovery runbooks do. That creates a governance gap: the plan may still be valid in technical terms while being wrong for current operations. Minimum viable recovery shifts the unit of planning from whole-system restoration to the smallest set of business capabilities that must return first. That requires mapping services, identities, and dependencies to business outcomes rather than to infrastructure ownership. Practical implication: recovery architecture must be prioritised by business function, not by platform inventory.
Practical implication: Map recovery dependencies to business-critical functions before the next change cycle invalidates your recovery order.
How minimum viable recovery changes identity and access planning
Recovery is not just about data, compute, and backups. It also depends on which identities can authenticate, which privileged paths are available, and which service accounts or secrets are needed to restart core processes. If those identities are missing, expired, or overcomplicated to restore, the business cannot resume even if the systems are technically online. Minimum viable recovery therefore turns identity governance into a continuity control. It forces teams to identify which accounts, tokens, and access relationships are essential to the first hours of recovery. Practical implication: recovery runbooks should include identity restoration dependencies, not just infrastructure tasks.
Practical implication: Add privileged access, service accounts, and secrets to recovery scope so access restoration is tested with the rest of the plan.
Why measurable recovery needs business-first metrics
The article shows how easy it is for recovery programmes to overvalue technical metrics such as downtime or time to resolution. Those measures matter, but they do not tell leaders whether the organisation can resume revenue-generating, customer-facing, or operationally essential work. Minimum viable recovery replaces that ambiguity with measurable business response thresholds. The focus becomes whether the minimum set of services needed for operations can be restored within an acceptable window. That makes recovery readiness auditable in business terms instead of only in infrastructure terms. Practical implication: define recovery success using business capability thresholds, then back-map the technical controls that support them.
Practical implication: Use business capability thresholds as recovery test criteria instead of relying only on uptime and ticket closure metrics.
NHI Mgmt Group analysis
Minimum viable recovery is really identity-enabled continuity planning: Recovery only works when the organisation knows which identities, access paths, and supporting services must return first. That is not a backup problem or a platform problem alone. It is a governance problem about what the business must be able to authenticate, authorise, and run before anything else can be considered recovered.
The recovery gap is a prioritisation failure, not a tooling failure: The research shows enterprises already spend on resilience, yet confidence remains low because restoration sequences are still organised around technical convenience. Business continuity collapses when security systems, operations tooling, and revenue dependencies are restored ahead of the functions that keep the organisation operating. Practitioners should treat that mismatch as a control design issue, not a budget issue.
Recovery readiness now depends on lifecycle discipline across humans, NHI, and services: Joiner-mover-leaver assumptions, privileged access ownership, and service account dependencies all shape whether recovery can happen cleanly after an incident. If those lifecycles are not mapped into recovery design, the organisation may pass technical tests and still fail operational recovery. The implication is that resilience programmes must govern identity state as part of recovery state.
Minimum viable recovery exposes a new governance concept: recovery blast radius: The real question is not whether every system can be restored, but how much of the business can be safely brought back with the identities, access, and dependencies that are already validated. That shifts resilience thinking from completeness to controllable scope. Practitioners should use that concept to redesign recovery priorities around operational survival, not technical perfection.
Technical completeness is no longer a credible recovery objective: The article makes clear that staged and comprehensive recovery approaches both fail when they are not anchored to business value. Modern enterprises change too quickly for fixed restoration hierarchies to remain reliable. Governance teams should therefore treat recovery as a living identity and dependency problem, not a static infrastructure checklist.
What this signals
Recovery programmes must now be designed around business survivability, not restoration theatre: If a plan can bring services online but cannot restore the identities and access paths that core teams need, it is not a recovery plan. It is an infrastructure exercise with a continuity label attached.
Minimum viable recovery should become a governance pattern for identity-heavy enterprises: The more business processes depend on privileged access, service identities, and interlocking platforms, the less useful static recovery sequencing becomes. Practitioners need living dependency maps that change when the business changes, not just after an incident.
Recovery readiness is increasingly an access problem disguised as an operations problem: Organisations that fail to model identity restoration alongside system restoration will keep discovering the gap only after an outage or attack. The practical shift is to treat privileged access, service account recovery, and business continuity as one programme.
For practitioners
- Define minimum viable business services Identify the smallest set of customer-facing, revenue-producing, and operational functions that must return first after a disruption, then map every supporting system and identity dependency to that set.
- Inventory recovery-critical identities Document which privileged users, service accounts, secrets, and access paths are required to restart core business processes, then test whether they can be restored under incident conditions.
- Replace technical restoration metrics Measure recovery against business capability thresholds such as order processing, payment flow, or customer support continuity rather than relying mainly on downtime and time-to-resolution.
- Test recovery after major changes Revalidate the recovery sequence whenever the business pivots, applications are upgraded, or identity dependencies change, because stale recovery ordering quickly becomes misleading.
Key takeaways
- The research shows that many enterprises still plan recovery around systems, even though business continuity depends on restoring the right functions and identities first.
- The confidence gap is large enough to matter operationally, with recovery expectations lagging behind the complexity of modern enterprise environments.
- Minimum viable recovery reframes resilience as a business-led discipline, where identity and access dependencies are part of the recovery objective, not an afterthought.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan Execution | The article is about recovery planning and how organisations restore business operations after disruption. |
| GV.OC-01 — Organisational Context | Minimum viable recovery depends on knowing which business capabilities matter most to the organisation. | |
| Recommendation — Align recovery exercises to RC.RP-01 and verify that business-critical functions restore in the right order. Define recovery priorities from organisational context before mapping technical restoration steps. | ||
| NIST SP 800-53 Rev 5 | CP-2 — Contingency Plan | The article focuses on contingency planning and recovery sequencing for business operations. |
| Recommendation — Update contingency plans so recovery steps reflect business-critical dependencies, not only infrastructure ownership. | ||
| CIS Controls v8 | CIS-11 — Data Recovery | Recovery assurance is central to the article's message about closing the recovery gap. |
| Recommendation — Test data and service recovery together so contingency capability matches business continuity needs. | ||
| NIST Zero Trust (SP 800-207) | Principle 5: Assume breach — Assume breach | The article assumes disruptive events will occur and recovery must be ready to respond. |
| Recommendation — Design recovery paths that assume disruption has already happened and validate restoration under that condition. | ||
Key terms
- Minimum Viable Recovery: The minimum recovery state required for an organisation to keep critical business functions operating after an attack. It is not full restoration. It is the smallest trusted operating condition that lets the business continue while other systems recover in stages.
- Recoverability Gap: The recoverability gap is the difference between the state an organisation believes it can restore and the full operating state actually needed to resume service. It often appears when data backup is mature but configuration, identity, and integration recovery remain incomplete or undocumented.
- 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.
- Recovery Blast Radius: The set of systems and data that become exposed when backup, restore, or crisis tooling is over-privileged or too tightly coupled to production identity. A larger blast radius means a resilience tool can itself become part of the incident.
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.
Published by the NHIMG editorial team on July 9, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org