A risk assessment should help someone make a decision. If a reviewer cannot explain why a scenario is rated high, which evidence supports that rating, or what would change it, the assessment is difficult to use. The problem can survive inside a spreadsheet, a heat map or an expensive quantitative model.
What the frameworks actually ask for
SOC 2 CC3.2 asks an organization to identify and analyze risks to its objectives. ISO/IEC 27001 requires an information security risk assessment process. NIST SP 800-30 goes further as a guide: it describes how to prepare, conduct and maintain an assessment. These sources have different purposes; they do not amount to one universal legal requirement. NIST SP 800-30.
A heat map can summarize the result of that work. It cannot explain the assumptions by itself. A high rating for a service outage might mean an interruption is frequent, a rare interruption would be severe, or both. Those are different problems and may justify different treatments.
The useful question is how the assessment follows the system as it changes. A new production dependency or a broader service account may matter more than the next review date. The same issue appears when evaluating an AI vendor’s SOC 2 report.
The assessment should connect each requirement to evidence, a decision and an accountable owner. A display of ratings is only one part of that record.
Choose the method for the decision
Before choosing a scoring model, write down what the assessment must decide. An initial inventory may need a consistent way to route attention. A budget decision may need an estimate of loss and the cost of reducing it. A question about safety or individual rights may need criteria that a financial model cannot capture.
For SOC 2, relate the assessment to the organization’s objectives and the risks that could prevent it from meeting them. Record who assessed the risk, the evidence considered, and the response. CC3.2 does not prescribe FAIR or require every scenario to have a dollar value. AICPA Trust Services Criteria.
ISO/IEC 27001 clause 6.1.2 calls for a defined process that will “ensure that repeated information security risk assessments produce consistent, valid and comparable results.” That requires usable criteria and a record of how they were applied. It does not mean a risk rating must stay unchanged when the evidence changes.
NIST SP 800-30 permits qualitative, quantitative and semi-quantitative approaches. It supplies a methodology rather than leaving a blank space for teams to fill. The organization still has to define its scope, choose suitable scales and explain the uncertainty in its conclusions. NIST’s assessment guidance.
A rating needs something behind it
A decision
State what the assessment informs: approve a supplier, reduce a permission, fund recovery work or accept a defined exposure. This gives reviewers a reason to inspect the analysis.
Consistent criteria
Define the time horizon and the boundaries between likelihood and impact categories. Two assessors should be able to identify why they disagree, rather than silently using different scales.
A review trigger
Set a review interval and identify changes that reopen the assessment. A failed recovery test or a material change in access may justify a review before the scheduled date.
An accountable owner
Record the person who can act on the finding, the treatment decision and its rationale. An unexplained number is no easier to audit than an unexplained color.
Tony Cox’s 2008 analysis describes how risk matrices can compress very different risks into the same category and misorder some risks. Its often-cited less-than-10% example concerns the fraction of pairs that a matrix can unambiguously compare. It is not a universal accuracy score for assessments. The practical lesson is to inspect the underlying scenario before treating a category as a priority. Cox, What’s Wrong with Risk Matrices?.
Use financial analysis where money is the decision
FAIR, Factor Analysis of Information Risk, is one option for analyzing financial exposure. It organizes a loss scenario around how often loss events occur and how much those events could cost. That structure can help a team compare a proposed treatment with the exposure it may reduce. Open FAIR requirements.
Consider a service outage that interrupts order processing. Operations can estimate how much work a manual process can absorb. Finance can explain which lost sales are recoverable. Engineering can test restoration time. Those inputs give the assessment more substance than asking each team to nominate an impact score.
Represent uncertain inputs with distributions that fit the available evidence. A simulation can then produce an estimated annual loss distribution. Its percentiles are conditional on the model and assumptions. If a P90 estimate is $4 million, the model puts annual loss at or below that amount in 90% of simulated years; it does not guarantee that outcome.
Keep the reasoning as carefully as the result. Record the scenario, time horizon, input sources, model version and unresolved disagreements. A second reviewer should be able to understand how the team reached its decision. Using a named methodology does not by itself establish conformity with a standard or ensure an audit outcome.
Quantification takes work, and a simulation cannot repair unsupported inputs. If recovery time drives the result, a restoration exercise may be more useful than another round of numerical analysis. For a low-impact decision, a documented qualitative assessment may be sufficient.
An assessment becomes current when its evidence and assumptions are reviewed. A chart in dollars can become stale too. Figures shown are illustrative.
Keep the assessment tied to the work
The useful record connects analysis to action. It also preserves enough history to show why a decision changed.
Define the assessment
Choose the approach. Explain why qualitative analysis, a financial model or a combination fits this decision. Define the scope and time horizon before collecting scores.
Write a specific scenario. Describe the affected service, the event and the consequence. For an outage, distinguish delayed work from permanently lost revenue.
Record evidence and uncertainty. Identify observations, estimates and gaps separately. Give each important assumption an owner and review date.
Preserve a comparable record. Keep prior inputs and model versions so reviewers can distinguish a real exposure change from a change in method.
Maintain the decision
Set review triggers. Revisit the assessment after relevant incidents, permission changes, new dependencies or failed control tests. Match the routine cadence to the exposure.
Check treatment assumptions. A backup reduces outage duration only if restoration works at the required scale. Test the premise before counting the benefit.
Record acceptance. Name the person with authority to accept the remaining risk and explain the conditions or limits of that decision.
Map to applicable requirements. Show how the assessment supports the relevant SOC 2 criteria or ISO process. Keep additional evidence where a requirement calls for more than the assessment itself.
Make the next decision easier to review
A mature assessment lets a reviewer follow the path from evidence to assumption to treatment. It explains what is uncertain and who owns the next step. That is useful whether the final summary is a heat map, a loss distribution or a short decision memo.
Compare the requirements and evaluation criteria for first-party risk management software.
See how Zania quantifies first-party risk with FAIR →
Sources:
Share
