How do you retire a threat model for a decommissioned service so it stops being cited as evidence?

## Why a dead model is a live problem When a service is switched off, its threat model does not become harmless - it becomes a *false positive in the assurance record*. Someone assembling evidence for a customer questionnaire, a certification, or an internal control attestation finds a model with a plausible date and a full set of mitigated threats, and includes it. Two years after a coupon-redemption monolith stopped serving traffic, its model can still be sitting in an assurance pack as proof that the redemption capability is modeled. The asset at stake here is **audit truth**: the organisation's ability to state accurately what it has and has not analysed. Three concrete harms follow. 1. **Coverage is overstated.** The estate looks better modeled than it is, so effort is not directed at what is genuinely unexamined. 2. **The successor is invisible.** Redemption did not disappear; it moved into another service, most likely one that was never modeled. The dead model actively conceals that gap, because the capability appears to be covered. 3. **Stale controls are lent current status.** "Mitigated by the tokenisation service" was true of a system that no longer exists; nothing verifies that the claim holds for whatever replaced it. ## Model lifecycle as the fix A model needs the same metadata any controlled record needs: - **Scope statement** - which system, which release or version range, which environments. "The coupon-redemption monolith, as deployed in production, release 2024.3." - **Status** - one of *draft*, *current*, *under review*, *superseded* or *retired*. Absent status is the root cause of most of this; a file with no status defaults, in every reader's mind, to current. - **Last verified** - the date the model was last reconciled against the running system, and what evidence was used. A model dated by its authoring date only tells you when someone drew a picture. - **Successor pointer** - what supersedes it, whether that is a newer version of the same model or a different system's model that absorbed the capability. ## Retirement as a recorded state change Retiring is not deleting. Deleting destroys the history an incident review or an audit legitimately needs - the model as it stood when a decision was made is evidence about that decision. Retirement means: 1. **Evidence of decommission** - the deployment removed, the routing gone, the credentials revoked, the data disposed of or migrated. The service owner asserts it; the assurance function records it. 2. **A status change on the record**, with the date and the reason, and the pointer to the successor system or the model that absorbed the threats. 3. **Disposition of anything still open.** Open threats do not evaporate with the compute. Either the risk is genuinely gone with the system, or the functionality moved and the threat belongs to the successor's model. Say which, per item. 4. **Removal from the live set** that reporting and assurance draw on, while the artefact remains readable in history and visibly stamped, so a stray copy cannot masquerade as current. ## The structural fix: an index, not attachments The reason a dead model keeps appearing is almost always that assurance packs are **assembled from copies**. Once a PDF is in a shared folder or a customer's data room, no status change reaches it. The durable fix is that the pack is generated from a live index of models, each entry carrying system, status, last-verified date and owner, so what a reader receives reflects the current state at the time of generation. Copies then become obviously dated snapshots rather than the record. ## Do not retire too early The most common misjudgement is retiring on the decommission announcement rather than the decommission. Partial states are normal and each keeps some of the model alive: - **Traffic off, data retained.** Two years of redemption records still sit in a database with access paths, backups and operators. The confidentiality exposure is intact. Keep a reduced model covering the retained store, its access paths, and the scheduled deletion date; retire it when the data is gone. - **Endpoint still resolving.** DNS or a load-balancer rule still points somewhere. Anything still reachable is still in scope. - **Credentials and integrations still valid.** Partner API keys, queue permissions and service accounts often outlive the service they were minted for, and are precisely the kind of forgotten path an attacker likes. ## Who decides Make the decision two-sided. The **service owner** asserts decommission with evidence; the **assurance or security function** records the status change and disposes of open threats. A modeler retiring a model unilaterally is how a system that is still running quietly loses its coverage - the opposite failure, and a worse one. ## The judgment to voice in an interview A smaller library of models with honest status is worth far more than a large one where a reader cannot tell live from dead. Say that you would rather report lower coverage accurately than higher coverage that includes retired systems - and that you would treat the number of models with no status or no verification date as a defect to be driven down, because those are the ones that will be cited by someone who does not know better.