How do you judge whether a mitigation's cost is justified by the loss it prevents?

## The question behind the question Interviewers ask this to find out whether you can argue against your own instinct. A security engineer who says "it is a real threat, so fix it" cannot run a programme, because every real threat competes with every other real threat and with the product. The skill is building a defensible comparison and knowing where the comparison stops being valid. ## The worked example A used-car marketplace suffers account takeovers: attackers with credentials from elsewhere log into seller accounts, change payout details and intercept sale proceeds. The asset is money, the attacker position is an outsider with valid credentials, and the proposed mitigation is device binding — tying a session to a recognised device and challenging anything else. Engineering says a quarter of work plus ongoing support. Product says it will cost conversion. That is the shape of the decision. ## Building the loss side Expected loss over a window is likelihood times impact — but the useful version is built from what you already measure, not from a guessed probability: - direct loss: funds reimbursed, chargebacks, fraudulent payouts; - operational loss: support and investigation hours per case, times case volume; - indirect loss: churn of affected sellers, and the acquisition cost to replace them; - what you cannot price: regulatory attention, press, and the trust of the sellers who did not get hit but heard about it. State the last category explicitly as an unpriced floor rather than either ignoring it or inventing a number for it. Fabricated precision is the classic failure: a spreadsheet with three decimal places built on a made-up likelihood is less honest than a range with its assumptions written next to it. Also decide what portion of that loss the control actually removes. Device binding does not stop every takeover; if it removes seventy percent of a measured loss, the benefit is seventy percent, not all of it. ## Building the cost side The cost people forget is not the build: - **build**: engineering time, plus what it displaces; - **run**: the control has an owner, alerts, an exception path and a failure mode, forever; - **support**: recovery for customers who legitimately lose a device; - **friction**: conversion or engagement lost when a real user is challenged. If the marketplace loses even a small share of logins to abandonment, that number can dwarf the fraud it prevents — and it is a genuine cost, not a product objection to be argued away. ## Looking for the cheaper control first Before accepting a threat on cost grounds, ask whether a smaller control captures most of the benefit. Challenging only anomalous sessions, or gating only the payout-detail change rather than every login, often removes most of the loss for a fraction of the friction. "The full control is not worth it" and "nothing is worth it" are different conclusions, and interviewers listen for whether you looked for the middle option. ## Where the arithmetic does not decide Three cases: 1. **Tail risk.** When a rare event could end the company or cause irreversible harm, the expected value is misleading precisely because it averages away the outcome you cannot survive. Here the right moves are avoidance by redesign, capping the blast radius, or financing the tail — not a favourable average. 2. **Floors you do not get to price.** Legal and regulatory minimums, contractual commitments, and anything touching physical safety are constraints, not inputs. A cost-benefit argument against a legal floor is not a sophisticated answer; it is the wrong answer. 3. **Losses that land on someone else.** If the loss falls mostly on users rather than the business, expected loss to the business systematically under-values the fix. Say so out loud, because the arithmetic will otherwise quietly encode the externality. ## What you produce The deliverable is not a number, it is a comparison with its assumptions visible: the measured loss over a stated window, the fraction the control removes, the full cost of the control including friction, the cheaper alternatives considered, and the explicit list of what was not priced. The accountable owner decides; the assumptions are what let the decision be re-opened when fraud triples, when the control's friction turns out lower than feared, or when a regulator changes the floor. Recording the assumptions is also what separates this from a one-off argument you have to win again every quarter.