Enable deletion and termination protection

Every control in this group is a setting, not a service, so there is no line item attached to fixing it. Enabling termination protection on a stack, deletion protection on a database, or the deletion-protection attribute on a load balancer changes nothing on the AWS bill. The cost is bounded engineering time to flip the flags and fix the templates that ship them off by default.

The reason this lands on a finance or risk radar is the asymmetry. The safeguards are free, but the events they prevent (a deleted production database, a wiped CloudFormation stack that owned the whole environment, a load balancer dropped mid-deployment) are among the most expensive things that can happen to a business: lost data, regulatory exposure, recovery effort, customer credits and reputational damage that dwarf any cloud line item. Public post-mortems of accidental deletes routinely land in six figures.

From a governance standpoint, a persistent failure in this group is a finding about discipline, not dollars. It usually means infrastructure is being created from templates that do not set the safe defaults, which means the same templates are spawning other unprotected resources too. The number to watch is not a cost; it is the count of long-lived production resources failing these controls, and whether that count trends to zero and stays there.

Priya is the finance and risk partner for the platform team. Security Hub fires a spread of deletion-protection failures across CloudFormation stacks, RDS instances and load balancers in three accounts that pre-date the safe-defaults standard. Her instinct is not to ask for a budget line, because there is none: every control in this group is a setting, not a service, and flipping the flag changes nothing on the AWS bill. Her question is which of these resources is long-lived production, because those are the ones where a deletion would be unrecoverable and expensive.

The team buckets the inventory by environment tier. Two production RDS instances and several production stacks are unprotected; a handful of CI and sandbox resources are also flagged but are intentionally disposable, where protection would just add friction to automated teardowns. Priya prices each unprotected production resource as an uninsured deletion-accident exposure, recovery hours plus SLA credits plus regulatory notification, against a zero cost to fix, which makes the prioritisation self-evident. Her output for the risk pack is a count, not a dollar figure: the number of long-lived production resources failing these controls, with a note that the residual target reflects disposable resources rather than zero, and a question about whether the source templates were fixed so the count does not creep back up.

Most compliance controls involve a trade-off. This family is unusual because the remediation is free and the risk of ignoring it is quantifiable. Enabling protection adds no compute, storage or licensing charge; it is a boolean with no price tag. The relevant number is the count of long-lived production resources failing these controls and the size of the loss if one of them were deleted.

The asymmetry is the whole story. These controls are rated Low or Medium because deletion events are rare, but the cost when one happens is among the largest a business can absorb. That is the textbook case for a cheap, always-on safeguard: you do not price it against its frequency, you price it against its worst outcome, and the fact that it is free removes even the usual cost-benefit debate.

For governance, the right framing is uninsured liability. A production stack, database or load balancer without protection is an uncovered exposure with a documented cost range. Enabling protection on every long-lived resource converts that open liability to a closed one at zero premium. The finance contribution is to classify resources by environment tier, treat protection as a precondition for production sign-off, and require a recorded exception for any long-lived resource intentionally left unprotected, rather than a silent finding.

Most production resources can be deleted with one command by anyone holding the right permission. Deletion and termination protection is a free flag that requires that command to be a deliberate two-step action: disable protection, then delete. Security Hub flags the long-lived resources where the guard is off, across stacks, databases, tables, load balancers, container capacity providers and user pools.

This is a low-frequency, high-consequence category. The controls are rated Low or Medium because the bad event is rare, but the right way to read them is as cheap insurance against a tail risk no business wants to be on the wrong side of. A clean score is a small but real signal that the organisation sets safe defaults on the infrastructure that holds its most important data and serves its most important traffic.

None of this is a cost decision. The flags are free. It is a governance decision about whether critical systems are protected by design or only by everyone remembering not to run the wrong command in the wrong terminal window.

After a near-miss where a stale Terraform plan almost deleted a production database, the CTO asked the platform team a single question: can a wrong command still permanently destroy production. The honest answer was yes, because the flags that block a one-step delete defaulted to off and the old modules never set them. The fix was free; the gap was that nobody had formally decided critical systems require deliberate, two-step deletion.

The team made the safe default automatic rather than chasing the findings quarter to quarter. Protection went on by default in the approved infrastructure templates, alongside backups and encryption; per-resource retention policies were added for stateful resources so an UpdateStack could not replace a database out from under itself; and a Service Control Policy denied the delete action on resources tagged production. Disposable environments were left intentionally unprotected so teardowns stayed frictionless. The next review answered the CTO's question differently: production deletion now takes a deliberate two-step, enforced automatically, with disposable exceptions on the record. That standing yes, with documented exceptions, is the governance signal, not the technical depth behind it.

Nearly every accidental-deletion incident comes back to the same root cause: a critical resource that could be deleted in one step was deleted in one step, by an internal change against the wrong target. Deletion and termination protection makes that root cause structurally difficult, and pairing it with per-resource retention policies and Service Control Policies makes it close to impossible.

What makes it a leadership item rather than a pure engineering one is accountability and the fact that the fix is free. An unprotected production resource represents a policy gap: the team has not formally decided that critical systems require deliberate, two-step deletion. The healthy end state (protection on by default on everything long-lived, intentionally off on disposable environments, every exception documented) is a governance signal, not a technical one. It says critical systems are protected by design, not by luck, and the leadership move is to insist the safe default is automatic so the risk is structurally closed and never has to be revisited.