What are the four treatment options for a threat found in a design review?

## What a "treatment" is A threat model produces a list of things that could go wrong, each with a rating. The rating is not the output — the **decision** is. For every threat that survives the ranking, someone has to say what the organisation is going to do about it, and there are exactly four things it can do. Getting the vocabulary right matters in an interview because candidates who only know "fix it" cannot explain the ninety percent of real findings that are not fixed this quarter. Keep the four ideas separate from the four words that surround them: - a **threat** is what could go wrong (an attacker replays a captured session token), - a **vulnerability** is the flaw that lets it (tokens never expire), - a **risk** is the rated consequence (likely, and it exposes customer orders), - a **control** is what you do about it (short expiry plus binding). Treatment is the decision layer that sits on top of the risk. ## Mitigate Mitigation keeps the design and adds a control that reduces likelihood, reduces impact, or both. Preventive controls (input validation, authorization checks, short-lived credentials) attack likelihood; detective and limiting controls (rate limits, anomaly alerting, blast-radius reduction, backups) attack impact and time-to-notice. Two things people get wrong here. First, a mitigated threat is not a closed threat — the control is partial, can fail, and can be bypassed, so what remains is **residual risk** and it deserves a fresh rating. Second, a control has an operating cost forever, not just a build cost; a mitigation nobody maintains decays into a claim on a slide. ## Avoid (by redesign) Avoidance removes the conditions the threat depends on: the asset stops existing, the flow stops crossing the boundary, or the feature is dropped. The loyalty service that stops storing raw card numbers and redirects the payment leg to the processor no longer has a card-database-theft threat to rate — there is no card database. Avoidance is the treatment that design-time modeling uniquely unlocks, and it is why threat modeling early beats threat modeling late: at design time "do not collect it" and "do not let that flow cross the boundary" are still cheap. After launch the same move costs a migration. The honest caveat is that avoidance is a trade against product value. Deleting the feature deletes the threat and the revenue with it. Redesigning the flow so the sensitive data never enters your trust boundary usually keeps both, which is why it is the version worth arguing for. ## Transfer Transfer moves the financial consequence of a loss to someone else — an insurer, or a supplier who takes contractual responsibility for that part of the system. What it does **not** do is equally important, and interviewers probe exactly here: - it does not change the likelihood that the attack succeeds; - it does not move accountability to your customers or your regulator, who still come to you; - it does not cover the operational consequence — the outage, the incident response, the reputational hit; - it pays only within the terms, and policies carry exclusions. A logistics firm insuring an unpatchable legacy partner-facing gateway can find that the loss it actually suffers — one caused or assisted by its own staff — sits in an exclusion, and that the contractual liability it owes partners was never the insured amount. Transfer is a legitimate treatment for a low-likelihood, high-financial-impact threat you cannot economically mitigate. It is never a substitute for a control on a threat that is likely. ## Accept Acceptance is a decision to carry the risk knowingly. It is not "ignore it", and the difference is entirely in what is written down: who is accountable, what the residual risk is in outcome terms, what evidence and compensating controls support the call, and when the decision expires and must be made again. An acceptance with none of that is not a treatment, it is an unrecorded gamble. ## Choosing between them A workable order of preference at design time: **avoid** if the value of the flow does not justify the exposure; otherwise **mitigate** to the point where the residual risk is tolerable; **transfer** the financial tail you cannot mitigate away; **accept** what is left, explicitly. In practice one threat often gets several — redesign the worst flow, add a control on the rest, accept the remainder for a quarter while a better fix is built. The output of a treatment decision is not "done", it is a residual risk that has been named and owned.