Across forty teams, how do you make key ownership a standing property rather than a spreadsheet refreshed before each review?

## What "standing property" means A register refreshed before each review is a performance. It is true on the day, false a fortnight later, and its completeness is a measure of how hard someone worked the week before, not of whether the estate knows what its keys protect. Making ownership *standing* means the fact is maintained by the same mechanisms that change it: a key cannot come into existence unowned, a dissolved owner is detectable without anyone looking, and a claim that nobody will re-confirm decays into a visible question rather than a silent lie. ## Four controls, in the order they pay 1. **Ownership as a precondition of creation.** The only moment the purpose and the owner are known for free is the moment the key is created. Capturing them later is archaeology. Enforce it on the path teams actually use to create keys - and keep that path faster than the alternatives, because this control's failure mode is not non-compliance, it is key material generated somewhere the manager cannot see. 2. **Owner values that point at something checkable.** A free-text team name stops meaning anything the moment the organisation reshuffles, and nothing notices. An identifier resolved against an independent list of teams turns a reorganisation into a detectable event: the resolution fails, and the key surfaces as orphaned the week it happens rather than at the next review. 3. **Claims that expire.** An owner re-confirms periodically: yes, this is ours, this is what it protects, these systems call it. The period matters in both directions - too long and the claim is stale anyway, too short and it becomes a reflexive click that certifies nothing. Annual or semi-annual, tied to something the team already does, is the usual compromise. An unattested key becomes a *candidate for retirement*, which starts the deny-then-wait procedure; it never becomes an automatic destruction, because the evidence bar for destruction is separate and higher. 4. **A custodian of last resort.** Orphans need an address. A named team holds keys whose owner dissolved, with a deadline per key to reassign or retire. Without the deadline the custodian becomes a landfill and the orphan count only ever rises - which is the same failure as having no owner, with extra paperwork. ## What each control costs | control | what it buys | what it costs | |---|---|---| | owner required at creation | no new unowned key enters the estate | friction, which pushes some key material outside the manager | | owner resolved against a team list | a dissolved owner surfaces on its own | a dependency on someone else's list being accurate | | expiring ownership claims | stale meaning becomes visible | becomes a rubber stamp if asked too often | | custodian of last resort | orphans have an accountable holder | grows without bound unless each key carries a deadline | The first row is the one a lead has to think hardest about. Every control that makes the managed path slower is an argument for generating key material on a host and keeping it in a file, where it is both unowned *and* invisible. The correct trade is to attach the requirement to the fast path rather than placing a gate in front of it. ## The metric to report Completeness is the wrong number because it is trivially gamed: fields get filled with plausible text and the register scores well while answering nothing. Report instead a **sampled hour test**: choose keys at random each period, ask the recorded owner what the key protects and what breaks if it is denied, and report the share answered correctly within the hour. That number is hard to fake, it measures the property you actually want, and it goes down for exactly the reasons you need to hear about - reorganisations, departures, and keys minted outside the standard path. A second number worth publishing is the count of keys with no resolvable owner, with its trend. Not zero as a target - that invites a clean-up that assigns everything to one team - but a trend and an age distribution, so a key that has sat orphaned for eight months is visible as such. ## What a lead cannot delegate Three decisions stay with whoever owns the standard: - **How much friction the managed path may carry** before it drives teams off it. - **Who may authorise destruction** of a key that nobody claims, and what evidence that decision must leave behind, given the act is irreversible. - **What the organisation is willing to keep paying to hold** - because an unowned key is not free: it is a standing liability with no one to answer for it, and carrying a hundred of them is a choice even when nobody remembers making it. A central team owning every key looks tidy and destroys the thing being measured: the owner is supposed to be the party who knows what breaks, and a central team knows that for nothing.