Three high threats, one sprint before a ticketing on-sale: how do you run that trade-off with the product VP?
answer
- options with prices, not a demand
- some exposure ends with the event
- temporary controls are legitimate answers
- state the cost of waiting
- scope decisions belong to the scope owner
basics
~20 sBring priced options, not a demand: for each threat, a full fix, a partial mitigation, detection only, or a temporary control for the event. Then state what the deferred one costs, over what window, and get it owned and dated.
solid answer
~50 sI never open with "these three are critical". I decompose each threat into a ladder of responses - engineered fix, partial mitigation, detect-and-respond, or a temporary operational control that lives only for the event window - each with a cost and a lead time. That ladder is what makes a sprint fit: for a threat whose exposure exists only during the on-sale hour, a per-account cap, a hold timeout and a staffed room buy most of the risk reduction for a fraction of the engineering. Then I make the deferral explicit in the VP's units: the exposure window is the on-sale itself, the loss looks like an unbuyable checkout during the only hour that matters plus the refund and support tail, and it returns at the next on-sale. The VP chooses. I want that choice recorded with an owner and a date, not a nod in a corridor.
go deeper
Know that not every identified threat gets fixed immediately, and that deferring one is a legitimate outcome as long as somebody owns the decision and it has a date to come back on.
Be ready to break a single threat into more than one possible response - full fix, partial mitigation, detection only, or a temporary control for an event - and to say roughly what each costs and how long each takes.
Show you can price a deferral in the business's own units: the exposure window, what a realistic bad day looks like inside it, and what evidence you will collect during the event to re-rate the threat afterwards.
Own the negotiation, not just the analysis. Expect to keep the scope decision with the person who owns the scope, to refuse a fix shallow enough to be theatre, and to leave with a recorded, dated call rather than an understanding.
## Why "three critical threats" is the wrong opening Bringing three unmitigated threats and a request to fund all three puts the other person in a position where every answer is bad: fund it and lose the feature, or refuse and own being the one who overruled security. People in that position defer the meeting. The senior version of this conversation is not a request, it is an **option set with prices**, and it works because it converts an argument about importance into a decision about spending. ## Build the ladder before you build the slide Every threat has more than one possible response, and the cheap rungs are what make a sprint fit. For each one, work out: 1. **Engineered fix** - the design change that removes the capability. Real cost, real lead time, permanent. 2. **Partial mitigation** - narrow the path rather than close it. A cap, a default-deny, a field masked until a condition holds. 3. **Detect and respond** - do not stop it, see it and react. Cheap to add, needs someone actually watching. 4. **Temporary operational control** - a lever that exists for the event and is reverted afterwards: a toggled rate limit, a shortened timeout, a staffed room with the authority to intervene. A plausible on-sale model produces three very different threats: | Threat | Character | Sensible rung | | --- | --- | --- | | The inventory-hold endpoint has no per-account cap, so a bot fleet can hold the whole allocation | Denial of service - availability, and the revenue behind it | Temporary controls for the event, engineered fix after | | The promo-code path trusts a client-supplied discount amount | Tampering - money, permanently, on every sale | Engineered fix, this sprint | | An internal hold-release endpoint is reachable without the operator role | Elevation of privilege - insider or anyone inside the network, any day | Engineered fix, this sprint - usually a small authorisation change | Two of those ship because they are small and their exposure is not bounded by the event: the discount flaw leaks money on every future sale, and the missing authorisation check is exploitable on an ordinary Tuesday. The expensive one is the one whose exposure **ends when the event does**, and that is exactly the profile a temporary control fits. ## The test for a temporary control A temporary operational control is a legitimate answer when two things hold: - **The exposure is genuinely bounded by the window.** Once the allocation is sold, holding inventory buys an attacker nothing. - **The control is staffed and reversible.** A cap and a timeout are only as good as somebody watching the hold-to-purchase ratio with the authority to void holds in bulk mid-event. It is the wrong answer when the threat leaves lasting damage - data taken, records altered, credentials harvested - because there is nothing to revert afterwards. That distinction is the whole judgment call, and an interviewer is listening for it. ## Price the deferral in their units The deferred threat needs a sentence the VP can weigh against feature work: > If the hold cap waits, our exposure is the on-sale hour itself. The realistic bad day is that automated clients take the allocation in the first minutes, real buyers see an empty inventory during the only hour that matters, and we spend the following week on refunds, support volume and a public story about the on-sale. The temporary controls cut that materially but not to zero, and the exposure returns at the next on-sale unless the fix lands first. No invented percentages. The credible version is a described bad day plus a bounded window, not a fabricated likelihood. ## Keep the scope decision with the scope owner If the answer is "do all three properly and do not slip the feature", the honest response is not heroics. Shipping three rushed, untested security changes into an on-sale is itself a risk - a wrong authorisation change can lock out legitimate operators during the event. Put the cheapest credible rung on each back on the table, and if the answer is still all three at full depth, then something in the sprint slips and **that decision belongs to the person who owns the scope**. Absorbing it quietly is how a team ends up with shallow fixes and a security function blamed for the outcome either way. ## Close the loop after the event The deferral carries a date and an owner so it comes back on its own. After the on-sale, it returns to the model with evidence attached: what the hold-to-purchase ratio actually looked like, whether the temporary lever was exercised, and whether the exposure estimate held. If the next on-sale is scheduled before the review date, the date moves in, not out. That is what stops a temporary control from quietly becoming the permanent architecture.
- The VP says all three should ship and asks you to find a way. What do you do?I make the cost visible rather than argue. All three at full depth means either the feature slips or the fixes are rushed and untested, and a bad authorisation change shipped days before an on-sale is its own risk. I put the cheapest credible rung on each back on the table. If the answer is still all three at full depth, then something slips, and which thing slips is the VP's call to make out loud, not mine to absorb.
- How do you decide when a temporary operational control is enough for the event?Two tests. Is the exposure genuinely bounded by the window - does the attacker gain nothing once the event ends? And is the control staffed and reversible, with someone watching and authorised to intervene mid-event? Volume-driven threats against a timed event usually pass. A threat that takes data or alters records fails, because there is nothing to revert afterwards.
- What happens to the deferred threat after the on-sale?It goes back on the model with the event's evidence attached: what the traffic actually looked like, whether the temporary lever was used, and whether the exposure estimate held. The deferral carries a date and an owner precisely so it returns on its own rather than depending on anyone's memory. If another on-sale is scheduled before that date, the date moves in rather than out.
It is the difference between telling a builder the roof is unsafe and handing them three quotes: replace it, patch it, or put buckets out and stay home during the storm - with what each costs and what each leaves you exposed to.
saying these in an interview costs you the question
- Labelling all three critical, so nothing is ranked
- Bringing a demand instead of priced options
- Treating a temporary event control as a permanent fix
- Absorbing the scope decision instead of surfacing it
- Deferring with no date, owner or review trigger
- Pricing the deferral in engineering effort, not business loss