Which criteria actually decide which threat modeling method a team should use?

## The question behind the question An interviewer asking "which threat modeling method would you use here?" is not testing whether you can recite methodology names. They are testing whether you understand that a method is a *tool fitted to a team, a system and a deadline*, and that the most sophisticated method available is frequently the wrong one. The failure mode this question screens for is the engineer who has read about one method and now applies it to everything. ## The five axes that actually decide it **1. Team maturity.** Ask who will run the session next quarter when you are not in the room. A category-driven elicitation that engineers can self-serve from a one-page prompt survives; a staged, risk-centric engagement that requires a trained facilitator and threat-intelligence input does not, unless you have the people to staff it. Maturity also sets vocabulary: a team that cannot yet distinguish a *threat* (what could go wrong), a *vulnerability* (the flaw that permits it), a *risk* (the rated consequence) and a *control* (what you do about it) will produce mush from any method until you teach that first. **2. System type and risk profile.** The dominant threat class should drive the elicitation vocabulary. A money-movement system wants tampering and authorization coverage on every transaction path. A platform holding personal data wants a privacy-typed method: LINDDUN's seven privacy threat types cover linking, identifying, non-repudiation, detecting, data disclosure, unawareness and non-compliance, and a security-only category walk simply never asks whether two datasets can be linked. Safety-relevant systems want an asset- and harm-centric flow that traces a hazard to a control. Architecture matters too: a monolith with two trust boundaries and a fleet of services with fifty are different problems. **3. Regulatory or contractual driver.** This is the axis engineers most often skip. If a premarket submission, a certification body or an enterprise customer's due-diligence pack is the reason the model exists, the artifact must be legible to that reader and traceable from asset to threat to control. That rules out methods whose output is a photograph of a sticky-note wall, however good the discussion was. **4. Time budget.** Be honest about hours per design and per sprint. A method that consumes two days per feature will be run once, at the launch of the effort, and then quietly abandoned; the design keeps changing and the model rots. Cadence beats depth over a year. **5. Output consumer.** Who reads this afterwards, and what do they do with it? A sprint backlog wants a short list of specific, owned, actionable items and does not care about coverage. An architecture review board wants the trust boundaries and the decisions. An external auditor wants evidence that the analysis was systematic and complete over the scope. The same system genuinely justifies different methods for different consumers. ## A worked selection A Series-A payroll startup is six weeks from its first bank-file integration and has no security engineer. Its plausible attacker is not an exotic one: it is the outsourced bookkeeping contractor who legitimately has access to the payroll console, plus anyone who can influence the generated bank file. The asset is money and employee personal data. Maturity is low, the time budget is a few hours, the output consumer is the sprint backlog, and no regulator is reading anything yet. The correct answer is a tightly scoped, timeboxed model of the money-movement path only, using a simple prompt set the engineers can run themselves - not a full staged engagement covering the whole product. The heavier method would produce a better document and a worse outcome, because it would not finish before the integration ships. Change one variable and the answer changes. If the same team were building Class-II infusion-pump firmware, with a regulator as the reader and patient safety as the asset, the sticky-note session becomes indefensible: you need an asset- and harm-centric analysis whose artifact traces each hazard to a mitigation, and you need to model the attacker with physical access to the device and to a compromised service laptop. ## Anti-patterns - Choosing on prestige ("the staged risk-centric method is more rigorous, so we use it") without checking whether anyone can staff it. - Choosing before asking who reads the output. - Treating the choice as permanent. Re-select as maturity rises: the questionnaire that fits a five-person team is not what the same team needs two years later. - Assuming one method must cover every system in the organization. ## Record the decision Write down the method, the scope it applies to, the criteria that led there, and the date. That record is what makes the next selection an update rather than an argument, and it is what you show when someone asks why this system was modeled more lightly than that one.