TL;DR: IDC’s Resilience Operations report says more than 500 North American organisations are moving from recovery metrics toward business outcomes, while nearly 6 in 10 still have not defined their minimum viable business and many remain dependent on manual recovery, according to Commvault. The shift matters because AI is compressing attack and disruption timelines faster than current resilience operating models can keep up.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Commvault's blog post: Resilience is shifting from technical recovery measurements to business continuity outcomes as AI compresses attack and disruption timelines.
Why it matters: For IAM, NHI, and broader security teams, the key implication is that recovery planning now has to account for machine identities, SaaS dependencies, and automated response paths that can affect business continuity as much as traditional infrastructure outages.
Context
Cyber resilience breaks down when organisations measure recovery in technical terms but are forced to restore business services under pressure. In practice, recovery time objectives, backup completion rates, and application uptime do not tell leaders whether customer-facing processes, revenue operations, or regulatory obligations can resume.
The article’s identity angle is strongest where modern recovery depends on machine identities, SaaS access, and automated workflows. As environments become more distributed, resilience is no longer just an infrastructure problem. It becomes a governance problem about which identities, services, and dependencies must be restored first to keep the business running.
Key questions
Q: How should security teams define minimum viable business for recovery planning?
A: Start by identifying the smallest set of services, data, processes, and approvals needed to continue operating after disruption. That definition should be owned jointly by business, IT, security, and recovery teams, because it determines what gets restored first, what can wait, and where automation matters most.
Q: Why does AI make manual recovery less effective?
A: AI compresses reconnaissance, exploitation, and lateral movement into shorter windows, so manual recovery often finishes after the business has already absorbed the damage. When restoration depends on people assembling plans during the incident, response latency becomes a security weakness. Automation reduces that gap.
Q: What breaks when organisations have not defined a minimum viable business?
A: Recovery becomes reactive. Teams restore systems based on urgency, noise, or local priorities instead of a shared sequence that brings the business back online, which increases delay, confusion, and the chance that critical dependencies are restored in the wrong order.
Q: How should continuity planning account for machine identities and SaaS dependencies?
A: Treat service accounts, workload credentials, tokens, and third-party trust relationships as recovery dependencies, not just access controls. If those identities are missing, expired, or restored out of sequence, applications may be technically online but still unable to authenticate, exchange data, or resume transactions.
Technical breakdown
Why recovery metrics fail to capture business continuity
Traditional recovery models optimise for restoring systems, not restoring the enterprise’s ability to operate. A low recovery time objective can still leave the organisation unable to serve customers if the wrong applications, data sets, or access paths come back first. ResOps reframes recovery around the minimum viable business, which forces teams to identify the smallest set of services that must be restored in sequence for operations to continue. That shifts the centre of gravity from infrastructure speed to business dependency mapping.
Practical implication: Map recovery priorities to business services, not only to technical systems.
How automation changes resilience under AI-driven attack speed
AI compresses reconnaissance, exploitation, and lateral movement into shorter windows, which means manual recovery becomes a liability. If teams need days to assemble recovery plans, validate clean restore points, and coordinate across functions, the attacker has already won the timing race. Automated recovery orchestration matters because it turns restoration into a repeatable workflow rather than a crisis-driven project. In resilience terms, automation is not convenience, it is the control that keeps response latency below disruption latency.
Practical implication: Build automated recovery and validation steps into the restoration path before incidents force the issue.
Why machine identities and SaaS dependencies now belong in resilience planning
The resilience surface now includes machine identities, cloud services, SaaS applications, and third-party providers. Those dependencies often authenticate and communicate independently of human users, so a business outage may stem from access failure, token expiry, or compromised service credentials rather than a hardware event. That is where identity governance intersects resilience: if service accounts, tokens, and application trust relationships are not restored in the right order, the business may have systems online but still be unable to transact.
Practical implication: Include NHI and workload identity dependencies in continuity and restore sequencing.
Threat narrative
Attacker objective: The objective is to force business disruption before defenders can restore critical services and decision-making.
- Entry occurs through AI-accelerated reconnaissance and initial compromise that shortens the time between discovery and disruption.
- Escalation follows when attackers use automated movement to spread faster than manual recovery teams can coordinate a response.
- Impact lands when business services remain unavailable longer than the organisation can tolerate because recovery is too slow and too siloed.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
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
Business continuity is now the real resilience control. Recovery metrics still matter, but they no longer describe whether the enterprise can keep operating under stress. Once AI shortens the path from compromise to disruption, the question becomes whether the right business functions, identities, and dependencies can be restored in the right order. Practitioners should treat continuity design as a governance discipline, not a post-incident reporting exercise.
Minimum viable business is the missing control plane for recovery. Nearly 6 in 10 organisations lacking a defined minimum viable business is not just a planning gap, it is a decision gap. Without a shared view of what must come back first, recovery becomes reactive and every team optimises for its own metrics. Practitioners should use business service mapping to drive restoration sequencing and escalation authority.
Resilience debt accumulates when recovery remains manual. AI-driven attack speed exposes how much of today’s recovery process still depends on people assembling plans during the incident. That creates a lag between detection and restoration that modern threats exploit. Practitioners should treat automated recovery orchestration, clean restore-point validation, and dependency-aware testing as core resilience capabilities, not optional maturity enhancements.
Machine identity resilience is becoming part of operational continuity. The article correctly points to machine identities as a future resilience pressure point because service accounts, tokens, and workload credentials increasingly determine whether critical services can restart. That makes identity governance part of continuity planning, not a separate IAM concern. Practitioners should design restore order around the identities that re-establish trust between systems.
What this signals
ResOps changes the centre of gravity for resilience programmes. Teams that still treat recovery as an infrastructure function will struggle as business continuity, identity dependencies, and cross-functional coordination become the real constraints. The practical move is to anchor resilience governance in service restoration order and decision ownership, not just backup success.
Machine identity continuity will become a board-relevant issue. As more critical workflows depend on service accounts, tokens, and cloud trust chains, outage impact will increasingly depend on whether those non-human identities can be restored cleanly. That makes identity lifecycle control part of resilience design, not a separate IAM workstream.
For practitioners
- Define the minimum viable business Identify the smallest set of services, processes, data, and approvals required to keep operating after disruption. Tie each to an owner, a dependency chain, and a restoration order so recovery decisions are made against business continuity, not technical convenience.
- Automate recovery orchestration Replace manual recovery assembly with tested workflows for restore selection, validation, and coordination across security, infrastructure, and business teams. Focus on the steps that typically consume the most time during a real incident, especially recovery point selection and service revalidation.
- Include machine identities in continuity planning Map service accounts, workload credentials, tokens, and SaaS trust relationships into business continuity runbooks. If those identities are not available in the right sequence, restored systems may remain unable to authenticate or transact even after infrastructure is back online.
- Run tabletop exercises against business service loss Test cross-functional response using scenarios that remove revenue systems, customer-facing applications, or critical data access rather than only technical infrastructure. Use each exercise to expose hidden dependencies, ownership gaps, and escalation delays before a real incident forces the issue.
Key takeaways
- Resilience is shifting from technical recovery speed to the ability to restore business services in the right order.
- The article points to a material readiness gap, especially where organisations have not defined the minimum viable business that should guide restoration.
- Automated recovery, dependency mapping, and machine identity planning are becoming the controls that determine whether continuity holds under AI-driven attack speed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan Execution | ResOps is about restoring business services under disruption, which maps directly to recovery execution. |
| GV.OC-03 — Mission, Objectives, and Activities Are Understood and Prioritised | The minimum viable business concept depends on explicit business priorities and mission-critical activities. | |
| RC.CO-02 — Recovery Activities Are Coordinated with Internal and External Parties | ResOps stresses cross-functional coordination between security, ITOps, business, and recovery teams. | |
| Recommendation — Align restoration playbooks to RC.RP-01 so recovery restores the services the business actually depends on. Use GV.OC-03 to define which services and activities must come back first after disruption. Coordinate recovery ownership and communications under RC.CO-02 before an incident forces decisions. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article’s machine identity angle touches the lifecycle risk of non-human credentials that outlast their business role. |
| Recommendation — Apply NHI-01 to ensure service identities are removed or retired when continuity dependencies change. | ||
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 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.
- Business Continuity: Business continuity is the capability to keep essential services operating through disruption and recover them afterward. In identity programmes, continuity depends on access control, authentication, and recovery governance remaining dependable when normal workflows are stressed or unavailable.
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 a fit for practitioners who need to connect identity governance with broader resilience and access-control programmes.
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