A risk register can tell a board which issues need attention. A funding decision asks something more specific: how much exposure could this investment reduce, and how uncertain is that estimate? Answering that question takes a loss scenario, evidence and a comparison. Changing a red cell into a dollar figure is only the beginning.
Connect the analysis to a decision
The SEC’s cybersecurity disclosure rules generally require domestic registrants to disclose a material incident within four business days after determining it is material, including its material impact on “financial condition and results of operations.” Materiality includes qualitative and quantitative factors. The rules do not mandate FAIR, a P90 estimate or a particular risk-management method. Financial analysis can support a decision without replacing that broader judgment. SEC compliance guide.
A likelihood-impact grid can summarize priorities. Its categories do not have a natural dollar value, and adding category numbers does not produce total financial exposure. If a board must choose between recovery investments, the analysis needs to explain what each option changes and what it costs.
Be clear about what the rating measures
Ordinal categories put items in an order. They do not establish that a score of four carries twice the exposure of a score of two. Where a grid uses numerical labels, keep the category definitions visible and avoid treating arithmetic on those labels as financial measurement.
Tony Cox showed the underlying problem in 2008. A typical risk matrix, he found, can “correctly and unambiguously compare only a small fraction (e.g., less than 10%) of randomly selected pairs of hazards,” and it assigns “identical ratings to quantitatively very different risks,” an effect he named range compression. For risks whose frequency and severity pull in opposite directions, he showed matrices can be “worse than useless,” producing worse-than-random rankings.
Two scenarios in one category may have different loss distributions. The illustrated P90 values describe assumptions in a model, not guaranteed loss limits.
Cox’s examples describe limitations under particular mathematical conditions. The less-than-10% figure is not a universal error rate for risk teams. The useful question is whether the categories preserve the differences that matter to the decision in front of you.
Keep the assumptions visible
Build the loss scenario
FAIR is a framework for quantifying information and operational risk financially. Its taxonomy organizes the analysis around loss-event frequency and loss magnitude. The Open Group’s Open FAIR standards provide a common vocabulary, which helps reviewers examine the assumptions rather than argue about what a risk label means. Open FAIR requirements.
Consider ransomware interrupting order processing. Estimate how often an event could cause loss and what the interruption would cost over a defined time horizon. Distinguish response and restoration work from possible customer or regulatory reactions. FAIR can also describe accidental events; the analysis is not limited to an attacker defeating a security control.
Controls can affect event frequency, the chance of a loss or its magnitude. The assumed effect needs evidence, such as a recovery test or an access-control test.
Use distributions that represent the evidence and uncertainty in the inputs. In an illustrative model, a P90 annual loss of $4.2 million means 90% of simulated years have losses at or below that amount. P90 values cannot simply be added to obtain a portfolio P90. Model shared causes, overlapping losses and dependencies before estimating the portfolio tail.
The estimate is only as useful as its assumptions
A model makes uncertainty easier to inspect; it does not automatically reduce it. More simulation runs do not make an unsupported restoration-time assumption more credible. Keep a list of the assumptions that drive the result and identify which ones could be checked with operational evidence.
Compare the options on the same basis
For example, a recovery project may shorten a production outage while an access-control project may reduce the chance it begins. Compare their estimated effects over the same period, include implementation and ongoing costs, and show where uncertainty changes the preferred option.
Prepare the analysis
Scope one loss scenario. Identify the affected operation, the event and the consequence. State whether the model covers a year, a project or another period.
Estimate with evidence. Use incidents, operational measurements and informed estimates. Record sources and disagreements instead of treating a range as proof of reliability.
Inspect model behavior. Check implausible combinations and overlapping cost categories. Test whether plausible alternative assumptions change the recommendation.
Report more than a percentile. Explain expected loss, the distribution and relevant tail estimates. State the assumptions that matter most to the decision.
Use the result
Prioritize with context. Consider financial exposure alongside mandatory controls, safety concerns, customer commitments and available treatment options.
Compare costs with benefits. Evaluate the change in modeled loss over a consistent time horizon. A reduction in P90 alone is not a complete return-on-investment calculation.
Build the portfolio explicitly. Avoid counting the same interruption in several scenarios. Shared providers and other common causes can change the combined loss distribution.
Record the decision. Keep the chosen treatment, its owner, the accepted uncertainty and the events that trigger a review. Preserve earlier versions so changes can be explained.
Give the board a decision it can examine
Present the scenario, the proposed treatment, the estimated benefit and the assumptions that could change the recommendation. Name the owner of the remaining exposure. If the analysis needs a platform to maintain that record, our guide to first-party risk management software sets out the evaluation criteria.
Explore Zania’s first-party risk management →
Sources:
Share
