SOC 2, ISO 27001, and NIST all require a formal risk assessment. None of them prescribes the method, so most teams answer with a color spreadsheet they update once a year for the auditor. That gap is where the work now sits.
The 60-second version
Three of the frameworks a security team lives under require a risk assessment in writing. SOC 2 criterion CC3.2 says the entity identifies and analyzes risks to its objectives as the basis for how they are managed. ISO/IEC 27001 clause 6.1.2 requires a defined risk assessment process that produces “consistent, valid and comparable results” when you run it again. NIST SP 800-30 is the US federal guide for how to do it.
None of the three names a method. So the path of least resistance is a 5×5 heat map in a spreadsheet, red-amber-green, refreshed once a year the month before the audit. It clears the checkbox. It tells the business almost nothing.
Two things are pushing on that spreadsheet in 2026. Auditors are asking whether the methodology is real and repeatable, not just whether a grid exists. And the annual cadence is out of step with how fast risk moves, the same shift toward continuous evidence reshaping SOC 2 for AI vendors.
What the frameworks ask for on the left. What most teams submit on the right. The gaps are the parts an auditor now reads closely.
The frameworks require a method. They do not pick one.
Read the three requirements next to each other and the shape is consistent. Every one mandates a rigorous, repeatable, owned process. Not one says which model to use.
SOC 2 CC3.2 comes from COSO. It asks the organization to identify risks to its objectives and analyze them as a basis for managing each one. An auditor testing it wants a documented methodology, a risk register with owners, and a regular cadence.
ISO/IEC 27001 clause 6.1.2 is more specific. The process has to define risk criteria, be applied consistently, assign an owner to each risk, and “ensure that repeated information security risk assessments produce consistent, valid and comparable results.” That phrase is a repeatability test written into the standard.
NIST SP 800-30 sets out the process and is explicit that you can assess risk qualitatively, quantitatively, or with a mix of both, as long as the approach fits your risk tolerance. The color grid fills the method vacuum because it is fast and it looks like risk. It is also the weakest thing you can put in the box.
The heat map is not worthless. It goes wrong when a color becomes the whole program.
Checkbox theater outputs a color
A grid that satisfies the auditor and guides no decision. It gives a color, not a number a CISO or CFO can act on.
Not repeatable <10% ranked right
Re-run the assessment and the colors move. ISO 27001 6.1.2 asks for consistent, comparable results; ordinal ratings drift with whoever fills the cell.
Stale 1× per year
Refreshed once a year, then frozen. Risk moves in days; the grid describes a world that has already changed.
No rationale or owner untraceable
A rating with no recorded reasoning. An auditor cannot follow “high” back to an assumption, and no one owns the number.
The repeatability problem is not a matter of taste. Tony Cox showed in Risk Analysis (2008) that a typical risk matrix can correctly rank fewer than 10% of randomly chosen pairs of risks, assigns identical ratings to quantitatively very different hazards, and in some cases performs worse than random. The grid feels rigorous. Its resolution is close to noise.
The method that satisfies the requirement.
The frameworks leave the method open, so the fix is to pick a real one and write it down. The recognized quantitative option is FAIR, Factor Analysis of Information Risk.
FAIR is an open standard maintained by The Open Group, with a practitioner community in the FAIR Institute, and it is the method most enterprise programs converge on when they need to state cyber risk in money. It takes a risk apart instead of scoring it on a grid. Risk is Loss Event Frequency multiplied by Loss Magnitude. Loss Event Frequency breaks down into how often a threat acts (Threat Event Frequency) and the probability it gets through (Vulnerability). Loss Magnitude splits into primary loss, the direct hit, and secondary loss, the response, fines, and reputation that follow.
You estimate each factor as a calibrated range with a minimum, most-likely, and maximum, not a single guess. Those ranges run through a Monte Carlo simulation, thousands of iterations, and the output is a distribution of annualized loss exposure in dollars with percentiles: a 90% chance the yearly loss stays under a stated figure, often drawn as a loss-exceedance curve.
Two things make this satisfy the requirement the heat map only pretends to meet. It is documented and named, sitting alongside NIST 800-30 and ISO 27005 as an accepted methodology an auditor recognizes. And it is repeatable in the exact sense ISO 6.1.2 asks for: the same inputs produce the same defensible output, and the reasoning behind every estimate is on the record.
FAIR is not free. It needs calibrated estimates and it takes effort, which is why it lived with specialists for years while everyone else reached for the grid. It also does not predict the future. Quantification narrows the uncertainty around a decision; it does not remove it. What it gives you is a number the business can use and an auditor can follow, refreshed as often as the inputs change rather than once a year.
An annual heat-map dot goes stale the day after it is set. A quantified loss-exposure trend moves with the risk and is current when the auditor asks. Dollar values illustrative.
Adopt a real methodology, then run it continuously.
Two tracks. Pick a method that holds up, then keep it current and audit-ready.
AAdopt a real methodology
Replace the color grid with a named model
1Pick a named method and write it down
FAIR, NIST 800-30, or ISO 27005. The methodology document is the first thing an auditor asks for and the first thing a color grid cannot produce.
Closes checkbox theater
2Define scenarios and loss types
Name the asset, the threat, and both primary and secondary loss for each scenario you assess. A scenario is auditable; a color is not.
Closes no scope
3Record calibrated estimates with rationale
Capture each factor as a range with a stated reason and source. The rationale is what turns a number into evidence.
Closes no rationale
4Make it repeatable and versioned
Same inputs, same output. Version the model so a re-run is comparable to the last one, which is the CC3.2 and 6.1.2 test.
Closes not repeatable
BMake it continuous and audit-ready
Keep the assessment current and defensible
1Track loss exposure as a trend
Watch annualized loss exposure move over time instead of setting one dot a year. The annual refresh is the floor, not the coverage.
Closes stale assessment
2Tie treatments to the risks they reduce
Simulate a control and show the loss exposure it buys down. That turns security spend into a number a board can weigh.
Closes blind spend
3Keep the justification trail
Every estimate stays sourced and owned, so an auditor can trace any figure back to its assumption and its owner.
Closes no owner
4Map the output to the evidence auditors ask for
Point the quantified assessment at SOC 2 CC3.2, ISO 27001 6.1.2, and NIST 800-30 directly. One method, mapped to every framework that wanted it.
Closes audit gap
The frameworks were never asking for a heat map. They were asking for a method.
Most teams bring a spreadsheet of colors refreshed once a year, and for a long time that cleared the bar. It clears it less well every year, as auditors press on repeatability and the annual snapshot falls further behind the risk. A quantified methodology answers both: a repeatable process for the auditor, a number in dollars for the business.
See how Zania quantifies first-party risk with FAIR →
Sources
01SOC 2 and Risk Assessment CC3.2 Explained, ISMS.online
02SOC 2 Risk Assessment: What Auditors Actually Look For, Linford & Co
03ISO 27001 Clause 6.1.2 Information Security Risk Assessment, ISMS.online
05Cox, L.A. (2008), What’s Wrong with Risk Matrices?, Risk Analysis 28(2), Wiley
06The Open FAIR Body of Knowledge, The Open Group
07What is FAIR, The FAIR Institute
08How FAIR fits with NIST, ISO, CIS and other frameworks (Frank Kim, SANS), Safe Security
09Your AI vendor’s SOC 2 has an expiration date it doesn’t print, Zania Research
Share
