Turning a threat model into an accountable artifact — every risk scored, mitigated, and owned
Day 48 of 60
On Day 3 you built a threat model: a ranked list of what could go wrong. That's the Map step. Today you build the artifact that makes the Manage step real — the risk register. A register takes each risk and adds the two things a threat model leaves out: a mitigation (what we'll do about it) and an owner (who's accountable for doing it). Without those, a risk is just a worry someone wrote down. With them, it's a commitment.
A risk without an owner is a risk nobody fixes. The single most important column in a register isn't the score — it's the owner. The score tells you what matters; the owner is what turns "we should" into "she will, by Friday." That column is the difference between a register and a wish list.
"Jailbreak elicits weapons uplift," not "jailbreaks." A register entry names a specific bad outcome you can mitigate and detect, drawn from your threat model and taxonomy work.
Same discipline as your threat model: score each on probability and severity, multiply, and sort descending. The product decides what the organization fixes first. A rare-but-catastrophic risk and a common-but-mild one both stay visible without pretending they're equal.
What concrete control reduces this risk? Tiered evals, an output filter, an input-provenance check, an RSP gate. Each mitigation should trace back to something you know how to build or measure from Parts A and B.
Safety, Product Security, Evals — a function (or person) on the hook for this risk. Ownership is what makes a register a live document instead of a snapshot that rots.
In the Try This box is risk_register.py — a minimal, runnable register that scores each risk by likelihood × impact, attaches a mitigation and an owner, and sorts so the highest-priority risk surfaces first. Run it, read the sorted output, then replace its entries with risks for a deployment you actually understand. Notice that the moment you add an owner column, the conversation changes from "is this scary?" to "who's fixing it, and when?"
Write 6–10 register entries for one concrete system, spanning all three risk types (misuse, accident, systemic). Score and sort them. Then do the honors move: map each risk to a NIST AI RMF function, and add a residual-risk-after-mitigation estimate — because the risk you accept after mitigating is the number a sign-off actually rests on.
risk_register.py from the Try This box and read its sorted output. Confirm you understand why the owner column exists.A novice produces a risk list — flat, ownerless, a record of concern. An expert produces a risk register — scored, mitigated, owned, and mapped to a framework — because the register is the thing a deployment decision actually rests on. The altitude jump is from cataloguing fears to running an accountable process where every top risk has a name attached to fixing it.
Say this in an interview: "I don't hand a team a list of risks — I hand them a register: each risk scored by likelihood × impact, mapped to a concrete mitigation and a named owner, and tied to a NIST AI RMF function. The owner column is the whole point. A risk nobody owns is a risk nobody fixes, and a register without residual-risk estimates can't support a real sign-off."