A retention lock on stored records cannot be shortened, and an erasure request arrives for one of them — what now?
answer
- the date only ever moves later
- a lock an admin can lift is a policy
- the platform offers no override
- unreadable rather than absent
- decide the scope before anything is locked
basics
~20 sA lock that cannot be shortened keeps the bytes until its retained-until date passes, so the erasure obligation has to be met another way — usually by destroying the key material that makes the record readable, and by never placing erasable personal data under such a lock in the first place.
solid answer
~50 sA retention lock is the store enforcing immutability against everyone, including you: while it holds, the version cannot be deleted or replaced, and the date can be pushed **later** but never earlier. That is the whole point — a lock an administrator can shorten protects against accident but not against an insider or ransomware, so the strict flavour is deliberately built so nobody can lift it. When an erasure obligation lands on a locked record, the platform offers no override, so the remaining move is to make the bytes meaningless rather than absent: destroy the key material the record was encrypted under, and record why. The durable fix is upstream — scope locks to the records that genuinely carry a retention duty, and keep erasable personal data out of that scope, ideally in a separate store.
code
json · 13 lines{
"key": "records/2031/scan-00412.tiff",
"versionId": "v3",
"retention": {
"retainUntil": "2038-01-01",
"shortenAllowed": false,
"extendAllowed": true,
"appliesTo": "this version only"
},
"holds": [
{ "name": "matter-open", "indefinite": true }
]
}go deeper
Recall that a retention lock stops a version being deleted or replaced until a stated date, and that the date can be extended but not brought forward. That asymmetry is the idea.
Explain why the unliftable flavour exists: the threats it addresses assume the attacker already holds administrator credentials, so any lock an administrator can shorten defeats itself. Distinguish a dated retention from an indefinite hold.
Show what you do when erasure meets the lock: check whether the retention duty genuinely overrides, make the record unreadable through key destruction where it does not, clean the unlocked copies, and document the collision rather than seeking an override that does not exist.
Own the policy before anything is locked: which record classes carry a duty, how long, which flavour, and where erasable personal data lives instead. A misconfigured strict lock is the one decision here with no remediation path at all.
## What a retention lock is **Versioning** makes a mistaken write or delete reversible. A **retention lock** goes further: it makes a version *un-removable* for a stated period, enforced by the store itself rather than by policy or convention. While the lock holds: - The version cannot be deleted, by any caller, including the account's own administrators in the strict form. - The version cannot be modified — object stores replace rather than edit, and the replacement is blocked too. - The retained-until date can be moved **later**. It can never be moved earlier. That asymmetry is the mechanism. A lock you can shorten is a policy; a lock you cannot shorten is a guarantee, and only the second one survives the threat it exists for. ## Why 'cannot be shortened' is the feature The threats retention locks address are precisely the ones where the attacker has your credentials: - **Ransomware** that encrypts or deletes the stored copies after compromising an operator account. - **An insider** removing the record that incriminates them. - **A regulator's requirement** that a record demonstrably existed, unaltered, for a stated number of years. Every one of those is defeated by a lock an administrator can lift, because the attacker is an administrator. Providers therefore usually offer two flavours, and the distinction is worth stating in an interview without naming anyone's product: | Flavour | Who can shorten or lift it | Protects against | |---|---|---| | The permissive form | a specially privileged administrator, leaving an audit record | accident, a careless job, an ordinary compromised account | | The strict form | nobody, for the retained period — not the account owner, not the provider's support | a determined insider, ransomware, and a regulator's questions | | An indefinite hold | whoever may release it; no date involved at all | an open matter, where the end date is genuinely unknown | The indefinite hold is a separate control layered on the same version: it blocks removal with no expiry until explicitly released, which is what an open investigation actually needs. ## The day an erasure request meets the lock An individual's erasure request and a statutory retention duty are genuinely in tension, and the platform does not resolve it — it enforces whichever one you configured. If a record carrying personal data sits under a strict lock with years to run, there is no call that removes it, no support escalation, and no override. What is actually done: 1. **Check whether the record is in scope for the retention duty at all.** Frequently the locked object is a scanned document that the business has a legal obligation to retain, and the obligation genuinely overrides erasure for that record. Then the answer is to say so, with the retention basis, and record the decision. 2. **Where it does not override, render the record unreadable rather than absent.** If each record is encrypted under key material you control, destroying that material makes the retained bytes meaningless while leaving them physically present under the lock. This is the standard technical answer, and it must be a deliberate design — you cannot retrofit per-record key separation after the lock is on. 3. **Suppress the record everywhere it is *not* locked.** Indexes, search stores, caches, derived exports and downstream copies are usually the parts a person actually experiences, and none of them need to be under the lock. 4. **Record the collision.** The fact that a lock prevented removal, with the retained-until date, is itself the evidence that the obligation was handled rather than ignored. ## Designing so the collision is rare The senior answer is not a clever escape; it is that this should have been decided before anything was locked: - **Scope locks narrowly.** A lock applied to an entire store by default eventually covers data nobody intended to freeze. Apply it to the class of records that carries the duty. - **Separate erasable data from retained data.** Keep personal data that may need erasing out of the locked store, and reference it rather than embedding it in the locked record where the retention duty permits. - **Choose the period from the obligation, not from caution.** 'Lock it for a very long time to be safe' is how a cost problem and a legal problem are created simultaneously — you cannot delete to reduce spend either. - **Pilot the strict flavour before standardising it.** A misconfigured strict lock on a large store is unfixable by definition, and that is the one mistake here with no remediation at all. ## What a lock is not A retention lock is not a backup: it preserves a version inside the same store, not a copy elsewhere. It does not replicate itself to other stores unless configured to. And it says nothing about who may *read* the record — immutability and access control are separate mechanisms, and a locked object with an over-broad read policy is still exposed.
- Two flavours of retention lock are usually offered. How do they differ, and when is the weaker one right?One can be shortened or lifted by a specially privileged administrator, leaving an audit record; the other cannot be lifted by anyone for the retained period. The permissive form is right when the threat is accident — a careless job or a wrong prefix. Only the strict form survives a determined insider or ransomware, because there the attacker holds administrator credentials.
- What does an indefinite hold add over a retained-until date?It blocks removal with no expiry, until someone explicitly releases it. That fits an open matter whose end date is unknown, where a fixed date would either expire too early or be set absurdly far out. The two compose: a version under either one cannot be removed.
- Does a retention lock protect the record from being read by the wrong people?No. Immutability and authorization are separate mechanisms. A locked version is guaranteed to still exist and to be unaltered; who may read it is decided entirely by the permissions on the store and on the caller. A locked object under an over-broad read policy is exposed and unremovable at once.
saying these in an interview costs you the question
- Thinks a privileged administrator can always lift a strict retention lock
- Applies a long lock to an entire store by default
- Assumes an erasure obligation overrides the platform's lock
- Believes a lock can be cleared by rewriting the object under the same key
- Treats a retention lock as a backup of the record
- Thinks deleting the surrounding store removes the locked versions