Which changes to a system should trigger a new or updated threat model?

## What a trigger is, and why you need explicit ones A modeling trigger is the observable event that says *the threat picture of this system may have changed, so look again*. Triggers matter because threat modeling has no natural rhythm inside a delivery process. Nothing in a sprint reminds anyone to do it, so in the absence of written triggers teams fall into one of two failures: they model once at project kickoff and never again, or they try to model continuously until the practice collapses under its own weight. A trigger is not the same thing as a schedule. A schedule fires on the calendar whether or not the design moved; a trigger fires on a change to the design. ## Trigger on the design, not on the diff The most common mistake is using code volume as the signal. A four-thousand-line refactor that moves logic between classes inside one service may change nothing about who can reach what. A three-line edit to an ingress rule, a cloud trust policy or a queue's access control can hand a new actor a path to data they never had. So the question a trigger asks is not "did the code change a lot" but "did the answer to *who can reach what, and what would they gain* change". ## Four trigger classes worth writing down **A new component or service.** A new process, a new data store and new flows between them are new places for something to go wrong, and new flows are where trust boundaries usually land. **A new trust boundary.** This is the trigger teams miss most, because a boundary can appear with no new code. A previously single-tenant analytics product that signs its first external customer now has a boundary between tenants: a paying customer is a legitimate actor with credentials, and other customers' data is an asset that nothing in the original design was built to protect. The same shape appears when an internal-only service is opened to a partner network, when an operator group gains standing access, or when a workload starts running under an identity another team also controls. **A new class of data.** New data changes what an attacker gains, which changes which threats matter. A payroll platform that adds employee bank details to an HR service which previously held names and job titles has created a money asset where there was only a privacy asset. The plausible adversary shifts too: the realistic threat is a malicious insider in HR operations who already has legitimate read access and could redirect a salary payment, not an anonymous stranger on the internet. A model written before that data class arrived will not have considered integrity of payment details at all. **A security incident.** An incident is evidence that an assumption the design leaned on was false. Suppose a regional electricity utility finds that a stolen field technician's laptop held a shared meter-provisioning credential. Two design assumptions just died: that technician devices are trustworthy custody, and that provisioning identity is per-person and revocable. The consequence class here is the safety and availability of a physical process, not data theft. The value of the post-incident model is not documenting the incident — that belongs to the response record — it is finding every other place resting on the same assumption. ## What should not fire a trigger Dependency upgrades, cosmetic UI work, internal refactoring, adding capacity, and bug fixes that restore intended behaviour do not on their own change the threat picture. They earn a model only when they alter exposure, privilege or the data held. Keeping this list explicit is what stops a trigger policy from degenerating into "model everything". ## Making triggers operational A trigger only works if it sits where the change is described, not in a policy document nobody opens. In practice that means a short set of yes/no prompts on the design-doc or change template: does this add a component, a caller, a data class, or change who can reach an existing one? Keep it to a handful of questions — a long form gets auto-answered "no". Pair it with a named owner, because the third failure mode, after model-once and model-everything, is the trigger that everybody agrees with and nobody owns, so security hears about the new boundary after launch.