Protect Azure resources with backup

Backup is one of the few security controls with a real, recurring Azure cost, so it deserves a finance lens rather than a blanket fix. Enabling Azure Backup for a VM consumes protected-instance fees plus the storage the recovery points occupy. Turning on geo-redundant backup for a database roughly doubles the backup storage footprint, because a second copy is held in the Azure paired region. These are bounded, forecastable line items, not open-ended spend.

Frame each failing recommendation by what the resource would cost to lose, not by the backup fee. A VM hosting a stateless web tier behind a load balancer may be rebuildable from code in minutes, so its backup is cheap insurance against a small risk. A database holding the only copy of customer records carries an existential expected loss, so geo-redundant backup is non-negotiable regardless of the storage bill. Map the failures to the data behind them and prioritise by what is irrecoverable, not by recommendation count.

The arithmetic is one-sided where it matters most. The remediation is a modest, predictable monthly charge. The downside of leaving it is the documented cost of permanent data loss: regulatory exposure, contractual breach, the cost of reconstructing or re-acquiring the data if that is even possible, and the reputational damage of telling customers their data is gone.

Priya is the finance partner supporting the platform team's SOC 2 push. The security report lands with nine backup findings: eight virtual machines with no protection and one production database flagged for local-only backups. The instinct is not to wave through a blanket backup budget; it is to ask what each resource would cost to lose. Backup is one of the few controls with a real recurring charge, protected-instance fees plus recovery-point storage for VMs, and roughly double the backup storage for a geo-redundant database, so the spend question is genuine rather than rhetorical.

Priya asks the team to map each failing resource to the state behind it. The database holds the only copy of customer order history, three of the VMs run stateful line-of-business apps, and the remaining five are stateless web nodes behind a load balancer that redeploy from a pipeline in minutes. The list is reframed by irrecoverability: the database gets geo-redundant backup today regardless of the storage cost, the three stateful VMs get a backup policy sized to their recovery objective, and the five stateless nodes are documented as rebuildable-from-code rather than backed up, saving the protected-instance fees on resources that do not need them. The finance pack reads: 'Four resources carry irrecoverable loss and get protected now at a bounded monthly cost; five are rebuildable and are explicitly excluded with a recorded reason; the spend is forecastable and proportional to what we would actually lose.'

The cost model here is one of the clearer ones in security work. Backup carries a real, recurring Azure charge, so the question is never 'is it free?' but 'is the cost proportional to what we would lose?' For a resource holding irreplaceable data, the answer is almost always yes by a wide margin: a modest monthly backup fee against the existential cost of losing the only copy of customer records. For a stateless resource that redeploys from code, the answer may be no, and explicitly excluding it is good stewardship, not a gap.

The documented cost of unrecoverable data loss includes mandatory breach or incident notification, contractual penalties, the cost of reconstructing or re-acquiring data where possible, prolonged downtime, and customer churn that often dwarfs the technical loss. Against that, the remediation is a bounded and forecastable monthly charge that scales with protected instances and, for geo-redundant databases, roughly double the backup storage. The finance role is to attach a cost-of-loss to each failing resource so protection is funded where it matters and consciously skipped where it does not.

Backup is the control that separates an incident from a catastrophe. A VM with no backup or a database whose only backup sits in the same region as the data is one bad event, ransomware, a regional outage, a fat-fingered deletion, away from permanent loss, and the report shows this as a scatter of separate findings across the estate.

The leadership question is not 'do we take backups?' It is 'if our most important system failed right now, how recent a point could we recover to, and would the backup survive whatever took the system down?' The defensible end state is that every stateful resource is protected by policy, the recovery objective for each tier is a deliberate decision, and the backups for critical data live somewhere the original failure cannot reach.

This is partly a cost decision, but a small and bounded one. The far larger number is the cost of discovering, mid-incident, that the thing you needed to restore was never being backed up, or that the backup died alongside the data.

After a peer company spent four days down following a ransomware event, and then discovered their most important database had never been backed up off-region, the CEO asked the obvious question at the next review: if our most important system failed right now, how recent a point could we recover to? The honest answer at the time was that it depended on the system, because backup across the estate was governed by whoever happened to set it up rather than by policy.

The team's response was to stop treating backup as a per-resource afterthought and start treating it as a guarantee. They listed every VM with no protection and every database with local-only backups, enabled Azure Backup on the stateful resources, moved the critical database to geo-redundant backup so a regional outage could not take both copies, and then set an Azure Policy that audits every new VM for backup so an unprotected one cannot quietly slip into production. The next time the CEO asked the question, the answer had changed from 'it depends' to 'our critical systems recover to within hours, the backups survive losing the region, and anything not backed up is rebuildable from code on purpose.' That shift, from assuming recoverability to guaranteeing it, is the one-line confidence signal this capability delivers.

Nearly every business-ending data-loss event came back to the same root cause: a resource that mattered was not recoverable when an ordinary failure hit it, either because it had no backup or because the backup died with it. Backup is the capability that makes that root cause structurally difficult, and geo-redundancy on critical data makes the regional-failure version of it survivable.

The cost of getting this wrong is potentially the business itself, while the cost of getting it right is a modest, bounded and predictable monthly charge plus the discipline to decide what each tier of system actually needs. This is the rare class of control where the downside is unbounded and the upside is cheap insurance, which is exactly the trade leadership should be quickest to approve.