A seven-year log archive must keep its bytes in one jurisdiction and let a customer order its records destroyed - what do you accept by holding the key yourself?
answer
- custody buys proof, not secrecy
- the key store joins the read path
- key residency is its own fact
- losing the key destroys the archive
- escrow weakens the destruction claim
basics
~20 sYou accept that the key store becomes the availability of the archive, that losing the key is indistinguishable from destroying it, and that key residency is now a separate fact to defend. In return you get a destruction switch you can evidence.
solid answer
~50 sCustody buys two things worth having for this contract: a destruction mechanism scoped per customer that you can evidence, and control over where key material sits. It costs three. First, availability - every read now depends on the key store, so an outage, a policy slip or a mistaken disable presents as an unreadable archive and your team is paged, not the provider. Second, recoverability - you can lose the key, and that is the same outcome as destroying the archive, which is why any escrow copy you keep to protect against that also weakens the destruction claim. Third, proof obligations - key residency is a separate fact from data residency, and whether the obligation covers it has to be read rather than assumed. The judgment is matching custody to a stated obligation, not maximising control.
go deeper
Take away the core trade: holding the key gives you the power to make data unreadable, and it also means the data is unreadable whenever your key system is unavailable or the key is lost.
Explain that custody puts the key on the read path, so a confidentiality control becomes an availability dependency, and that a key you can recover is a key that weakens any claim the data was destroyed.
Show the operational plan: on-call for the key path, a runbook separating a disabled key from an unreachable store, cache windows that delay revocation, and a drill that proves both a cold read and a scoped destruction.
Make the call from the obligation's wording, not from instinct. Choose key scope before the first write, decide recoverability against provable destruction explicitly, and record what was traded so the decision survives the incident that questions it.
## The three postures, and what each can actually prove This is a decision with three positions, and the right one follows from the obligation rather than from a preference for control. | Posture | Destruction you can evidence | Where key material sits | Who is paged when reads fail | |---|---|---|---| | Provider-held default key | none - you have no switch | the provider's key service, wherever it operates | the provider | | A key you control in the platform's key service | yes, if the key scope matches the obligation | that region's key service, on the provider's terms | you, for the key policy; the provider, for the service | | Key material in a store you operate | yes, and independent of the provider relationship | wherever you put it, which you must then defend | you, for everything on the key path | For a contract that permits a customer to order its records destroyed, the first row cannot discharge the obligation at all. The real choice is between the second and the third, and it is mostly a question of whether custody has to survive the provider. ## Custody makes you the availability of the data This is the consequence teams underestimate, and the one a lead is expected to name first. - Every read, and often every write, now depends on an `unwrap` call succeeding. The key store is on the critical path of the archive. - The failure does not look like a security event; it looks like an outage. A key disabled in error, an expired credential the service uses to call the key store, a network path that is unreachable, or a policy edit that removes the service's permission to use the key all present as the same symptom: objects that will not open. - The provider's availability commitment covers its service, not a key store you run. Composite availability is the product of both, and the weaker term is now yours. - Cached data keys soften this - a short outage may be invisible - but the same cache is the lag on a revocation. You cannot have instant revocation and outage tolerance from the same setting. ## Losing the key is destroying the archive Custody makes an irreversible failure possible that simply did not exist before. Treat it as such: 1. Decide the recovery posture explicitly - a second copy of key material, held where, reachable by whom, under what break-glass procedure. 2. Accept the consequence: any recoverable copy is a copy that can also be used, which is a hole in the destruction promise you made to the customer. 3. Note that key services offer a pending-deletion window that is still reversible for exactly this reason, and that the window is a delay on destruction, not destruction. There is no configuration that gives both perfect recoverability and provable destruction. The lead's job is to say which one the contract requires, in writing, and to design for that one. ## Key residency is a separate fact from data residency The bytes staying in one jurisdiction is an obligation about the data. Where key material lives is a different fact that has to be checked on its own terms: - A regionally scoped key binds the archive to that region in practice - if the key service there is unreachable, so is the data, whatever its replicas say. - Key material held outside the provider can sit in a different jurisdiction from the bytes, which some regimes treat as material and others do not address at all. - Some obligations are satisfied by the key never leaving; others speak only to the data. Read the wording. An assumption in either direction is how this decision gets made badly. ## Scope is what makes destruction provable None of the custody work pays off unless the key's scope matches the obligation's scope. A destroy-on-request contract implies **a key per customer**, decided before the first write, because retrofitting it means re-encrypting an archive priced by its volume. Alongside that, the claim only holds if every copy - live, replicated, backed up within retention - is ciphertext under that key, and if no plaintext export or downstream derived artefact escaped the boundary. The cryptography is almost never what fails here; the inventory is. ## How to decide, in order 1. Name the obligation and quote it, including whether it mentions key location at all. 2. Choose the key scope that obligation implies, and check whether the store can be keyed that finely. 3. Choose the posture - platform key service or a store you operate - on whether custody must survive the provider relationship. 4. Price the operational burden: on-call for the key path, the recovery procedure, and the drill that proves both a read and a destruction work. 5. Write down what you traded away, because the recoverability-against-destruction choice is the one someone will question in an incident.
- Who is paged when reads of the archive start failing under this posture?Your team. The storage service is reporting an unwrap it could not complete, and the key material lives in a system you run, so the fault is on your side of the line. That on-call burden, and a runbook that distinguishes a disabled key from an unreachable key store, is part of the cost of custody.
- Does keeping a break-glass copy of the key undermine the destruction promise?Yes, to the extent that the copy is usable. A destruction claim holds only if no usable key remains anywhere, so an escrow copy converts the promise into one about intent and procedure rather than about cryptography. If the contract requires provable destruction, the escrow has to go, and the recovery risk is accepted instead.
- How would you test this arrangement before relying on it?Drill both directions. Prove a read works from a cold start including the key path, and prove a destruction actually renders one customer's records unopenable across live objects, replicas and backups within retention - then confirm nothing else went dark. Also rehearse the key store being unreachable, since that failure will arrive first.
Keeping the only key to a rented vault yourself. Nobody can open it without you, including you on the morning you cannot find the key.
saying these in an interview costs you the question
- Argues more custody is always better without pricing the availability risk.
- Assumes the provider's availability commitment covers a key store you operate.
- Asserts the key must sit in the data's jurisdiction without reading the obligation.
- Keeps a usable escrow key copy and still promises provable destruction.
- Forgets that a cached data key delays the effect of a revocation.
- Adopts custody without narrowing key scope to match the obligation.