How do you set threat-modeling cadence between modeling every story and modeling once?

## Why cadence is a real decision Once a team accepts that threat modeling should happen more than once, the next question is how often — and the two easy answers are both wrong. "Model every story" and "model once at kickoff" are the same error in opposite directions: each picks a fixed rhythm instead of following the thing modeling is supposed to track, which is change to the design. ## The model-everything trap An insurance claims team that runs a threat model for every item in the tracker will, after a few months, be producing near-identical documents sprint after sprint. Most stories in a mature product do not change the design: they add a field, adjust a rule, fix a defect, improve a screen. A model of such a story restates the same actors, the same flows and the same handful of threats that the last one did. The damage is not mainly the hours spent. It is attention. When every model looks like the last one, reviewers skim, then stop reading, and the one model in twenty that describes something genuinely new — a new external caller, a new data class — arrives in a stack of noise and is skimmed too. A practice that produces output nobody reads has negative value, because it also produces the belief that the design is covered. The useful diagnostic is exactly that repetition. If consecutive models are near-identical, the granularity is wrong. The response is to move the modeling up a level, not to produce the same documents faster or with a slicker template. ## The model-once trap The opposite failure is the kickoff model: one thorough session at project start, a diagram and a threat list filed somewhere, and nothing after. Within a couple of quarters the system has acquired integrations, a new store, an admin surface and a second consumer, and the filed model describes an architecture that no longer exists. Worse, its existence is used as evidence of coverage, so nobody asks for another one. A model that no longer matches the system is not neutral; it actively misleads the next person who reads it. ## What to do instead: bind cadence to design decisions The unit that should carry a model is the unit at which design decisions get made. In most teams that is the epic, the design document, or the architecture change — not the story, and not the project. Concretely: - **Full session at design-decision granularity.** When a design doc is written or an epic is planned, run the session while the design is still cheap to change. This is where the value is: threats found here are edits to a diagram, not to production. - **Cheap filter at story granularity.** Every story carries a few yes/no prompts — does this add a component, a caller, a data class, or change who can reach an existing one? Answering takes seconds and the overwhelming majority answer no. That is the design working, not failing: the filter's job is to catch the small minority that slipped in below epic level, such as a config change that quietly exposes an internal endpoint. - **Out-of-band trigger for incidents.** Incidents do not respect sprint boundaries, so they fire a session directly rather than waiting for the next planning cycle. ## Answering the manager who wants a number Interviewers often push for a fixed number — every sprint? quarterly? The honest answer is that a fixed interval is a fallback for systems that are not changing, and change is what you should be measuring. Two measures work better than a cadence number: the proportion of design changes that shipped with a model attached, and the count of genuinely new threats found per session. When the second number falls to near zero across several sessions, the system is stable and you should model less often, not keep the ritual for its own sake. ## The failure worth naming out loud The subtle risk in the middle path is that the per-story filter becomes a rubber stamp — checked "no" by habit without reading. The countermeasure is to keep it short, keep the prompts concrete rather than asking "any security impact?", and to review the answers when a change turns out to have needed a model. The point of the filter is to be cheap enough that honesty costs nothing.