With seven years of retained ciphertext and a yearly key rotation, do you backfill old rows or carry every version forever?

## Do the arithmetic before the argument The debate is usually conducted as a matter of taste - *shouldn't we re-encrypt the old data?* - when it is a division. Where nothing is ever rewritten, the number of key versions the estate depends on converges to: > **live versions = retention period / rotation period** Seven-year retention with a yearly rotation converges to about seven live versions (briefly eight, in the window after a rotation and before the oldest year's data expires). The same retention with a quarterly rotation gives twenty-eight; monthly gives eighty-four. Nothing is wrong with seven. Something is probably wrong with eighty-four, and the team that chose a monthly cadence to look diligent usually never computed it. So the decision a lead owns is not *rotate or not*. It is: **what is the target number of live versions, and what funds getting there?** ## What each live version actually costs - material that must be held, backed up, and restored with the manager, in every region it serves; - a line in whatever statement the organisation makes about custody, and an answer when an external audit asks how often the key changes and who can prove it; - a version that cannot be retired while any readable copy anywhere still names it; - one more thing that has to survive a disaster-recovery exercise intact, because losing it means losing the data it protected. None of those is dramatic on its own. The point is that the cost is per version and permanent, so the cadence you pick multiplies it. ## The three levers | Lever | What it costs | What it needs to be true | |---|---|---| | Let retention age versions out | nothing | expiry is actually enforced, and the backup horizon has passed too | | Fund a rolling backfill | one campaign per cycle | a resumable, marker-driven job and capacity to run it | | Make rotation a rewrap | a structural change, paid once | objects carry their own data keys, wrapped by the managed key | | Shorten retention | a business decision, not a technical one | someone who can actually approve holding less | **Letting retention do it** is the cheapest and the most often wrong for one reason: *expired* is not the same as *deleted*, and a version is not retirable while a backup you would still restore contains rows naming it. Get the horizon wrong and the first restore after the retirement is the incident. **A rolling backfill** keeps the live set small - move the oldest partition each cycle and you hold two or three versions instead of seven - at the price of a standing annual commitment that competes with production load, and which nobody budgets for after the first year. **Changing the shape** is the structural answer: where each object holds its own data key wrapped by the managed key, moving everything onto a new version is a rewrap of small wrapped keys rather than a rewrite of rows, so the live set can be pulled down to one or two cheaply and repeatedly. It is also the hardest to retrofit, because retrofitting it is itself the full backfill. ## What to decide, and what to state 1. **The target.** How many versions the estate is willing to depend on, as a number. 2. **The mechanism that enforces it.** Retirement, and a floor where the design offers one - otherwise the target is an aspiration. 3. **The evidence.** A census of version markers across live storage, backups within the restore horizon, replicas and archives. Not the rotation log: seven successful rotations say nothing about which rows still name version 1. 4. **The owner and the budget.** Who runs the backfill each cycle, and out of whose capacity - because the default answer is nobody, and the default outcome is a version set that only grows. 5. **The reversibility you keep.** Refusing to serve a version can be undone; destroying its material cannot. Decide deliberately which you are doing, and demand more evidence for the irreversible one. ## The trap worth naming The common failure is not choosing wrong. It is choosing a rotation cadence for how it sounds - monthly, because it reads well in an answer about key hygiene - without computing the version count it implies or funding the backfill that would keep the count down. Two years later the estate depends on two dozen key versions, no one can say which of them any stored row still needs, and retiring the oldest is a research project. A defensible position is a modest cadence, a stated target, a census that proves it, and a floor that enforces it.