How do you record a threat's closure so the ticket re-opens when the design that justified it changes?

### Closures are conditional, and the condition is usually invisible When a team closes a threat, they are asserting something narrower than "this can no longer happen". They are asserting "given how the system is currently shaped, this can no longer happen". The shape is the hidden variable. A control that covers every path today covers every path only until someone adds a path, and the person adding it has no idea a closed ticket depended on them not doing so. So the durable unit of a closure is not the fix. It is the **invariant**: the sentence about the system that must remain true for the closure to hold. ### A worked case A data platform modeled a nightly warehouse export — customer records leaving the transactional store for analytics, with the adversary of concern being a broad-access internal consumer and the asset being personal data of customers who had never agreed to analytics use. The agreed control was field-level minimisation and redaction applied inside the export job, and the threat's ticket closed once the job shipped and a check confirmed redaction on the output. Two releases later a reporting service was given its own read path and began pulling the same tables directly, because that was faster than waiting for the nightly file. Nothing about the closed ticket was wrong. The export job still redacted. But the closure had rested on an unwritten sentence — *all exports of this data leave through the reviewed job* — and that sentence was now false, so the threat was live again with a green ticket over it. What should have been recorded at closure: Closure of THREAT-114 Control: field minimisation inside the nightly export job Invariant: every path that moves these tables out of the transactional store goes through that job Guard: alert on any read of these tables by a principal other than the export job's service identity Re-open if: the guard fires, or a new consumer of these tables is introduced The invariant line is the one people omit, and it is the one that would have caught this. ### Making the invariant checkable Rank your options by how much they depend on someone remembering: 1. **Mechanical guard.** The invariant is expressed as something that fails on its own — a constraint, an alert on an unexpected access pattern, an assertion in the build that a second path does not exist. Best, and not always possible. 2. **Anchored review.** The ticket is anchored to the diagram element or flow it came from, so when that element changes, whoever changes it sees the closed threats attached to it. This puts the prompt in front of the right person at the right moment rather than relying on a periodic sweep. 3. **Written assumption only.** The invariant is stated but nothing watches it. This is still far better than nothing, because it converts a later argument from "was this ever considered?" into "here is exactly what we assumed, and it no longer holds". Aim for the highest tier each closure supports, and be honest on the ticket about which tier you achieved. A closure at tier three should say so. ### Re-open, do not re-file When the invariant breaks, bring back the original ticket. The temptation to file a fresh one is strong — it is cleaner, and the old discussion looks stale — but the old discussion is the asset. It contains the alternatives that were considered and rejected, the reason this control was chosen over a redesign, who agreed, and what the fix cost last time. A re-opened ticket lets the next engineer start from that position rather than re-deriving it, and it makes visible that this is the second time, which is itself important information: a threat that has re-opened twice is telling you the control sits in the wrong place, and the durable answer may be structural rather than another point fix. ### The organisational shape At scale the interesting question is who pays attention. Nobody re-reads closed tickets voluntarily, so the practice has to attach the prompt to a moment that already exists: a design change touching that component, a release that adds a consumer, an incident review that names the asset. Build the linkage so the closed threat appears in that moment, and resist building a separate ceremony for reviewing closed findings — it will be scheduled, then skipped, then quietly dropped. The cultural half matters too. If re-opening a threat is treated as a failure by whoever closed it, people will file new tickets to keep their record clean, and you lose the history the practice depends on. Re-opening should read as the system working: the closure was honest, it was written down precisely enough to be falsified, and it was falsified. That is a better outcome than a closure vague enough that nothing could ever contradict it.