Background

Platforms often expose tiered controls that trade cost against risk: how many backup copies, which storage class, how long to retain, how much redundancy, how strict the security posture. In this post I’ll discuss who should carry the burden of proof when a team wants the cheaper tier, and why the default matters so much.

The failure I want to avoid is silent risk accumulation. Chargeback and cost pressure push every team to claim the cheapest tier that sounds plausible. If they can self-declare with no verification, a dataset marked low-risk today drifts into high-risk as its sources are deleted and its pipelines rot, and nobody notices until a recovery fails. The label was right when it was written and wrong by the time it mattered.

The rule

The default is the safest tier. Teams opt into a cheaper tier only by supplying verifiable evidence that the weaker tier still meets the underlying requirement, and that evidence expires and has to be renewed.

Putting the burden of proof on whoever wants the discount inverts the failure mode. The upside is that a team which cannot produce evidence simply stays on the safe, expensive tier; the downside is that they pay more than they might have needed to. That is the correct downside to have. The worst case is overspending, never data loss.

Practices

Classification lives in code, beside the resource, validated at deploy time. No classification means the default tier is applied automatically. No spreadsheets, because a spreadsheet is exactly the artefact that drifts out of sync with reality.

Cheaper tiers are earned, not declared. To claim a weaker tier the team supplies machine-checkable evidence that the requirement is still met. For data that is claimed to be “regenerable”, that evidence is a manifest pointing at the source dataset and the pipeline that rebuilds it.

Verify continuously and mechanically. Check that the source still exists, that the source is itself backed up at the right tier, and that the regeneration pipeline actually ran recently. These are the two failure modes that quietly break “regenerable”: the source got deleted, or the rebuild pipeline rotted. Checking them continuously catches the drift long before an audit would.

Evidence expires. Claims re-prove on a schedule, annually for example. Regenerable today is not regenerable forever, and a one-time proof treated as permanent truth is how you end up trusting a lie.

State requirements as intent, not mechanism. “Data must be recoverable within the RPO” rather than “keep two copies”. Intent-based requirements let evidence legitimately satisfy the requirement without prescribing one implementation, so a team that can rebuild from source is not forced to also keep copies it does not need.

Tier the cost levers explicitly: number of copies, storage class, backup frequency, retention period, immutability scope. Map each lever to a tier rather than applying one setting uniformly across everything.

Legitimate exceptions

Not everything needs per-team evidence.

Platform-side global optimisations, retention right-sizing, moving old backup generations to colder storage, deduplication, need no per-team proof. The platform owns that risk and applies them universally; on a long tail of services these usually deliver the largest savings for zero per-team effort.

Trivially ephemeral data classes can be pre-approved for the cheap tier by policy rather than per-service proof.

Reserve the heavyweight drills, a full restore or a full regeneration, for the highest-spend services where the saving justifies the engineering time.

Anti-patterns

Self-classification with no verification mechanism, where the discount is claimed and never checked. Evidence that never expires. Blanket mandates that back everything up identically and so price tier-3 data at tier-1. And the one that quietly undoes the whole scheme: verification that costs more than it saves. If proving the discount is more expensive than the discount itself, the program is upside down and you should just apply the safe tier.