Would you mandate one threat modeling method across every team, or let each team choose?

## What each extreme actually buys and costs **Full mandate.** The benefits are real and often understated. One method means training material you write once and facilitators you can move between teams. It means a reviewer opens any model and already knows where to look. It gives you a crude but genuine ability to compare across systems: when every model uses the same vocabulary, "team A found nothing in this category and team B found eleven things" is a signal rather than an artifact of format. It also makes tooling, templates and review checklists worth building. The cost is fit. The same method is imposed on a team with a security engineer and a team without one, on a product under external scrutiny and on an internal tool. Where it does not fit, you do not get a bad threat model - you get a *performed* one. A diagram appears in the repository the week before the audit, nobody revisits it, and the organization now has documented false assurance, which is worse than an honest gap. **Free choice.** Fit improves and adoption usually does too, because each team picks something it can sustain. The cost is that nothing is comparable, reviewers must learn every dialect, quality varies invisibly, and there is no way to answer "are we covered?" at the portfolio level. Free choice also tends to drift downward under deadline pressure - every team independently discovers the cheapest thing that satisfies the requirement. ## The position worth defending A default plus a governed exception path. Concretely: 1. **Pick a house default matched to the median system**, not the scariest one. If most of what the organization builds is ordinary service-to-service software, the default should be something engineers can run themselves in a couple of hours. 2. **Publish the selection criteria** - team maturity, system risk profile, regulatory or contractual driver, time budget, output consumer - so the decision is a shared one rather than a negotiation with the security team each time. 3. **Sanction two or three alternatives** for the cases the default handles badly. A product processing personal data under privacy regulation needs privacy-typed elicitation such as LINDDUN, whose seven threat types include linking, identifying and unawareness - concerns a security-category walk simply never raises. A safety-relevant or externally audited product needs an asset- and harm-centric flow with a traceable artifact. 4. **Require a short written rationale to deviate**, reviewed but rarely refused. The point is the record, not the gate. 5. **Fund facilitation where depth is warranted.** Mandating a method you cannot staff creates a queue, and a queue creates the ritual compliance you were trying to avoid. ## The case that stress-tests the position A B2B SaaS team's largest customer sends a due-diligence pack that demands a threat model artifact. The consumer here is an external reviewer, and the asset at stake is audit truth and the customer relationship - not, on this occasion, a specific attacker path. That team needs a formal, traceable output on a schedule set by someone outside engineering. If your house default produces workshop notes, forcing it on this team is actively harmful; the alternatives list exists exactly for this. Equally, if you had mandated *that* team's method organization-wide because it satisfies auditors, you would have imposed audit-grade formality on every internal tool in the company. ## Measuring the programme without corrupting it Count of models produced is the metric that guarantees theatre, because it is the easiest number to satisfy dishonestly. Better signals, all harder to fake: - Models updated when the design changed, not only at project kickoff. - Design decisions that visibly changed because of a finding. - Threats consciously accepted with a stated reason - a team that reports zero accepted risks is not being careful, it is not being candid. - Whether engineers run sessions without a security facilitator present, which is the real maturity indicator and the thing that eventually lets you raise the default. ## Revisit deliberately Set a review cadence for the default itself. The right default for a fifty-engineer organization with two regulated products is not the right default three years later. Announcing that the choice will be revisited also lowers the temperature of the initial decision, which is worth a lot when the alternative is a year-long standards argument.