ResOps is shifting resilience from recovery metrics to business continuity

At a glance

What this is: This is an independent analysis of IDC’s Resilience Operations report, which argues that resilience is becoming a cross-functional discipline centred on business continuity rather than technical recovery milestones.

Why it matters: It matters to IAM and security practitioners because the same operating gaps that slow recovery also weaken identity, access, and governance decisions when attacks move faster than manual response can adapt.

By the numbers:

• The report is based on a survey of more than 500 North American organisations.

👉 Read Commvault’s analysis of IDC’s Resilience Operations report

Context

Cyber resilience is increasingly a governance problem as much as a technical one. If the enterprise cannot decide which services, identities, data sets, and processes must recover first, then backup and restoration work only after the business has already absorbed avoidable damage. The first-order issue in this article is resilience operations, with a growing identity angle where machine identities, agentic AI, and privileged access all influence restoration speed and trust boundaries.

The article’s core claim is that AI has shortened the interval between compromise and disruption, which makes manual recovery less reliable than it once was. That changes how practitioners think about minimum viable business planning, recovery sequencing, and the coordination between security, infrastructure, and business leaders. The starting position is increasingly typical across mature environments, not exceptional.

Key questions

Q: How should organisations define minimum viable business for resilience planning?

A: Start by identifying the smallest set of services, data, processes, and identities required to keep the business operating after disruption. Then rank dependencies by business impact, not by system ownership. The output should drive recovery order, validation priorities, and cross-functional decision-making before an incident occurs.

Q: Why do machine identities make cyber resilience harder?

A: Machine identities make resilience harder because their credentials are embedded in services, scripts, and automations that may fail silently during an incident. When those secrets are stored in a single control plane, a platform outage can block both business operations and recovery. The result is an identity dependency problem, not just a storage problem.

Q: What breaks when recovery remains a manual process?

A: Manual recovery creates delay, inconsistency, and decision bottlenecks when attackers or outages move faster than humans can coordinate. Teams spend time assembling steps, checking dependencies, and validating systems instead of restoring service. That increases recovery debt and widens the business impact window.

Q: Who should own resilience decisions when business, security, and IT priorities differ?

A: Ownership should sit in a shared operating model that aligns business continuity, security containment, infrastructure restoration, and compliance obligations. No single team can optimise resilience alone. The practical answer is joint governance with pre-agreed recovery thresholds, escalation paths, and validation criteria.

Technical breakdown

Minimum viable business planning and recovery prioritisation

Minimum viable business, or MVB, is the smallest set of functions, systems, processes, and data required to keep operating after a disruption. In practice, it is the answer to a harder question than RTO or backup success: what must come back first for the business to function? MVB planning forces organisations to rank services by business dependency, not by infrastructure ownership. That matters because recovery order often exposes hidden identity dependencies, such as directory services, privileged access pathways, SaaS sessions, API keys, and machine identities that other systems rely on.

Practical implication: map critical business services to their identity dependencies before an incident forces recovery decisions.

Automated recovery orchestration and validation

Modern attacks compress the time available to respond, which means recovery must move from manual execution to orchestrated workflows. Automated recovery orchestration coordinates clean recovery point selection, service restoration, configuration validation, and dependency checks across systems that were previously handled by separate teams. Validation is the control that proves the restored environment is safe to reintroduce, rather than merely available. Without automation, recovery debt accumulates because analysts spend time assembling steps while business impact continues to spread.

Practical implication: automate the recovery sequence for identity stores, privileged access paths, and critical workloads, then test it under load.

Why resilience now includes machine identities and AI systems

The article’s forward-looking point is that resilience planning can no longer assume a traditional server-and-database estate. Cloud services, SaaS applications, machine identities, third-party connections, and AI systems all participate in recovery and can also become failure points. Machine identities matter here because service accounts, tokens, and delegated access often persist across environments and may be needed to restore systems. If those identities are not governed, recovery can fail even when infrastructure is technically healthy.

Practical implication: include machine identity recovery and access validation in resilience testing, not just infrastructure failover.

NHI Mgmt Group analysis

Resilience operations is becoming an identity problem as much as an uptime problem. The article is right to move the discussion from recovery time to business continuity, because the systems that decide what comes back first increasingly depend on identity stores, privileged access, and service credentials. If those controls are unstable, the organisation may restore infrastructure but still be unable to operate. For IAM and PAM teams, resilience planning must now include access restoration order and trust revalidation.

Minimum viable business is the right organising concept, but it exposes hidden control dependencies. Defining the smallest workable set of services forces leaders to identify which identities, secrets, and delegated permissions the business cannot function without. That is valuable because recovery plans often fail at the point where teams discover an overlooked service account or SaaS trust relationship. Practitioners should treat MVB mapping as a governance exercise, not a documentation task.

AI compression changes the resilience baseline because manual recovery assumes time that no longer exists. The article’s strongest point is that attackers are automating faster than many organisations can restore. That creates a detection-response-latency problem, where the real gap is not only technical tooling but the ability to coordinate action before compromise cascades. In identity terms, standing privilege and slow revocation become recovery liabilities rather than just access risks.

ResOps is likely to push resilience governance toward measurable operational proof. IDC’s framing suggests that planning, tabletop exercises, and validated orchestration will matter more than policy statements. That aligns with broader governance trends in which security controls must be demonstrable under pressure. Practitioners should expect recovery evidence, access validation, and cross-functional ownership to become stronger board-level expectations.

Machine identity sprawl is now part of resilience scope, not a separate niche concern. As cloud services and AI systems become embedded in business continuity, identity lifecycle management extends into restore, failover, and revalidation workflows. That widens the governance surface for IAM teams and makes lifecycle discipline central to resilience rather than adjacent to it. The practical conclusion is clear: recovery plans that ignore NHIs are incomplete.

What this signals

Minimum viable business will become a practical identity dependency map, not a workshop artefact. As resilience programmes mature, leaders will need to know which identities, secrets, and delegated access paths are required to restore each critical service. The operational change is simple but profound: recovery planning and IAM governance will converge around the same dependency graph, and that will expose weak lifecycle control faster than annual reviews ever could.

Recovery automation will increasingly depend on governed non-human identities. If orchestration is going to validate systems, restart services, and confirm trust after disruption, the machine identities behind those actions must be tightly scoped and observable. That makes lifecycle controls, privileged access review, and secret management part of resilience engineering. The practical signal for practitioners is that the resilience backlog now includes identity hygiene.

For readers building maturity in this area, the next step is cross-functional proof. Organisations will be expected to demonstrate that business, security, infrastructure, and recovery teams can act on the same priorities under pressure. Tools matter, but the bigger test is whether the enterprise can prove restoration order, access validation, and continuity decisions without improvisation. That is where resilience starts to become measurable.

For practitioners

• Map recovery order to business-critical identity dependencies Identify which directory services, privileged access channels, service accounts, tokens, and SaaS trust relationships must be restored before each critical business service can operate. Use the minimum viable business exercise to test whether those dependencies are complete and current.
• Automate identity and workload recovery workflows Build orchestration for account restoration, secret revalidation, privileged access reissuance, and configuration checks so recovery does not depend on manual sequencing. Include identity stores and machine identity validation in the same runbook as application failover.
• Test resilience with tabletop and cyber-range exercises Run exercises that force business, security, infrastructure, and compliance teams to make recovery trade-offs under pressure. Measure whether teams can agree on access priorities, restoration sequence, and validation checkpoints before the incident ends.
• Include machine identities in resilience governance Inventory service accounts, API keys, certificates, and delegated application access that support recovery paths. Validate that these credentials can be rotated, reissued, or revoked without breaking the restoration of critical business functions.

Key takeaways

• Resilience is shifting from technical restoration metrics to business continuity, and that change pulls identity governance into the core of recovery planning.
• Nearly 6 in 10 organisations still have not fully defined their minimum viable business, which leaves recovery sequencing, access priorities, and dependency mapping exposed.
• Practitioners should automate recovery orchestration, test it repeatedly, and include machine identities and privileged access in every resilience exercise.

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.
• 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.
• Recovery Orchestration: Recovery orchestration is the sequencing and coordination of tasks needed to bring systems back online in the correct order. In multi-cloud environments, it spans accounts, clouds, permissions, and dependencies, so orchestration failures often matter more than backup failures.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

What's in the full article

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

• IDC’s maturity model and how it stages organisations from reactive recovery to adaptive resilience
• Examples of the cross-functional operating model behind ResOps, including business, security, infrastructure, and compliance roles
• The report’s breakdown of tabletop exercises, cyber-range simulations, and validation practices that improve recovery performance
• How the survey respondents are thinking about future resilience pressure from agentic AI, machine identities, and post-quantum cryptography

👉 Commvault's full post covers the resilience maturity model, survey findings, and operating model detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle discipline. It helps practitioners connect access control and lifecycle management to broader security and resilience programmes.