ResOps shows why resilience must become an operating model

At a glance

What this is: This is a resilience operations article arguing that enterprises need an integrated ResOps operating model because fragmented recovery approaches no longer match today’s disruption pattern.

Why it matters: It matters to IAM, NHI, and security teams because resilience now depends on shared governance across identities, operational workflows, and recovery processes rather than isolated controls.

By the numbers:

• Only 44% of organisations are currently using a dedicated secrets management system.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Commvault's fireside chat on ResOps and enterprise resilience

Context

ResOps is a resilience operating model that brings people, process, and technology into one discipline instead of treating backup, recovery, security, and development as separate workstreams. The article argues that this shift is necessary because AI-enabled threats, cloud complexity, and continuous disruption have outgrown fragmented recovery planning.

For identity programmes, the lesson is broader than disaster recovery. When operational resilience is built around disconnected teams and undocumented expertise, identity recovery, credential governance, and access controls become brittle at exactly the moment they are most needed. That is a typical enterprise failure pattern, not an edge case.

Key questions

Q: How should security teams build resilience when identity, recovery, and operations are managed separately?

A: They should bring identity recovery, incident response, and operational restoration into one governed workflow with clear ownership, shared metrics, and tested handoffs. Separate plans usually fail at the seams, where access restoration, privilege decisions, and infrastructure recovery collide. The goal is not more tools, but a single operating model that can survive disruption without improvisation.

Q: Why does hero expertise create resilience risk in IAM and NHI programmes?

A: Because resilience cannot scale when critical steps live in one person's memory. IAM and NHI recovery need documented approvals, runbooks, and access paths so restoration still works when staff are unavailable, roles change, or the incident is larger than one operator can handle. Treat process documentation as a control, not paperwork.

Q: What breaks when resilience planning treats security and operations as separate disciplines?

A: Recovery slows because each team optimises its own priorities, tools, and escalation path. In practice, that creates gaps between access restoration, system restoration, and containment, which is where incidents become outages. Separate disciplines can collaborate, but they must share an operating model and common service targets if resilience is to be dependable.

Q: Who should be accountable for resilience operating models in identity-heavy environments?

A: Executive sponsorship matters because resilience spans business risk, infrastructure recovery, and identity governance. The CEO, CIO, CTO, CISO, and business leaders should define outcomes and priorities, while operational teams implement the playbooks. Without top-level accountability, resilience becomes a collection of local optimisations instead of a strategic discipline.

Technical breakdown

Why resilience fails when identity and operations stay siloed

Resilience breaks down when different teams own different pieces of the recovery chain, because each team optimises for its own tools, metrics, and escalation path. In identity-heavy environments, that means access restoration, secret rotation, and privileged recovery can drift apart from incident response and infrastructure recovery. The result is slower containment and unclear ownership when disruption hits. ResOps is trying to solve the coordination problem, not just the tooling problem. Practical implication: map identity recovery steps into the same operating model as SecOps and ITOps, with explicit handoffs and shared service targets.

Practical implication: map identity recovery steps into the same operating model as SecOps and ITOps, with explicit handoffs and shared service targets.

Why hero knowledge is a resilience liability

Hero worship appears when critical resilience knowledge lives in one person's head instead of in repeatable process. That works until the person is unavailable, leaves, or the incident requires action at scale. In identity governance, this is especially risky for emergency access, recovery credentials, and exception handling, because those areas often depend on informal tribal knowledge. A scalable programme documents decisions, not just procedures. Practical implication: convert recovery and identity exception handling into playbooks, approval paths, and tested runbooks that do not depend on a single operator.

Practical implication: convert recovery and identity exception handling into playbooks, approval paths, and tested runbooks that do not depend on a single operator.

How AI pressure changes resilience and access governance

AI changes resilience because it increases both the speed of threat activity and the volume of decision points defenders must manage. That creates more pressure on identity systems, especially where automated workflows, delegated access, and system-to-system permissions are already complex. Resilience therefore has to include governance over who or what can act during disruption, not just whether systems can be restored. Practical implication: align identity recovery and privilege control with zero trust architecture so emergency access remains bounded even under stress.

Practical implication: align identity recovery and privilege control with zero trust architecture so emergency access remains bounded even under stress.

NHI Mgmt Group analysis

Resilience operations exposes the governance gap between recovery capability and recovery accountability. The article shows that enterprises often have tools for backup, response, and continuity, but not a single operating model that binds them together. That is an identity problem as much as an infrastructure problem, because access, restoration, and authorisation all become unstable when ownership is fragmented. The practitioner conclusion is that resilience must be governed as a lifecycle, not assembled ad hoc after disruption.

Heroism is a control failure, not a cultural quirk. When a resilience programme depends on one expert who knows where the access paths, recovery steps, and exceptions live, the programme is already non-scalable. The article is right to warn against reliance on individual expertise, because undocumented identity recovery is indistinguishable from unmanaged privilege under stress. The practitioner conclusion is to treat documented process as a resilience control.

ResOps is the right lens for cross-domain identity governance because recovery, security, and operations now share the same failure surface. Identity teams cannot separate secret management, privileged recovery, and incident response from operational continuity anymore. The more cloud, AI, and automation expand the attack and recovery surface, the more important it becomes to govern identities through shared operating discipline. The practitioner conclusion is that resilience and identity governance should be planned together, not sequenced separately.

Zero trust assumptions weaken quickly when recovery paths are improvised. The article’s emphasis on assuming that something will go wrong is the right starting point, but resilience must still preserve bounded access under failure conditions. If emergency access, service restoration, and administrative override are handled outside governed workflows, the identity model expands at the exact moment it should contract. The practitioner conclusion is to make resilience itself a governed access pattern.

Identity recovery is becoming a first-class resilience requirement, not a back-end task. As cyberattacks, cloud complexity, and AI-enabled threats increase operational disruption, the question is no longer whether systems can be restored but whether identities can be restored safely and consistently. That makes recovery authority, privilege boundaries, and process ownership part of the resilience architecture. The practitioner conclusion is to put identity governance inside the resilience programme, not beside it.

From our research:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to The 2024 State of Secrets Management Survey.
• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management.
• For deeper operational context, see Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs for the lifecycle controls that resilience programmes often depend on.

What this signals

Identity resilience will increasingly be judged by whether recovery steps are governable, not just whether systems come back online. As disruption becomes continuous, teams will be expected to prove that access restoration, privileged override, and secret handling are documented, tested, and owned. The programme signal is simple: if recovery depends on one expert, it is not resilient.

With 88% of security professionals concerned about secrets sprawl in our 2024 survey, operational resilience and identity governance are converging around the same control failure. Fragmented recovery models cannot keep pace with sprawling credentials, especially when incident response and access management remain disconnected.

ResOps becomes a useful concept when it changes how teams budget, measure, and rehearse recovery. The practical shift is toward shared service targets across SecOps, ITOps, DevOps, and IAM, with zero trust assumptions applied to emergency access as well as normal operations. That makes resilience a repeatable governance discipline instead of a heroic event.

For practitioners

• Define resilience ownership across identity and operations Assign explicit ownership for identity recovery, privileged access, and incident handoffs within the resilience operating model so no step depends on informal coordination.
• Document recovery playbooks for access-critical systems Turn emergency access, secret rotation, and administrative override procedures into tested runbooks that can be executed without tribal knowledge or a single expert.
• Map resilience controls to zero trust boundaries Ensure emergency access stays time-bound, approved, and traceable even during disruption, with recovery workflows aligned to zero trust architecture and least privilege.
• Unify SecOps, ITOps, and IAM metrics Use shared service targets for restoration time, access restoration, and incident containment so resilience performance is measured across teams, not inside silos.

Key takeaways

• Fragmented resilience models fail because recovery, security, and operations are governed separately, even though incidents break across all three.
• Manual identity recovery is a material operational weakness, especially when secrets, privilege, and handoffs are not centrally governed.
• ResOps matters because resilience now has to be measured as a repeatable operating discipline, not as an improvised response after disruption.

Key terms

• Resilience Operations: An operating model that treats resilience as a continuous discipline rather than a separate project or tool set. It brings together recovery, security, and delivery teams so disruption response, identity recovery, and business continuity are planned and measured together.
• Hero Worship: A resilience failure mode where critical knowledge lives in one expert instead of being documented and repeatable. In identity and recovery programmes, it creates fragility because access decisions, exception handling, and restoration steps cannot scale beyond the individual.
• Operating Model: The structured way an organisation assigns ownership, process, metrics, and escalation across a capability. For resilience and identity governance, it determines whether recovery is ad hoc and local or coordinated, testable, and accountable across teams.

What's in the full article

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

• The CEO-level sponsorship model and how executive accountability is used to drive resilience priorities.
• The practical operating changes needed to unify ITOps, SecOps, and DevOps around one resilience workflow.
• The discussion of why isolated recovery tools and undocumented expert knowledge slow recovery at scale.
• The way AI-enabled threats are changing the assumptions behind resilience planning and business continuity.

👉 The full Commvault discussion covers the operating-model details behind resilience, recovery, and executive sponsorship.

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 or security programme, it is worth exploring.