A FAIR risk assessment example should do more than assign a red, amber, or green label to a cyber scenario. It should show leadership what could happen, how often it may happen, the financial range of the outcome, and which decision would change that exposure. That is the difference between a risk register entry and a board-ready risk decision.
For senior leaders, the value is not false precision. Cyber risk quantification cannot predict the exact date or cost of an incident. It can provide a disciplined, evidence-based view of loss exposure that supports choices on investment, risk acceptance, insurance, resilience, and accountability.
What FAIR Measures Differently
FAIR, or Factor Analysis of Information Risk, treats risk as the probable frequency and probable magnitude of future loss. Rather than beginning with a generic control maturity score, it begins with a defined loss event scenario.
That distinction matters. A statement such as “ransomware risk is high” may be directionally useful, but it does not establish whether a proposed $750,000 investment is proportionate, whether a risk is within appetite, or what management is accepting by delaying action.
A FAIR analysis separates the scenario into two questions: how often a loss event is likely to occur, and how much a loss event could cost. It also makes uncertainty visible. Inputs are expressed as defensible ranges, not as single-point assumptions presented with unwarranted confidence.
The framework is especially useful where boards need to compare unlike risks. A ransomware event, regulatory enforcement action, cloud service outage, and third-party data breach can all be discussed in financial terms while retaining the operational detail needed by security and technology teams.
FAIR Risk Assessment Example: Ransomware at a Payments Firm
Consider a mid-sized payments company that processes transactions for business customers. Its executive team is deciding whether to fund a resilience program that includes privileged access hardening, endpoint detection improvements, immutable backups, and tested recovery procedures.
The scenario must be narrow enough to analyze and material enough to matter:
> A criminal group deploys ransomware through compromised administrator credentials, encrypting the production payments environment and causing a material interruption to transaction processing.
This is not an assessment of every ransomware possibility across the business. It is an analysis of one defined event affecting a defined asset and business process. That scope discipline prevents broad assumptions from being mistaken for evidence.
Step 1: Estimate loss event frequency
The first task is to estimate how often this scenario may result in loss. The team examines external threat intelligence, internal detection data, phishing and credential exposure trends, administrator access design, endpoint coverage, and prior security testing.
Suppose the analysis concludes that credible threat actors may attempt a relevant intrusion roughly 10 to 18 times per year. Not every attempt leads to a successful action, and not every successful action leads to the level of encryption described in the scenario. Based on the effectiveness of current controls, the assessed probability that a relevant attack results in the defined loss event is 8% to 16%.
The resulting loss event frequency is therefore modeled as a range rather than a fixed number. The organization may face a material ransomware interruption approximately once every 0.8 to 2.5 years, with the central estimate near one event every 1.4 years.
That finding may challenge assumptions on both sides. Security leaders may see that exposure is higher than the existing risk register suggests. Finance leaders may see that the scenario is not an annual certainty. Both outcomes are useful if the assumptions are documented and can be challenged.
Step 2: Estimate loss magnitude
Loss magnitude is rarely limited to the ransom demand. In a regulated payments environment, the more significant costs may arise from interrupted operations, customer remediation, contractual claims, incident response, legal advice, regulatory engagement, and reputational damage.
For this scenario, management and subject matter experts may develop the following loss ranges:
- Incident response, forensics, and recovery: $400,000 to $1.2 million.
- Lost revenue and transaction disruption: $750,000 to $3 million.
- Customer remediation, service credits, and contractual penalties: $500,000 to $2.5 million.
- Legal, regulatory, and notification costs: $250,000 to $1.5 million.
- Longer-term customer attrition and increased acquisition cost: $300,000 to $3 million.
These figures should not be guessed in isolation. Finance can provide revenue and margin data. Legal and compliance can assess contractual and regulatory exposure. Operations can estimate recovery timing. Security can describe realistic attack paths and control limitations. The analysis becomes credible when each range has an owner, source, and rationale.
After modeling the combined ranges, the probable loss from one event may fall between $2 million and $8 million, with a most likely outcome near $4.2 million. A severe but plausible event could exceed that range if recovery is delayed or a major customer terminates its agreement.
Turning the Analysis Into a Decision
Combining frequency and magnitude gives leadership an annualized view of exposure. In this example, the modeled annual loss exposure may be approximately $2.5 million to $4.5 million, depending on the distribution of inputs and the organization’s assumptions.
That number is not a budget request. It is the basis for deciding what level of investment is economically and operationally justified.
The resilience program under consideration costs $900,000 in the first year and $250,000 annually thereafter. Technical testing indicates it could reduce the likelihood of a material encryption event by 45% to 60% and reduce restoration time if an event occurs. The analysis estimates an annual risk reduction of $1.4 million to $2.3 million.
The decision is not automatic. Management should test whether the estimated control improvement is achievable, whether the program introduces operational burden, and whether there are lower-cost measures that address the same risk drivers. A backup platform that is not isolated or routinely restored under realistic conditions may create confidence without resilience.
Still, the conversation has changed. The board is no longer asked to approve a collection of security tools because ransomware is concerning. It is asked to choose between a defined cost, a modeled reduction in loss exposure, and a stated level of residual risk.
What Makes the Example Fair and Defensible
A useful FAIR assessment does not depend on elaborate mathematics alone. Its quality depends on clear scenario definition, traceable evidence, informed challenge, and accountable ownership.
The most common failure is treating FAIR as a conversion exercise for an existing heat map. If the source inputs are generic ratings, the financial output will only create an appearance of rigor. Quantification should begin with the business process, asset, threat community, control environment, and loss forms that are relevant to the decision.
A second failure is using a single number as though it were a guarantee. Executives should see ranges, confidence levels, material assumptions, and the conditions that would invalidate the analysis. For example, a planned migration to a new payment platform or an acquisition that changes the customer base may require the scenario to be reassessed.
Finally, a FAIR analysis should identify action owners. Security may own privileged access controls and recovery testing. Operations may own recovery objectives. Legal may own contractual risk treatment. The executive sponsor owns the decision to accept, reduce, transfer, or avoid the residual risk.
Using FAIR at Board Level
Board reporting should be concise. The supporting model can be detailed, but the board paper should show the scenario, current exposure range, key drivers, risk appetite position, proposed treatment, expected reduction, cost, and residual exposure.
Boards should also ask what would cause management to revisit the analysis. Decision thresholds may include a material increase in exposed privileged accounts, an untested recovery environment, a major regulatory change, or evidence that an important supplier cannot meet required recovery commitments.
This approach supports governance without asking directors to become security specialists. It gives them a structured basis to challenge assumptions, compare priorities, and record risk acceptance with appropriate care.
The practical test is simple: if a quantified assessment does not change or clarify a business decision, it is probably too broad, too abstract, or aimed at the wrong audience. Start with the decision that cannot be responsibly made from a heat map, then build the scenario and evidence around it.