ResOps shows resilience fails when security and business stay siloed

At a glance

What this is: This is an independent analysis of IDC’s ResOps framing, which says the biggest resilience failures come from organisational silos rather than technical ones.

Why it matters: It matters because IAM, NHI, PAM, and broader security teams all depend on clear recovery authority, shared priorities, and tested governance when incidents cut across identities, infrastructure, and operations.

👉 Read Commvault's analysis of ResOps and cyber resilience governance

Context

Cyber resilience often fails at the handoff points between teams, not in the technology stack itself. In practice, recovery decisions are slowed when security, infrastructure, business, legal, and communications teams have never aligned on what must be restored first, who can approve exceptions, and how much risk is acceptable. That governance gap becomes more visible as attacks move faster and cut across multiple domains at once.

For identity and access programmes, the same pattern applies to privileged recovery, emergency access, and service continuity. If teams do not agree in advance how elevated access is granted, who can override controls, and how non-human identities are handled during disruption, response efforts become inconsistent. The article’s central point is that resilience is operational coordination, not a standalone technology layer.

Key questions

Q: What breaks when cyber resilience planning stays inside separate teams?

A: Recovery slows when security, infrastructure, legal, communications, and business leaders each optimise for different outcomes without a shared decision model. The biggest failure is not technical unavailability alone, but uncertainty about who can prioritise restoration, approve exceptions, and accept risk. That uncertainty turns an incident into a coordination problem and extends impact even when tooling is available.

Q: Why do identity and privileged access controls matter in resilience planning?

A: Because recovery depends on who can approve failover, access critical systems, and execute restoration when the normal operating model is disrupted. If IAM and PAM controls are not included in resilience design, the organisation may have technically recoverable systems but no authorised path to bring them back online.

Q: How do organisations know whether resilience controls are actually working?

A: They know by testing under failure conditions, not by checking configuration alone. A resilience control is working if the team can still reach critical credentials, restore service, and complete remediation when the main environment is down. If the process only works when production is healthy, it is availability theatre rather than resilience.

Q: Who is accountable when recovery decisions affect customers, operations, and compliance at the same time?

A: Accountability should sit with the governance structure that pre-defines recovery authority, not with whichever team is most visible during the incident. In practice, that means leadership must assign decision rights for prioritisation, exception approval, and reporting before an event occurs. Frameworks that emphasise control ownership and operational resilience reinforce that approach.

Technical breakdown

Why organisational silos slow cyber recovery

Cyber incidents rarely stay inside one domain. A ransomware event can affect identities, cloud workloads, backup systems, customer applications, and reporting obligations in parallel, which means recovery requires several teams to act in sequence. The technical problem is not only downtime but decision latency: each group has different objectives, tooling, and approval paths. Without a pre-agreed operating model, teams spend the incident negotiating what to do next. That is why resilience planning must map authority, dependencies, and escalation paths before the attack, not during it.

Practical implication: document cross-functional recovery ownership and decision rights before an incident forces improvisation.

Minimum viable business and recovery prioritisation

Minimum viable business, or MVB, is the set of capabilities that must keep operating when everything else stops. The concept shifts resilience from asset-centric thinking to outcome-centric thinking. Instead of restoring systems in the order teams argue for in the moment, organisations agree in advance which services, data flows, and dependencies support the most critical business functions. That shared definition creates a stable basis for recovery sequencing, exception handling, and risk acceptance. It also gives security teams clearer criteria for where to concentrate protection during disruption.

Practical implication: align restoration runbooks to business capabilities, not application ownership.

What automation can and cannot solve in resilience operations

Automation can accelerate failover, restore systems, and preserve evidence, but it cannot resolve competing priorities or assign accountability. Resilience operations fail when organisations assume tooling can replace governance. In reality, the most difficult questions are organisational: which services resume first, what risk is tolerable, and who can authorise exceptions under pressure. That makes ResOps a coordination discipline as much as a technical one. The stronger the recovery automation, the more important it is to define the rules that govern its use.

Practical implication: pair recovery automation with explicit governance triggers and approval authority.

NHI Mgmt Group analysis

Shared recovery authority is now a core resilience control. The article’s central contribution is that recovery fails when no one has pre-agreed authority over prioritisation, exceptions, and risk acceptance. That makes resilience a governance problem before it is a tooling problem. For identity-led programmes, the same issue appears in emergency access and privileged recovery paths. Practitioners should treat recovery authority as part of operational control design.

Minimum viable business is a useful way to convert business intent into recovery order. The value of MVB is not the label itself but the discipline of forcing business and technical teams to agree on what must remain available. That reduces argument during crisis and turns abstract resilience goals into specific dependencies. Where identity, access, and service continuity intersect, MVB can expose which non-human identities and privileged workflows are truly critical. Practitioners should use it to define restoration precedence, not as a reporting exercise.

ResOps exposes the limits of control thinking that stops at the platform boundary. Many programmes still assume resilience can be delivered by separate teams optimising their own tools. The article argues the opposite: resilience is produced by connected silos, not eliminated silos. That is a useful framing for IAM and PAM teams, because privileged access recovery, service-account continuity, and emergency delegation all require cross-domain choreography. Practitioners should align identity controls with operational recovery governance.

The governance gap is the real attack surface in recovery. Cyberattacks now compress timelines, which means the most exploitable weakness is often uncertainty about who decides what happens next. That uncertainty can delay containment, restoration, and reporting even when technical systems are available. In identity terms, the same gap appears when organisations have no tested process for emergency access or non-human identity continuity during disruption. Practitioners should design for decision speed as deliberately as they design for technical failover.

Resilience operations should be measured by coordination quality, not just restoration speed. The field has over-indexed on recovery time objectives while under-measuring whether people can execute the recovery plan under stress. This article suggests the better indicator is whether teams share the same priorities before the incident begins. For identity security programmes, that means validating whether emergency access, service continuity, and offboarding exceptions are governed through a rehearsed operating model. Practitioners should test the process, not only the platform.

What this signals

ResOps is a useful reminder that resilience programmes fail when they are treated as a tool selection exercise instead of an operating model question. For identity leaders, the same lesson applies to emergency access, privileged recovery, and service continuity. The more cross-domain the incident becomes, the more the programme depends on clear authority and rehearsed decision paths rather than platform features.

Recovery latency is the hidden control gap: if teams cannot agree quickly on restoration order and acceptable exceptions, the incident lasts longer even when the infrastructure is technically recoverable. That makes decision speed a governance metric worth tracking alongside recovery time objectives. Identity programmes should specifically test whether emergency access and service-account handling remain coherent under pressure.

For practitioners

• Define recovery decision rights Assign who can approve service restoration order, risk exceptions, and emergency access when an incident crosses security, infrastructure, and business functions. Include named backups and escalation rules so recovery does not depend on ad hoc consensus.
• Build a minimum viable business map Translate critical business outcomes into the applications, identities, data flows, and privileged access paths required to keep them operating. Use that map to set restoration precedence and to identify which non-human identities must remain available during disruption.
• Test cross-functional recovery drills Run scenarios that force security, IT, legal, communications, and business owners to make live prioritisation decisions under time pressure. Measure whether teams can agree on acceptable risk, service sequencing, and reporting obligations without waiting for escalation.
• Align identity recovery with resilience plans Document how emergency access, privileged accounts, and service accounts are handled if the primary response team is unavailable. Tie those procedures to recovery runbooks so identity governance remains intact during failover and restore activities.
• Measure coordination latency Track how long it takes to identify the decision-maker, validate the recovery priority, and execute the first exception during an incident simulation. That timing is often more revealing than raw restoration metrics because it exposes governance friction before a real event does.

Key takeaways

• The article shows that resilience often breaks at the organisational boundary, not the server boundary.
• Shared recovery authority and business-defined prioritisation are the controls that turn recovery from guesswork into a repeatable process.
• Identity teams should treat emergency access and service continuity as part of resilience governance, not as separate operational concerns.

Key terms

• 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.
• 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.
• 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.

What's in the full article

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

• How ResOps defines minimum viable business and turns it into recovery prioritisation guidance
• The cross-functional decision model for security, infrastructure, legal, and business leaders during an incident
• The article's explanation of why technology automation cannot replace governance and shared accountability
• The full resilience framing used by Commvault Field CTO Vidya Shankaran

👉 The full Commvault article expands on MVB planning, cross-functional alignment, and operational recovery.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader operational resilience and access governance decisions their programmes depend on.