ResOps shows why resilience must become an operating model

At a glance

What this is: Commvault argues that resilience should be run as an operating model, not assembled from separate recovery tools, and links that shift to cross-functional governance, executive sponsorship, and continuous operating discipline.

Why it matters: IAM, NHI, and security leaders need this lens because resilience failures often come from ownership gaps, disconnected lifecycle controls, and recovery assumptions that collapse when identity and access dependencies span teams.

Context

ResOps is a shorthand for resilience operations, meaning the operating model that coordinates recovery, security, and delivery work across the organisation. The article argues that the old pattern of treating backup, disaster recovery, cyber resilience, and business continuity as separate efforts no longer matches the operational reality facing identity security and adjacent teams.

The governance gap is not a lack of tools alone. It is the absence of a shared model that keeps people, processes, and technology aligned when incidents, cloud complexity, and AI-driven threat pressure all hit at once. For IAM practitioners, that means resilience has to be managed as part of lifecycle governance, ownership, and operating accountability, not as an afterthought.

The article’s starting position is typical: many enterprises still bolt new controls onto old recovery practices instead of redesigning the operating model around today’s disruption profile.

Key questions

Q: What is the first step in building a resilience operations model?

A: Start by defining the business outcome resilience must achieve, then translate that into KPIs, SLAs, and ownership. If teams choose technology before they agree on the operating target, they usually recreate the same fragmentation in a newer toolset. Executive sponsorship is what turns that outcome into enforceable accountability.

Q: Why do separate recovery tools often fail in practice?

A: Separate tools fail because recovery is a chain, not a product category. If teams split backup, cyber resilience, and business continuity across different owners and policies, the handoffs become the failure point. The result is slower restoration, unclear escalation, and gaps that only appear when multiple disruptions happen together.

Q: What are the signs that resilience is too dependent on individual experts?

A: Look for recovery steps that only one or two people can explain, incident decisions that are not written down, and repeated pauses while teams wait for a known expert. Those are signs that the organisation has hero knowledge instead of durable process, which means resilience is not yet scalable.

Q: Should organisations prioritise governance or new resilience technology first?

A: Governance should come first, because new technology cannot fix an undefined operating model. Organisations need agreement on who owns resilience, what outcomes matter, and how performance will be measured before selecting tools. Without that, technology becomes another silo instead of the mechanism that connects recovery work.

Technical breakdown

Why separate recovery tools create resilience gaps

When backup, disaster recovery, cyber resilience, and business continuity are managed as separate programmes, each one optimises for its own scope and tooling. That leaves handoffs, dependencies, and ownership boundaries under-defined, which is where recovery slows or fails. ResOps is essentially a control-plane view of resilience: it tries to align decision rights, processes, and telemetry across ITOps, SecOps, and DevOps so that disruption can be managed as one operating problem rather than four disconnected ones.

Practical implication: map the recovery handoffs that exist between teams and identify where no single owner can execute end-to-end restoration.

How hero-based resilience fails to scale

Hero worship in resilience is what happens when critical operational knowledge lives in the heads of a few experts instead of in documented, repeatable processes. That model can work during limited incidents, but it collapses when staff change, responsibilities shift, or multiple events happen at once. In identity terms, it creates hidden dependency on named individuals rather than governed roles, which is the opposite of resilient control design.

Practical implication: replace person-dependent recovery knowledge with documented runbooks, ownership maps, and tested escalation paths.

Why executive sponsorship changes resilience governance

The article makes a clear governance point: resilience becomes durable when the CEO and senior leadership treat it as a business outcome, not a technical add-on. That matters because resilience decisions often involve prioritisation across systems, teams, and risk appetite, which cannot be settled inside a single function. Under a ResOps model, accountability is explicit, cross-functional, and tied to agreed KPIs, SLAs, and recovery expectations rather than informal coordination.

Practical implication: define resilience objectives at the executive level and force them into measurable service and recovery commitments.

Threat narrative

Attacker objective: The objective is to create enough operational disruption that fragmented resilience controls cannot restore business services cleanly or quickly.

1. Entry begins when cyberattacks, cloud complexity, or AI-enabled threats create the operational disruption that exposes weak recovery coordination.
2. Escalation occurs when separate teams, tools, and policies cannot converge quickly enough to restore services or maintain business continuity.
3. Impact is delayed recovery, inconsistent response, and a resilience programme that cannot keep pace with systemic disruption.

Breaches seen in the wild

• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

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 is now an identity governance problem as much as an operations problem. Once recovery depends on coordinated access, ownership, and decision-making across ITOps, SecOps, and DevOps, the control gap is no longer only technical. The real failure mode is fragmented accountability, where no function can prove it owns the full restoration path. Practitioners should treat resilience as a governed operating model with identity-style accountability across roles and handoffs.

Hero-based resilience creates a hidden single point of failure. When only a few people know how systems recover, the programme depends on undocumented access to knowledge rather than durable process. That is a governance weakness, not a staffing issue, because resilience cannot be audited or recertified when it lives in memory. The implication is that recovery maturity should be measured by whether the organisation can execute without key individuals present.

ResOps is a named concept for the resilience operating model gap. It captures the move from isolated recovery tooling to continuous operational discipline that spans people, processes, and technology. That framing matters because the market has spent years adding capabilities to old structures instead of redesigning ownership, prioritisation, and coordination. Practitioners should read ResOps as a governance shift, not a product category.

AI pressure makes resilience governance less optional, not more technical. The article ties AI-enabled threats and AI-related rollout concerns to rising operational disruption, which means the resilience conversation now intersects with change governance and risk acceptance. The lesson is not that AI creates a new recovery tool requirement; it is that the organisation needs a model capable of absorbing faster-moving disruption. Teams should prepare for resilience planning to be judged as an operating discipline under AI-era conditions.

What this signals

ResOps changes the resilience question from “what tool do we buy?” to “how do we operate recovery across functions?” That shift matters for IAM and NHI programmes because the same ownership gaps that break access governance also break restoration governance. Teams should expect resilience to be assessed alongside lifecycle accountability, not only alongside technical recovery.

The operating model matters more than the incident class. Whether the disruption comes from ransomware, cloud complexity, or AI-enabled attack pressure, fragmented teams create the same governance failure: nobody owns the full path back to service. Practitioners should look for cross-functional recovery design that survives personnel change and scaling.

Recovery maturity will increasingly be judged by coordination quality. Organisations that can document ownership, decision rights, and restoration dependencies will have a clearer path to repeatable resilience than organisations that rely on informal heroics. That makes resilience an enterprise control objective, not a narrow infrastructure task.

For practitioners

• Define resilience as a business outcome Set explicit resilience objectives, KPIs, SLAs, and recovery expectations before choosing tools or reorganising teams.
• Build cross-functional ownership Create a standing team that brings together IT operations, security operations, DevOps, and business leaders with named decision rights.
• Replace hero knowledge with documented runbooks Capture restoration steps, dependencies, and escalation paths in tested procedures so recovery does not depend on individual memory.
• Test resilience as a continuous discipline Run regular exercises that validate whether governance, process, and technical controls still work together under disruption.

Key takeaways

• ResOps treats resilience as an operating model because fragmented tools and isolated teams leave recovery gaps that only appear under real disruption.
• The article’s core evidence is organisational rather than numerical: hero expertise, siloed planning, and tool-first thinking all weaken recovery at scale.
• For practitioners, the practical shift is to define ownership, align KPIs and SLAs, and make resilience a governed cross-functional discipline.

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.
• 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.
• Hero knowledge: Hero knowledge is critical operational expertise that exists mainly in the heads of a few individuals rather than in documented processes. It creates a hidden dependency that can slow recovery, weaken auditability, and fail when people leave or responsibilities change.
• Recovery operating model: A recovery operating model is the structure that defines who owns restoration, how teams coordinate, and how success is measured during disruption. It matters because resilience breaks down when recovery is treated as a set of separate tasks instead of a governed system.

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.