What makes the attacker persona behind an evil user story useful rather than a caricature?
answer
- does it change a design decision?
- access they already hold today
- attackers satisfice, not maximise
- what will they not risk?
- attribution-averse means evidence deters
basics
~20 sA useful attacker persona states the access the person already holds, what they want from this specific system, what counts as good enough for them, and what they will not risk. A caricature states only a label.
solid answer
~50 sA persona earns its place when it changes a design decision. So it has to carry four things: the access this person legitimately holds today, the goal they want from *this* product, what they would accept as good enough, and the thing they will not risk. On a B2B procurement marketplace, "a rival supplier's account manager, logged in as a real tenant, who wants the winning price before the close, would settle for a narrow price band rather than the exact number, and will not do anything that could be traced back to their corporate account" tells the team something. "An industrial spy" tells them nothing. The last clause is the one people skip and it is often the most useful, because a persona who fears attribution is stopped by evidence and traceability, while one who does not is only stopped by prevention.
go deeper
Know that the persona is the narrator of an evil user story and that it should say what access the person already has, not just call them an attacker.
Be able to write one: current access, goal against this product, what they would settle for, and what they will not risk. Explain why an insider persona usually produces more useful stories than an outsider one.
Show that the persona drives control selection — an attribution-averse insider can be deterred by visible evidence, while someone with nothing to lose needs prevention. Name a case where the good-enough clause exposed an inference channel a team had missed.
Own the persona set for a product: how few there are, who maintains them, when a new product surface earns a new one, and how to stop them collecting biography that never changes a decision.
## What the persona is for An evil user story needs a narrator. The persona is that narrator, and the only test that matters is whether it changes a design decision. If you can delete the persona and the resulting work is identical, it was decoration. ## Four things a working persona carries **1. The access they already hold.** Not what they might achieve — what they can do right now, legitimately. A logged-in tenant. A reviewer assigned to a submission. A courier with an active shift. This is the single most load-bearing field, because it decides which flows the story can even reach and it usually reveals that the interesting adversary is inside the system rather than outside it. **2. The goal, expressed against this product.** "Wants money" is not a goal. "Wants the winning bid price before the auction closes" is, because it points at one screen, one export and one notification. **3. What good enough looks like.** Attackers satisfice. A rival bidder does not need the exact winning number; a price band that is narrow enough to undercut is a win. This matters because teams routinely design a control that blocks the perfect outcome and leaves the good-enough one wide open — rounding a figure, rate-limiting an export, or hiding a field that is still inferable from a sort order. **4. What they will not risk.** A persona with a corporate identity, a professional reputation or a payroll record behaves very differently from one with neither. Someone who cannot afford attribution is deterred by evidence: an access log the account holder can see, a notification to the other party, a record they know is retained. Someone with nothing to lose is deterred only by prevention. Skipping this clause is why teams reach for a preventive control by reflex when a detective one would have been cheaper and enough. ## Two personas that pull in opposite directions On a **conference peer-review platform**, the persona is a reviewer: a trusted, privileged insider with an assigned submission who wants to learn the author's identity before scoring it. The asset is process integrity and the authors' anonymity. This persona is highly attribution-averse — they intend to keep their standing in the community — so the story is met well by making the attempt visible and attributable, and badly by a control that merely makes de-anonymising slightly inconvenient. On a **B2B procurement marketplace**, the persona is a rival supplier's account manager, an ordinary paying tenant who wants the winning price before the close. The asset is trade-secret commercial information. Here the same attribution-aversion applies but the good-enough clause dominates: any inference channel that narrows the price is a success, so timing differences, aggregate statistics, ordering of results and even a "you were outbid" nudge are in scope, and a control that hides only the literal number solves nothing. ## How personas go wrong **They become labels.** A one-word tag with no access level and no goal cannot be argued with, so it cannot be wrong, so it teaches nothing. **They are all external.** A product's most valuable adversary is usually someone the system already trusts, and a set of personas that are all anonymous outsiders produces a set of stories about the login page. **They accumulate biography.** Backstory, tooling preferences and a photograph are not decisions. Anything in the sheet that never gets cited in a design argument should be cut. **They are written once and never revisited.** Personas track the product. Adding a partner API, a support console or a marketplace of third-party integrations adds a persona; nobody notices unless someone owns the sheet. **They drift into rating.** A persona describes who and what they are after. How likely and how bad the outcome is belongs to the risk conversation that follows, and folding it into the persona hides the assumption inside a character sketch where it stops being challengeable. ## Where to keep it One short sheet per product, a handful of personas, each two or three lines, referenced by name from the evil user stories so the stories stay short. When a story's persona is not on the sheet, that is the signal to either add it deliberately or admit the story was invented rather than derived.
- Why does a persona's tolerance for being identified change which control you pick?Because it decides whether detection deters. A reviewer or an account manager with a professional identity is stopped by a visible, attributable record: they will not act if the other party can see it. Someone with no identity at stake is unmoved by logging, so only prevention helps. Skipping that clause is how teams end up buying a preventive control when a cheaper detective one would have been sufficient.
- How many personas should a product carry?Few enough that everyone remembers them — typically a handful, each two or three lines. The set should cover the distinct positions someone can occupy relative to your system rather than every conceivable adversary, and it should be revisited whenever the product opens a new position, such as a partner integration or a support console.
- A persona sheet lists tooling and backstory but no goals. What do you do with it?Cut everything that has never been cited in a design argument and replace it with the four fields that get used: current access, the goal against this product, what they would settle for, and what they will not risk. Biography feels like rigour and produces none; the test is whether removing a line would change a decision the team made.
saying these in an interview costs you the question
- Persona is a one-word label with no access level
- Every persona is an anonymous outsider
- Adds backstory that never affects a design choice
- Assumes attackers want the perfect outcome, not a sufficient one
- Bakes likelihood and impact ratings into the character sketch
- Written once at kickoff and never revisited