Why does cloud-hosted data need a backup approach designed specifically for the cloud?

Why cloud backup has different design requirements than on-premises backup

Cloud-hosted data changes the backup problem because the environment is elastic, distributed and heavily API-driven. Backups cannot assume a fixed server, a single storage array or a single admin boundary. The design has to account for application dependencies, cross-region recovery, account-level failure and the fact that the cloud control plane is often just as important as the data itself.

That means the backup approach has to preserve more than files. It has to preserve restore paths, authentication paths, retention settings and the ability to recover even when the primary workload, subscription or tenant is degraded. For cloud workloads, backup is part of resilience architecture, not just a copy of data.

What makes cloud recovery and continuity different in practice

Cloud backup needs to support faster recovery expectations because many cloud services are run with lower tolerance for downtime and with users, systems and operators spread across locations. A restore process that works on a single local server may be too slow or too brittle when the application is integrated with storage services, managed databases, containers and identity-controlled access points.

Cloud-specific backup design also has to recognise that some failures are not hardware failures at all. They are account lockouts, misconfigured lifecycle policies, deleted objects, broken permissions or region-level outages. Guidance from NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture reinforces the need to design recovery around trusted access, segmentation and recovery outcomes rather than around a single assumed perimeter.

Because cloud platforms expose recovery and control through APIs, backup design must also include verification that the backup system itself is protected from the same access paths that could delete or encrypt the primary data. That is why cloud backup planning often overlaps with access control, audit logging and immutable retention rather than stopping at storage capacity planning.

What a cloud-native backup strategy must preserve

A cloud-native backup strategy should preserve the state needed to rebuild the service, not only the customer content. That includes configuration, permissions, keys, snapshots, database state, application dependencies and the policies that govern retention and recovery. If any of those pieces are omitted, the restore may technically succeed while the service still fails to come back correctly.

For that reason, practitioners should treat backup scope as a service reconstruction question. The right approach is usually to define recovery objectives per workload, then map the data, settings and dependencies required to meet them. Controls in NIST SP 800-53 Rev 5 Security and Privacy Controls support that thinking through access control, auditability, configuration management and system integrity.

Cloud-specific backup also needs to consider where the backup is stored and who can reach it. A backup that shares the same credentials, same region and same administrative trust path as the primary workload may not survive a broad compromise. The design goal is to create an independently recoverable copy, with enough separation that a mistake or attack in one environment does not automatically destroy the other.

Risk and Threat Considerations

Cloud backups are attractive targets because they often contain high-value data, long retention periods and privileged recovery paths. If the attacker reaches the primary cloud account, they may try to delete backups, disable retention, encrypt storage or tamper with recovery settings before the organisation can respond.

Failure mechanism: The backup fails when the same identity, control plane or retention policy protects both production and recovery, so a single compromise, misconfiguration or outage can remove the only viable restore path.

Impact: Loss of backups can turn an ordinary incident into a prolonged outage, a full data-loss event or a ransomware recovery failure, especially when the business assumes cloud availability is the same as backup resilience.

Practitioner Guidance

What to prioritise: Start with recovery objectives, not storage features. Define which workloads must be restorable, how quickly, and from which failure scenarios, then align the backup design to those outcomes.

What to verify: Test restores from a separate administrative path and confirm that backups remain recoverable after permissions changes, account lockout, regional disruption and primary workload deletion. A backup is only useful if it can be restored under stress, not only during a clean test.

Common mistake: Treating cloud backup as a scheduled copy job. In cloud environments, the real failure is often shared control, shared identity or shared policy, so the backup must be isolated enough to survive the same event that breaks production.

Practitioner takeaway: The cloud-specific requirement is resilience against cloud-specific failure modes, so design for independent recovery, not just duplicate storage.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• Why is it important to integrate identity and data governance?
• How should organizations approach the governance of AI agents?