Enable automated backups on RDS

Amazon RDS is the managed database behind many applications. It offers a built-in backup feature that lets the team rewind the database to any moment in the recent past — useful when a bad change deletes or corrupts data. That feature is controlled by a single "retention" setting measured in days. When it's set to zero, the feature is switched off entirely, and there is no way to recover the data if something goes wrong.

The important thing for finance to understand is the cost shape: this protection is essentially free. AWS includes backup storage at no charge up to the size of the database itself, and only bills a few cents per gigabyte per month for anything beyond that. So unlike most resilience controls, there is no meaningful trade-off to weigh — the cost of the protection is near zero, while the exposure it covers (losing production data with no way to get it back) is potentially unbounded: lost revenue, breached contracts, regulatory and audit findings, and in many cases a voided cyber-insurance claim.

The right framing is exposure, not spend. A database with backups disabled is an uninsured liability sitting on the books — and because the premium is effectively zero, there is no defensible reason to carry it on anything that holds real data. The value of this control is that it surfaces those uninsured databases before an incident does, while the fix is still a one-line change rather than a board-level conversation.

Dana is the finance partner working with the platform team. At the operational review the reliability dashboard shows nine databases with automated backups disabled. Dana's instinct is to ask about the cost of fixing them — but the engineering lead explains there essentially isn't one: backup storage is free up to each database's own size, so turning it on adds nothing material to the bill.

That reframes the conversation entirely. There's no trade-off to weigh, so the only question is exposure. Dana asks which of the nine hold real customer or financial data — seven do. Those seven are uninsured liabilities: if any of them takes a bad write, the data is gone, and the firm's audit and cyber-insurance obligations both assume recoverable backups exist. The team agrees to enable backups on all seven immediately with retention matched to data class, and to check the remaining two (genuinely disposable test databases) can stay off with a recorded reason.

Dana's line for the finance pack is one sentence: "Every data-bearing database now has a recovery window at effectively zero cost; the two exceptions are throwaway test systems with sign-off." The next time an auditor or the insurer asks whether production data is recoverable, the answer is a documented yes — and it cost nothing to be able to say so.

Unlike most resilience controls, this one barely touches the budget. Enabling automated backups adds nothing to the bill until the accumulated backups exceed the database's own allocated storage, and even then it's a few cents per gigabyte per month. So there is no premium to weigh, no tiering trade-off, no forecast to build — the cost of the protection is, for practical purposes, zero. That removes the usual finance objection before it's raised.

Because the cost is negligible, this belongs on the risk register rather than the cost report. A production database with backups disabled is a quantifiable, unbounded exposure: the value of the data at risk, plus the revenue lost during an unrecoverable incident, plus the contractual and regulatory penalties — against an annual cost of protection that rounds to nothing. There is no scenario where carrying that exposure on a data-bearing system is the financially rational choice.

The compliance and insurance dimension is where this hits finance directly. Auditors and cyber-insurers routinely require evidence that critical data is recoverable; a disabled backup is a control failure that can fail an audit or void a claim. The dollar value of an insurance payout that doesn't pay out because a precondition wasn't met dwarfs any conceivable saving from the setting being off. Treat disabled backups on regulated data as a finding to clear before the next audit cycle, not a cost line.

Finally, treat the few legitimate exceptions as first-class. A genuinely disposable test or CI database can stay unbacked, but that should be a recorded, reviewed decision with a reason — not a silent default that someone later mistakes for a production system. A clean picture is one where every disabled backup is either fixed or carries a documented, finance-visible justification, so both the recovery posture and its (near-zero) cost are defensible at audit.

Cloud databases can be configured to keep a rolling backup that lets the team rewind to any recent moment after a mistake corrupts or deletes data. When that setting is turned off — as it sometimes is by accident — there is no recovery path at all: the data is simply gone. This protection costs almost nothing, so a database running without it is an uninsured risk with no offsetting saving.

This is a business-continuity issue, not a cost one. The healthy state is simple: every database holding real data has backups enabled with a retention window that matches how far back the business might need to recover. A database found with backups off isn't just a technical gap — it's a signal about whether the organization has basic operational discipline around the data it depends on.

At one company the CFO asked a pointed question after reading about a competitor's data-loss incident: "If one of our engineers ran a bad change tonight, could we get the data back?" The honest first answer was "for most databases, yes — but we're not sure about all of them." That uncertainty was the real finding.

The team turned it into a one-line operational metric: percentage of data-bearing databases with automated backups enabled and a retention window matched to their data class. It started at 84%. Within a sprint it was 100%, with a short, named list of intentionally-unbacked throwaway databases recorded as deliberate exceptions. Because the protection is effectively free, there was no budget conversation — just a discipline one.

That's the right end state for this control: not a heroic recovery story, but a boring confidence signal. "100% of databases that hold real data are recoverable, exceptions on the record" is a one-minute answer that tells leadership the organization treats its own data as something worth protecting.

This control answers a question every executive eventually faces after a competitor's incident or an auditor's request: "if someone makes a bad change to one of our databases, can we get the data back?" A database with backups disabled means the honest answer is no — the data would be gone, with no recovery path. Because the protection costs essentially nothing, there is no defensible reason to carry that exposure on any system holding real data.

The reason it's a leadership item is what its presence signals about operational maturity. A database found running without backups isn't usually a deliberate choice — it's a default that slipped through, which means the organization's guardrails didn't catch a basic, free, obvious protection on something it depends on. The healthy signal isn't a complicated dashboard; it's a flat, near-100% coverage number with a short list of recorded exceptions. A gap there is a cheap problem to fix and a revealing one to find.