TL;DR: Traditional backup models struggle with cloud environments that change daily across multi-cloud, containers, and serverless systems, while Commvault says Cloud Rewind can restore full cloud environments and dependencies through automated discovery, drift analysis, and recovery orchestration. The real issue is that recoverability now depends on continuously captured configuration and identity context, not just retained data.
At a glance
What this is: This is a Commvault analysis of why cloud-native recovery demands continuous discovery, dependency mapping, and orchestration rather than static backup alone.
Why it matters: It matters because IAM, cloud security, and resilience teams now have to treat configuration state, resource dependencies, and cloud permissions as part of recovery design, not just as operational detail.
Context
Cloud-native environments change too quickly for backup models built around stable servers and fixed application boundaries. When resources are created, removed, or reconfigured daily, restore success depends on knowing the current configuration, the dependency graph, and the permissions that allow components to work together.
That creates a governance gap for security and resilience teams. Recovery is no longer only about retaining data copies. It is about preserving enough cloud context to rebuild the application safely, which is where identity, entitlement scope, and configuration drift become part of recoverability rather than separate controls.
Key questions
Q: What breaks when cloud backups do not include application dependencies?
A: Recovery breaks at the application level. Even if data is available, missing networks, subnets, security groups, or supporting compute services can prevent the workload from starting cleanly or functioning as intended. Teams may recover fragments of infrastructure, but still face downtime, configuration drift, and manual reconstruction before the service is usable again.
Q: When should teams prioritise automated rebuild testing over more storage copies?
A: When the main uncertainty is whether the environment can be reconstructed, not whether data was retained. More copies do not prove recoverability if configuration, IAM, and dependency state are stale. Automated rebuild testing is the better control when cloud systems change frequently and manual recovery steps are too error-prone to trust.
Q: What are the signs that cloud recovery controls are failing?
A: Common signals include incomplete restores, missing service dependencies, restoration into the wrong region or account, and repeated manual intervention to make recovered workloads usable. If the backup exists but the team still needs many undocumented steps to rebuild the application, recovery control is failing in practice.
Q: How should security teams govern cloud recovery across IAM and infrastructure changes?
A: They should treat recovery as a lifecycle control that spans discovery, change tracking, identity scope, and restore validation. That means the recovery plan must be updated whenever permissions, dependencies, or service boundaries change. The goal is to preserve a restorable state, not just a set of snapshots.
Technical breakdown
Why static backups fail in cloud-native recovery
Traditional backup assumes the thing you restore is broadly the same thing you saved. Cloud-native systems break that assumption because application state is distributed across microservices, containers, serverless functions, network objects, and managed services that change independently. A point-in-time copy of data is incomplete if the surrounding configuration, routing, and dependency relationships are missing. In practice, the recovery problem becomes one of reconstructing an operating environment, not just retrieving files or volumes.
Practical implication: map what must be rebuilt, not just what must be backed up.
How dependency mapping and drift analysis change restore reliability
Dependency mapping captures which cloud resources must come back together for an application to function, while drift analysis compares current state with a protected baseline. Together they close a common failure mode in cloud recovery, where the data is available but the environment no longer matches the version that was originally protected. This matters because unmanaged change, decentralized ownership, and third-party services can alter recovery assumptions without touching the backup set.
Practical implication: use drift detection and dependency graphs to validate that protected state still matches production reality.
Why cloud recovery now includes IAM and metadata
Cloud recovery is increasingly an identity and metadata problem as much as a data problem. Full-stack restore needs the permissions, service relationships, and configuration metadata that allow compute, storage, DNS, and managed services to reassemble correctly. If those controls are missing, recovery may produce an incomplete or insecure environment even when the underlying snapshots are intact. That is why cloud resilience programs now have to track identity scope, resource ownership, and infrastructure metadata as restore inputs.
Practical implication: include cloud IAM and infrastructure metadata in restore design and recovery testing.
Threat narrative
Attacker objective: The objective is to create disruption that static recovery tools cannot quickly unwind, forcing the organisation into slow, error-prone restoration.
- Entry begins with routine cloud change, misconfiguration, or a cyberattack that disrupts the current environment and exposes the weakness of static recovery assumptions.
- Credential and dependency context are missing or stale, so the organisation cannot reliably reconstruct the right permissions, service links, and resource order during restoration.
- Escalation occurs when the restore process reintroduces partial or inconsistent cloud state, creating operational failure, extended downtime, or repeated compromise of the rebuilt environment.
- Impact is delayed recovery, incomplete restoration, and loss of confidence that the organisation can bring the application back exactly as required.
Breaches seen in the wild
- Commvault Metallic breach 2025: A nation-state actor exploited a Commvault zero-day in Azure and may have taken app secrets that open customers' Microsoft 365 tenants.
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
Cloud recovery has become a governance problem, not a storage problem. The article shows that cloud environments now change too quickly for backup thinking built around fixed assets. Recovery has to preserve configuration, dependency, and identity context if the business expects a usable rebuild. Practitioners should treat recovery architecture as part of control design, not as a post-incident utility.
Configuration drift is the hidden failure mode in cloud resilience. Backups can exist while the real environment has moved on through unmanaged change, decentralized ownership, and third-party services. That creates a recovery gap where the restored system may be technically present but operationally wrong. Security teams need a named control concept here: restore-state divergence, the point at which protected copies no longer match the live cloud application enough to recover it safely.
Cloud resilience now depends on identity-aware reconstruction. The article explicitly includes IAM among the resources that must be restored, which matters because permissions are part of the system state. If identity bindings, service relationships, and metadata are not captured, recovery becomes partial by design. For IAM and cloud security teams, the conclusion is clear: restoration must include who and what is authorised to reassemble the environment.
Automated rebuild testing is the only credible proof of recoverability. Point-in-time backups do not prove that the environment can be recreated under pressure. Automated daily or regular rebuilds in isolated spaces test the full chain from discovery to orchestration to functional recovery. That shifts resilience from assumption to evidence, which is the standard practitioners should demand.
Cloud-native recovery is moving toward application assemblies rather than isolated assets. The article’s assembly model reflects where the market is heading: away from file-centric recovery and toward environment-centric restoration. That direction validates integrated discovery, metadata capture, and orchestration as core resilience capabilities. Practitioners should align recovery planning with application boundaries, not storage boundaries.
What this signals
Restore-state divergence: cloud resilience programmes now fail when protected copies lag behind the live application enough that the rebuilt environment no longer behaves like production. That means teams should watch for drift between recovery baselines and current cloud state as a first-class resilience signal.
Because IAM is part of the restore surface, cloud teams need to fold service permissions and ownership into their resilience programme rather than leaving them in separate operational silos. That is especially important where multi-cloud, containers, and serverless services make the environment too dynamic for static recovery assumptions.
For practitioners
- Define recovery around cloud assemblies Map each critical application to the compute, storage, networking, IAM, DNS, and managed services it needs to function after a restore.
- Capture dependency graphs before incidents Document which services must come back in what order, including third-party dependencies that can break a rebuild even when data is intact.
- Test rebuilds in isolated cloud spaces Run recurring recovery exercises that recreate full environments in temporary cloud spaces so the team can measure whether the restore actually works.
- Include IAM metadata in recovery scope Treat cloud permissions, ownership, and service relationships as restore inputs rather than as separate administration details.
- Track configuration drift continuously Compare protected baselines with live cloud state so you can identify when the environment has diverged from what the recovery plan expects.
Key takeaways
- Cloud-native recovery fails when teams treat backups as a data problem instead of an environment reconstruction problem.
- Dependency mapping, drift analysis, and identity context are now essential to restore reliability in modern cloud estates.
- Practitioners should test full rebuilds in isolated environments and include IAM metadata in recovery scope.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IR-04 — Resilience Mechanisms | Cloud recovery and rebuild orchestration are core resilience functions in this cloud-native article. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article explicitly includes IAM as part of full-stack recovery scope. | |
| Recommendation — Design and test restoration workflows so critical cloud services can be rebuilt under disruption. Track cloud permissions as recovery dependencies and validate they can be restored with the workload. | ||
| CIS Controls v8 | CIS-11 — Data Recovery | The article centres on recovery testing, snapshot-based restore, and rebuild reliability. |
| Recommendation — Test restore procedures regularly and verify that cloud applications can be rebuilt from protected state. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud IAM is part of the restore surface because permissions and service relationships must be reconstructed. |
| Recommendation — Include IAM relationships in cloud recovery design so rebuilt services retain the access they need. | ||
| MITRE ATT&CK | TA0040 — Impact | The article addresses how recovery controls limit outage and disruption impact after a cloud incident. |
| Recommendation — Map cloud recovery failures to impact scenarios and prioritise controls that reduce outage duration. | ||
Key terms
- Cloud Assembly: A cloud assembly is the set of resources, configurations, identities, and dependencies that make an application function as a whole. In recovery planning, it is the practical unit that must be rebuilt together if the application is to come back in a working state.
- Configuration Drift: Configuration drift is the gradual divergence between a system's intended secure state and the settings it actually runs with over time. In SaaS, drift often appears when admins change sharing, logging, or access controls under pressure and never return to validate the result.
- Restore-state divergence: Restore-state divergence is the condition where protected recovery copies no longer match the current operational reality closely enough to rebuild service safely. It becomes visible when snapshots exist but the application still cannot be restored without manual intervention or rework.
- Cloud Dependency Mapping: The process of documenting which cloud services, APIs, regions, and external providers a workload depends on. It helps teams understand not just primary dependencies but also hidden trust chains that can turn an outage or compromise into a wider operational event.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control to resilience, access, and recovery in modern environments.
Published by the NHIMG editorial team on July 9, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org