Manage KMS encryption keys

KMS keys cost about a dollar a month each, and almost every control in this group costs nothing in AWS spend to satisfy. Enabling rotation, cancelling a deletion, tightening a key policy or scoping a decrypt permission does not change the bill. The cost lives entirely on the risk side, and it is asymmetric: the keys protect the company's most sensitive data, so a key mistake is one of the few configuration errors that can become a reportable breach or permanent data loss.

Read each failing control by the data behind it rather than by the control count. A publicly accessible key on a partner-data exchange (KMS.5, Critical) or a production key in a deletion countdown (KMS.3, Critical) carries a far higher expected loss than a never-rotated key on a low-traffic test store (KMS.4, Medium). Map the failures to what each key encrypts and prioritise by exposure, not by the order the report lists them.

The insurance maths is one-sided. The remediation is engineering minutes per key. The downside of leaving it is the documented cost of a key-related incident: a breach traceable to a wildcard key policy, permanent loss from a deleted key whose backups were encrypted with that same key, or a compliance finding when an auditor pulls the rotation and key-policy evidence. This is the rare capability where the spend to fix is essentially zero and the avoided downside is open-ended.

Priya is the finance and risk partner at a healthcare SaaS company. Security Hub shows a scatter of key findings: a few KMS.4 rotation failures, one KMS.5 publicly accessible key, and a KMS.3 finding where a decommissioning role has just scheduled a production key for deletion. Her first instinct is not to ask what the fix costs, because she knows it is essentially nothing: enabling rotation, cancelling a deletion or tightening a key policy changes no AWS line item, and the keys themselves run about a dollar a month. The cost lives entirely on the risk side, and it is asymmetric, because each key sits in front of a large pool of sensitive data.

She reads each failing control by the data behind it rather than by the control count. The KMS.3 pending-deletion finding on a production key is the one with a clock running and the largest possible loss, total unrecoverable destruction of everything it ever encrypted, backups included, so it is the immediate action regardless of its Medium-looking neighbours. The KMS.5 publicly accessible key on a partner-data exchange is the next priority, a Critical exposure of regulated data. The KMS.4 rotation gap on a low-traffic test store is a routine cleanup. Her output for the risk pack is a worklist ordered by expected loss keyed to what each key protects, with a note that persistence beyond one reporting cycle, on a free and framework-mandated control, is a process and ownership problem rather than a budget one.

The cost model here is the rare one where action costs essentially nothing and inaction creates unbounded tail risk. Enabling rotation, cancelling a deletion, scoping a policy and encrypting the audit trail are all free in AWS terms; the keys themselves are about a dollar a month. The downside is the documented cost of a key-related incident: a breach traceable to an over-broad key, permanent loss from a deleted key, or an audit finding that turns a five-minute fix into a remediation cycle with re-test fees.

The blast radius compounds with what each key protects, so the finance role is to attach expected loss to each failing key. A Critical KMS.5 or KMS.3 finding on a key behind regulated customer data is a this-week priority; a Medium KMS.4 finding on a disposable test store is a routine cleanup. Prioritising by the data behind the key, not by the report's ordering, is what turns a wall of red into a short, defensible worklist.

Treat persistence as the trigger, not cost. A free, framework-mandated control that stays open for more than a reporting cycle is a process and ownership problem, not a budget one. A small, documented set of exceptions, for keys that legitimately cannot rotate, is fine; an open finding on an eligible key is the prompt to ask who owns closing it.

Encryption keys are the locks on the company's most sensitive data. This group of controls asks whether those locks are well managed across their whole life: do they rotate so a stolen key is not valid forever, are they protected from accidental deletion that would destroy the data they protect, are they private rather than reachable by any external account, and is the right to decrypt scoped to the principals that genuinely need it.

The leadership question is not whether each box is ticked today. It is whether key health is a default. A key that drifts into a deletion countdown, picks up a wildcard principal, or never rotates is a configuration mistake one bad change away from being an incident. The defensible end state is that rotation is on by default, deletion of production keys is blocked by policy, key policies name principals explicitly, and decrypt is scoped to specific keys.

None of this is a cost decision. The keys are cheap and the fixes are free. It is a governance decision about whether the controls that protect everything else are themselves protected by design, or left to vigilance.

After an internal review surfaced a production key that had drifted into a deletion countdown unnoticed, the CTO asked the security team one question: are the locks on our most sensitive data healthy by policy, or only because people remember not to make a mistake. The honest answer was the latter. A key had nearly been deleted, another carried a wildcard principal, and several had never rotated. Each was one bad change away from a breach notification or irrecoverable data, and every fix was free.

The team made key health a default rather than a quarterly chase. Automatic rotation went on for every eligible customer managed symmetric key, with documented suppressions for the asymmetric and imported-material keys that cannot rotate. Key policies were rewritten to name principals explicitly instead of wildcards, decrypt permissions were scoped to specific key ARNs, and CloudTrail logs were pointed at a dedicated customer managed key so reading the audit history itself requires a controlled, logged decrypt. Then Service Control Policies were added to deny ScheduleKeyDeletion on production-tagged keys and to reject any policy reintroducing a wildcard. The next review answered the CTO differently: key health is now enforced by default, with exceptions on the record. That standing posture, not the individual ticks, is the governance signal.

Encryption is one of the primary controls the company cites when asked how it protects customer data. This group of controls checks whether that claim holds up: keys that rotate, cannot be deleted by accident, are not reachable by external accounts, and can only be used by named principals. Get one of these wrong on a high-value key and a configuration mistake becomes a headline, a breach notification, or irrecoverable data.

The cost of getting it wrong is large and well documented, while the cost of fixing it is essentially engineering time. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve, and exactly the place to insist on prevention by default rather than cleanup after the fact.