Keep Backups Separate from Production
Last week I wrote about two gaps that keep surfacing in CISO conversations: backup isolation and identity resilience. This week I want to go deeper on the first one, because I think it is the gap where the most assumptions live — and where those assumptions tend to fail at the worst possible moment.
The assumption I hear most often sounds like this: “We’re in the cloud, so we’re covered.”
It is understandable. Cloud providers invest heavily in availability, redundancy, and durability. Moving workloads to AWS, Azure, or GCP is a real improvement for a lot of organizations. But cloud resilience and backup isolation are not the same thing. They solve different problems, and confusing them is how organizations end up with backup architecture that looks solid until they actually need it.
What cloud does and does not give you
Cloud platforms provide availability within their own operational model. They protect against hardware failure, zone outages, and some categories of data loss. What they do not automatically protect against is a production compromise that happens inside your tenant, your account, or your administrative plane.
If an attacker gains access to your production environment, the question is not whether the cloud provider’s infrastructure is resilient. The question is whether your backup data is reachable through the same credentials, the same administrative access, or the same identity plane that the attacker may already control.
In a lot of organizations, the answer is yes. Backups are stored in cloud accounts tied to production. They are managed through the same administrative identities. They are accessible to someone who has already compromised the production environment. The cloud provider’s infrastructure is perfectly intact. The backup data is still effectively inside the blast radius.
That is the architectural problem. And it is a design choice, not a cloud limitation.
What separation actually looks like
Backup isolation means the recovery data cannot be reached through the same path that an attacker would use to compromise production.
In practice, that involves several things:
Separate identity and administrative access. Backup infrastructure should not be manageable through the same accounts and credentials as production. If an attacker compromises a production admin account, that should not give them access to the backup environment.
Immutable storage. Backup data should be stored in a way that cannot be altered, encrypted, or deleted — even by someone with elevated access to production. Immutability is what makes backup data trustworthy when you need it most. Without it, you are relying on access controls that may already be compromised.
Separation from the production cloud account or tenant. This is where a lot of organizations stop short. Keeping backups in a separate bucket or storage account is a start. Keeping them in a completely separate account, with separate access controls and no trust relationship to production, is a more meaningful architectural separation.
Recovery paths that do not depend on production trust. Recovery should be possible without first having to re-establish trust in the production environment. If the recovery process requires logging into a compromised system, using credentials that may be untrusted, or rebuilding access through administrative paths that were affected by the incident — the recovery process itself is fragile.
The insider risk angle
I want to add something that does not always get enough attention: backup isolation is not only about external attackers.
Insider risk — whether that is a disgruntled employee, a compromised privileged account, or an administrator who makes a destructive mistake — is also a reason to maintain architectural separation between production and backup environments. If a single administrator can access and delete both production and backup data, the backup does not provide the protection most people assume it does.
Separation creates friction. That friction is the point. Recovery data should not be as easy to reach as production data, even for people who have legitimate access to the production environment.
The test that matters
The most direct way I know to evaluate whether backup separation is real is to ask a specific question: what would still be recoverable if the production account, tenant, and admin credentials were fully compromised?
If the honest answer is “not much” or “we’re not sure,” the architecture needs attention. If the answer requires assumptions about what the attacker did or did not access, that is also a gap — because recovery under real pressure cannot depend on assumptions about attacker behavior.
The goal is backup data that is genuinely outside the blast radius. Not logically separated. Not protected by the same access controls as production. Actually outside it — stored in a location and managed through an identity plane that an attacker in production cannot reach.
Veeam Data Cloud Vault is the way I see customers address this cleanly without adding significant operational overhead. It provides immutable, offsite backup storage with separation built into the architecture, so organizations are not trying to engineer isolation themselves on top of a general-purpose cloud storage platform. What I find particularly valuable about how it is designed is that it removes a category of risk that is easy to overlook: configuration mistakes. Veeam Data Cloud Vault does not allow unencrypted data to be stored, and immutability is not optional — it is enforced. There is no setting to accidentally leave off, no misconfiguration that quietly leaves backup data exposed or alterable. The security properties are built into the service itself, not left to the administrator to get right under pressure.
But regardless of the tooling, the principle is the same: design backup architecture as if production has already been compromised, and ask whether recovery would still be possible.
That design question changes the conversation.
This is the second post in a four-part series. Next week: why identity resilience is not just an IAM problem — and why Conditional Access policies need to be part of your recovery architecture.
