How to frame and mitigate risks
A short explainer on how to effectively frame a risk, capture your sense of its likelihood and severity, and act to reduce either one.
Write it as a sentence, not a topic
“Security” is not a risk. It’s a subject heading. A risk names a specific condition and the damage that follows from it, which is why the useful shape is if <something happens> then <this consequence follows>.
Too vague to act on
Key person dependency in billing
Specific enough to argue about
If the one engineer who understands our billing system leaves the company then billing changes stall for months and an outage there could go unfixed.
The second version tells you who to talk to and what to change. The first only tells you to feel uneasy.
Every risk has two dimensions
How likely is it, and how bad is it if it happens? Those are separate questions, and keeping them separate is the point of the grid. A near-certain annoyance and a once-a-decade catastrophe are both “risks”, but almost nothing you’d do about them is the same.
Likelihood
- A
- Almost certain — Expected to occur in most circumstances
- B
- Likely — Will probably occur
- C
- Possible — Might occur at some point
- D
- Unlikely — Could occur, but not expected
- E
- Rare — Only in exceptional circumstances
Severity
- 1
- Insignificant — No measurable impact on operations or finances
- 2
- Minor — Small loss or temporary inconvenience, handled internally
- 3
- Moderate — Notable impact, needs management attention, short disruption
- 4
- Major — Significant loss, reputational damage, extended disruption
- 5
- Catastrophic — Existential threat, massive financial or legal exposure
Now at D5 — high risk
Plot the two together and every risk lands somewhere. The colour is the two axes multiplied out — it isn’t extra information, it’s a reading aid.
Mitigations move it — and you can say which way
A useful mitigation does one of three things: it makes the risk less likely, it makes the damage smaller when it lands, or both. Naming which one is the fastest way to tell a real mitigation from a gesture. Turn these on and watch where the risk goes.
Reducing likelihood — moves it down
If a critical vulnerability reaches production in one of our dependencies then an attacker could read customer data for days before anyone noticed.
Now at B4 — high risk
Turn the mitigation on
Reducing severity — moves it left
If our primary cloud region suffers a multi-hour outage then the product is completely unavailable to every customer for the duration.
Now at D5 — high risk
Turn the mitigation on
Neither mitigation makes its risk disappear. The vulnerability can still reach production; the region can still fall over. What changed is how often you should expect it, or how much it costs you when it does.
Stack them and you buy the risk down
This is the part worth internalising. You rarely eliminate a risk. You buy it down — each mitigation moves it a little further toward a corner you can live with, and you stop when the next move costs more than the risk it removes. Turn all three on, then take them away one at a time.
If the one engineer who understands our billing system leaves the company then billing changes stall for months and an outage there could go unfixed.
Now at C5 — high risk
Turn mitigations on
The dashed line is the distance you bought. It’s also the honest answer to “what did we get for that work?” — a question much easier to answer when the risk was a sentence with two numbers attached, rather than a heading in a spreadsheet.