You've seen the 5×5 grid at every risk committee meeting. Probability on one axis, impact on the other, risks plotted as dots, everything color-coded red, amber, and green. It's clean. It's simple. Your board understands it.
It's also misleading you.
Probability times Impact Graphs (PIGs) persist because they're easy to build in PowerPoint and easier to explain to executives who don't want a statistics lecture. But ease of creation doesn't equal quality of insight. Academic researchers have documented the problems with risk matrices for years, yet practitioners defend them with surprising passion. Let's examine why that defense rests on flawed assumptions.
Myth 1: "Ordinal scales give us enough precision to prioritize risks"
Reality: Ordinal scales obscure the differences that matter most.
When you assign a risk "3" for probability and "4" for impact, you're not capturing a measurement. You're assigning it to a bucket. Consider three risks that all land in your "Yellow" category: one with an expected value of £25,000, another at £75,000, and a third at £150,000. They're all Yellow. They all get the same treatment priority. But one represents six times the exposure of another.
The problem compounds when you use log-like scales for impact (common practice to handle both small and catastrophic risks on the same grid). You can end up with a Yellow risk and a Red risk that have nearly identical expected values but wildly different treatment urgency based solely on which squares they occupy.
Your ISO/IEC 27001 Clause 6.1.2 risk assessment doesn't require ordinal simplification. It requires criteria for accepting risk and criteria for performing risk assessments. Nothing mandates you throw away quantitative data to fit a 5×5 grid.
Myth 2: "Multiplying probability and impact scores helps us rank risks objectively"
Reality: Multiplication creates artificial clustering that makes ranking harder, not easier.
Here's the mathematical problem: when you multiply ordinal values in a 5×5 matrix, you don't get 25 unique risk scores. You get 14. Multiple combinations produce identical scores (a 3×4 and a 4×3 both equal 12), forcing you to treat fundamentally different risks as equivalent.
Worse, the ranking becomes irrational when compared to actual expected values. A risk scoring 9 might have an expected value four times higher than a risk scoring 12, yet your prioritized list puts the 12 above the 9. You're making decisions based on an artifact of ordinal math, not on actual exposure.
Myth 3: "Color-coding makes risk appetite clear to stakeholders"
Reality: The color bands hide dangerous overlap in actual risk values.
When you calculate the best-case and worst-case expected values for each square in your PIG, you'll find something uncomfortable: your Green risks can have higher expected values than some of your Amber risks. Your Amber risks can overlap with Red.
This isn't what your risk committee thinks they're seeing. They believe Green means "acceptable" and Red means "urgent." But the categorical colors are masking a continuous distribution of exposure. You've traded precision for the appearance of clarity.
Your SOC 2 trust services criteria don't ask for color-coded comfort. CC3.2 requires you to identify, analyze, and respond to risks related to defined objectives. Analyze means understanding the actual magnitude, not just the grid square.
Myth 4: "Low probability, high impact risks are safely captured in the bottom-right corner"
Reality: Those squares are where your existential threats hide in plain sight, labeled "Green" and ignored.
The business-ending risk sits there, plotted as very low probability and very high impact, colored green or light yellow, and categorized as acceptable. Why is it low probability? Often because you haven't seen it happen yet, not because you have strong evidence it's genuinely rare. You're confusing "low strength of knowledge" with "low likelihood."
This is where the so-called black swan risks live before they destroy you. They're not unknown unknowns. They're known, documented, and actively deprioritized by a tool that mathematically obscures high-impact scenarios behind a probability multiplier.
ISO/IEC 27001 Clause 6.1.3(c) requires you to evaluate the consequences of those risks. Not the color of the square they land in. The consequences.
Myth 5: "Showing inherent and residual risk on the same PIG demonstrates control effectiveness"
Reality: You're demonstrating movement between ordinal buckets, not measuring actual risk reduction.
When you plot a risk moving from Red to Yellow after implementing controls, you're showing a change in categorical assignment. But did you reduce expected annual loss by 20%? By 60%? By £100,000? The PIG doesn't tell you. It shows a dot moved from one square to another.
This matters for Clause 6.1.3(d), which requires you to determine and maintain documented information about the risk assessment process. If your process can't quantify the effect of a £50,000 control investment on actual risk exposure, you're not assessing, you're decorating.
Myth 6: "PIGs are standard practice, so they must be acceptable for compliance"
Reality: Neither SOC 2 nor ISO/IEC 27001 requires you to use ordinal risk matrices.
ISO/IEC 27001 Clause 6.1.2 requires risk assessment criteria and methods. It doesn't specify PIGs. SOC 2's CC3.2 requires risk identification and analysis to support the design of commitments and system requirements. It doesn't mandate 5×5 grids.
You adopted PIGs because they were easy and everyone else used them. That's not the same as them being required or effective. Standards give you flexibility in methodology precisely so you can choose approaches that actually inform decisions.
What to Do Instead
Start by separating estimation from presentation. Estimate probability and impact quantitatively, even if you use ranges (10-30% probability, £50,000-£200,000 impact). Calculate expected values. Understand the distribution.
Then, if you need to present simplified views to non-technical stakeholders, create those presentations from the quantitative data, not instead of it. Your risk register should contain the actual estimates. Your executive summary can contain the simplified view. Don't let the summary become your analysis.
For risk treatment decisions, rank by expected value, not by ordinal score. If you need to incorporate risk tolerance, set it as a threshold value (we accept risks below £X expected annual loss), not as a color.
Consider scenario-based risk assessment for your high-impact scenarios. Model the actual event chains. Estimate the actual costs. ISO/IEC 27001 doesn't prohibit this; it encourages methods appropriate to your context.
Your PIGs aren't helping you make better decisions. They're helping you make faster presentations. Know the difference, and choose your tools accordingly.
