TL;DR: IDC’s latest ResOps research argues that cyber resilience breaks down less because of technical fragmentation than because security, infrastructure, IT, and business teams do not share recovery decisions before an incident, according to Commvault. The practical lesson is that resilience depends on operating model alignment, not just faster tooling or better backup technology.
At a glance
What this is: Commvault argues that cyber resilience fails most often at the organisational boundary, where security, infrastructure, IT, and business teams have not aligned recovery decisions before an incident.
Why it matters: This matters to IAM and broader security practitioners because resilience depends on governance over decision rights, not just technical restore capability, especially when incidents span identities, cloud, applications, and business operations.
Context
Cyber resilience is not just a restore problem. It is a governance problem when different teams hold different assumptions about what must come back first, who can authorise trade-offs, and how much business risk is acceptable during recovery. In practice, that means technical readiness can still fail if identity, infrastructure, security, and business leaders have not aligned on decision rights before an incident.
This article sits at the intersection of cyber resilience, operating model design, and identity governance. The identity angle is indirect but real: modern attacks often begin with compromised identities and then move across infrastructure, applications, and third-party services, so recovery planning has to account for which privileged paths, services, and business functions are most critical to restore safely.
Key questions
Q: What breaks when security and business teams have not aligned recovery decisions?
A: Recovery breaks because restore order, risk tolerance, and authorisation remain unresolved until the incident is already under way. Teams then optimise for different outcomes, which creates delay, conflicting priorities, and slower service restoration. The failure is not the absence of tools, but the absence of a pre-agreed operating model for deciding what comes back first.
Q: Why does minimum viable business matter for cyber resilience?
A: Minimum viable business forces organisations to define the smallest set of capabilities that must continue operating during severe disruption. That makes resilience measurable in business outcomes rather than technical uptime alone. It also exposes hidden dependencies, so recovery can be sequenced around revenue, customer trust, and regulatory continuity instead of individual system preferences.
Q: How can teams tell whether a resilience council is working?
A: Look for measurable control changes, not just meeting outputs. A working council changes access policy, clarifies ownership for recovery paths, and closes specific operational gaps. If it only produces discussion, the governance signal is weak.
Q: Who should be accountable for resilience decisions in a cross-functional incident?
A: Accountability should sit with the leaders who own business continuity, operational recovery, and risk acceptance together, not with any single technical team. Security, infrastructure, IT, and business leaders each own part of the answer, but the organisation needs a shared authority model so the incident does not become a contest between functions.
Technical breakdown
Why recovery breaks at the organisational boundary
Resilience failures often come from unresolved decision ownership rather than missing backup capability. When security, IT, infrastructure, legal, and business teams each optimise for different outcomes, recovery becomes a negotiation inside the incident rather than a plan executed during it. The result is delay, conflicting priorities, and uncertainty about what to restore first. ResOps is essentially an operating model for making those decisions explicit before disruption forces them into the open.
Practical implication: Define recovery decision rights before an incident so restore sequencing is governed, not improvised.
Minimum viable business as a recovery control
Minimum viable business, or MVB, is the smallest set of capabilities the organisation must keep operating if everything else stops. It shifts resilience planning away from application-centric thinking and toward business outcomes, dependency mapping, and acceptable degradation. That matters because recovery should be driven by the services that preserve customer trust, revenue flow, and regulatory continuity, not by whichever system owner speaks loudest in a crisis.
Practical implication: Use MVB to rank recovery priorities across systems, services, and business functions before an outage happens.
Why automation cannot replace governance
Recovery tooling can accelerate restore tasks, but it cannot settle disagreements about business priority, acceptable risk, or cross-team authority. That is where many resilience programmes overestimate technology and underestimate governance. If the people involved have not already agreed on sequence, ownership, and escalation, automation only makes the wrong decision happen faster. The control problem is coordination, not speed alone.
Practical implication: Pair automation with pre-agreed governance so recovery orchestration follows business policy instead of ad hoc escalation.
Threat narrative
Attacker objective: The objective is to disrupt operations faster than the organisation can coordinate recovery, amplifying business impact and recovery delay.
- Entry can begin with compromised identities, then move through cloud infrastructure and critical workloads as the incident spreads across domains.
- Escalation happens when multiple teams have to react under pressure without a shared recovery model, turning coordination gaps into operational delays.
- Impact lands in disrupted customer services, slower restoration, regulatory exposure, and prolonged business interruption because no one has pre-agreed the recovery order.
Breaches seen in the wild
- Commvault Metallic breach 2025: A nation-state actor exploited a Commvault zero-day in Azure and may have taken app secrets that open customers' Microsoft 365 tenants.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Resilience governance fails when decision rights are distributed but never reconciled. The article shows that organisations often treat recovery as a technical workflow even though it is really a cross-functional authorisation problem. Security, infrastructure, IT, and business teams each own part of the outcome, but if they do not agree on authority before an incident, the recovery process becomes self-defeating. Practitioners should treat governance design as a resilience control, not a support function.
Minimum viable business is the right concept because it forces recovery to be measured in business continuity, not system availability. That is a more useful discipline than generic restore testing because it requires explicit decisions about which capabilities must survive, what dependencies matter, and what degradation is tolerable. For identity-led programmes, the same logic applies to privileged access, service accounts, and critical control planes that underpin business operations. Practitioners should map recovery priority to business capability, not infrastructure sentiment.
ResOps exposes a coordination gap that modern attack patterns keep widening. When incidents start with compromised identities and spread across cloud, applications, third parties, and compliance obligations, siloed response models break down quickly. The named concept here is the recovery alignment gap: the distance between having technical recovery tools and having a shared operating model for using them. Practitioners should close that gap before an attack turns it into outage time.
AI compression of attack timelines makes the old recovery playbook less defensible. If attacks move faster, the organisation has less time to resolve internal disagreement during the event. That increases the value of pre-agreed escalation, restore sequencing, and business prioritisation. The practical conclusion is that resilience programmes now need to be tested for decision latency, not just technical restore success.
Identity governance belongs in resilience planning because identity compromise is often the first move in a wider disruption chain. The article’s attack framing starts with compromised identities and then expands across systems. That means privileged access, authentication paths, and service identities are not separate from resilience, they are part of the recovery surface. Practitioners should connect identity control ownership to recovery ownership so the first compromised control does not become the last unresolved dependency.
From our research library:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to the State of Secrets in AppSec.
What this signals
Recovery alignment gap: many resilience programmes still assume that technical recovery and business recovery are the same thing, but the article shows they are separate control problems. The gap appears when teams know how to restore systems but have not agreed how to choose between competing restore paths. Practitioners should treat that gap as a measurable governance weakness, not a communications issue.
The resilience discussion is moving toward operating model design because attackers do not respect functional boundaries and neither do modern dependencies. When compromise starts in identity and spreads across cloud, applications, and third parties, the ability to coordinate matters as much as the ability to restore. That makes cross-functional recovery testing a core resilience control, not an optional exercise.
For practitioners
- Define recovery decision rights Document who can authorise application restore order, acceptable degradation, and business trade-offs before an incident begins. Make security, infrastructure, IT, legal, and business leaders sign off on the same escalation path.
- Build a minimum viable business model Map the small set of customer, revenue, and regulatory capabilities that must continue if major systems fail. Use that model to prioritise restore sequencing and to identify which services cannot be treated as equal during recovery.
- Test cross-functional recovery decisions Run exercises that force teams to choose between competing restore paths, data sets, and service priorities. Score the exercise on decision speed, ownership clarity, and whether the chosen order matched the agreed business outcomes.
- Align identity and recovery ownership Include privileged access, service identities, and critical control-plane access in resilience planning so the teams responsible for those controls are part of recovery governance. That prevents identity failure from being treated as an isolated security problem.
Key takeaways
- Cyber resilience fails when recovery authority is fragmented across teams that never agreed on priorities before an incident.
- The article’s core evidence is organisational, not technical: delays come from uncertainty about what to restore first and who can decide.
- Minimum viable business and cross-functional recovery exercises are the controls that convert resilience from theory into a repeatable operating model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RR-01 — Roles, Responsibilities, and Authorities | The article centres on who decides recovery actions across business and security teams. |
| RC.RP-01 — Recovery Plan Execution | ResOps is fundamentally about coordinating recovery execution under pressure. | |
| ID.RA-05 — Threat and Vulnerability Analysis | The article links incident spread and dependency complexity to recovery readiness. | |
| Recommendation — Define and rehearse recovery authorities so cross-functional teams can execute restoration without unresolved ownership. Test recovery plans against real decision scenarios so execution reflects agreed business priorities. Use dependency and disruption analysis to identify which services must be restored first. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The article describes attacks beginning with compromised identities and ending in operational disruption. |
| Recommendation — Map identity compromise and disruption pathways to recovery scenarios so exercises cover the full attack chain. | ||
| CIS Controls v8 | CIS-17 — Incident Response Management | Cross-functional recovery coordination aligns with incident response governance and testing. |
| Recommendation — Run coordinated incident exercises that force leadership to resolve business and technical recovery trade-offs. | ||
Key terms
- Minimum Viable Company: Minimum Viable Company is the smallest level of identity and application capacity needed for the business to operate after a recovery event. It shifts the recovery question from whether a system is online to whether enough trusted access exists for critical services to function.
- ResOps: ResOps is an operational discipline that combines security, infrastructure, and recovery work into one resilience model. It focuses on proving that critical services can be restored cleanly and safely, rather than assuming backup ownership or documented runbooks are enough to guarantee recoverability.
- Recovery Decision Rights: Recovery decision rights are the pre-assigned authorities that determine who can prioritise restoration, approve exceptions, and accept risk during an incident. They reduce delay and conflict by preventing teams from negotiating governance in the middle of a crisis.
- Operational Resilience: Operational resilience is the ability to keep critical services running or recover them quickly after disruption. In identity-led environments, that depends on authentication services, privilege management, and recovery procedures that can be tested under realistic failure conditions.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for security and identity practitioners who need to connect access governance to broader operational resilience.
Published by the NHIMG editorial team on August 11, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org