Notifications
Clear all
Topic starter
09/07/2026 3:24 pm
TL;DR: Multi-cloud backup often protects data service by service, but recovery still fails when teams must restore synchronised applications across clouds, accounts, and admin domains, according to Commvault. The real control gap is not storage durability but orchestration, dependency mapping, and governed automation across the full recovery path.
NHIMG editorial — based on content published by Commvault: multi-cloud recovery, application-level resilience, and AI-enabled automation
By the numbers:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
Questions worth separating out
Q: What breaks when multi-cloud backup is treated as the same thing as recovery?
A: Service-level backup protects data, but recovery fails when teams cannot restore the full application state in the right sequence across clouds, accounts, and identities.
Q: Why do multi-cloud environments make recovery harder for IAM and PAM teams?
A: Because recovery depends on the permissions of service accounts, automation tokens, and privileged workflows that span multiple providers and admin domains.
Q: How do you know if multi-cloud recovery is actually working?
A: A recovery programme is working only if it can restore a real application, with its dependencies and identity bindings intact, within its target recovery time.
Practitioner guidance
- Map recovery at the application layer Document the service dependencies, identity bindings, and cross-cloud control paths required to restore each critical application in a usable state.
- Inventory recovery automation identities List every service account, token, and agent that can trigger backup, failover, or orchestration actions.
- Scope restoration permissions to task and environment Remove broad standing access from backup and recovery workflows, and separate read, restore, and orchestration permissions by environment.
What's in the full article
Commvault's full episode covers the operational detail this post intentionally leaves for the source:
- Step-by-step discussion of why service-level backup does not guarantee application-level recovery across AWS, Azure, and Google Cloud.
- Specific examples of how dependency mapping changes recovery sequencing when multiple admin teams and vendor tools are involved.
- The practical impact of AI-enabled automation on backup triggers, permission scope, and recovery governance.
- The source conversation's own framing of what CISOs and DevOps leaders need to align on before the next incident.
👉 Read Commvault's discussion on multi-cloud recovery and application-level resilience →
Multi-cloud recovery and application-level resilience: what teams miss?
Explore further
09/07/2026 3:43 pm
Application recoverability is now an identity governance problem as much as an infrastructure problem. Multi-cloud recovery depends on service accounts, automation tokens, and cross-cloud permissions that decide what can be restored and in what order. If those identities are inconsistent across providers, the recovery plan is already brittle. Practitioners should treat recovery access as governed identity, not as an afterthought to backup design.
A question worth separating out:
Q: Who should own permissions for recovery automation and agentic workflows?
A: Ownership should sit jointly with resilience, IAM, and PAM, because recovery automation is privileged identity infrastructure. The owner must define scope, approval boundaries, logging, and offboarding for every service account or agent that can trigger recovery actions. That prevents a recovery tool from becoming a hidden admin plane.
👉 Read our full editorial: Multi-cloud recovery gaps expose weak application-level resilience
