Open FAIR 2 Foundation common mistakes
Open FAIR 2 Foundation · Understand the traps and how to avoid them.
Treating Risk as a single number (a 'risk score') instead of expressing it as the expected loss distribution - frequency of loss events multiplied by the probability distribution of loss magnitude - so answers collapse to one figure with no shape or tail information.
Candidates carry over habits from score-based frameworks where risk is a scalar. Open FAIR defines risk as the probable frequency and probable magnitude of future loss, so a scalar answer discards the two-factor structure the exam is testing.
What to do instead
Before answering, write the factor pair explicitly: 'Risk = LEF (loss event frequency) × LM (loss magnitude, itself a distribution).' If an option reports only frequency, only magnitude, or a single blended index, treat it as incomplete unless the question specifically asks for one factor.
Confusing Risk with the individual factors in the taxonomy - for example labelling Loss Event Frequency as 'the risk' or calling Vulnerability a form of loss.
The taxonomy is hierarchical and the word 'risk' appears in everyday speech for any bad thing. Candidates map colloquial usage onto formal terms and pick answers that swap a factor with the top-level concept.
What to do instead
Draw the tree from memory: Risk → Loss Event Frequency and Loss Magnitude; LEF → Threat Event Frequency and Vulnerability; LM → Primary and Secondary Loss. Place each option in the tree before choosing; anything that is a node cannot be 'risk' itself.
Treating Threat Event Frequency and Vulnerability as interchangeable or as a single combined 'threat level', so when a scenario describes weak controls the candidate raises Threat Event Frequency rather than Vulnerability.
Many frameworks blend actor capability and control strength into one 'threat' rating. In Open FAIR, Threat Event Frequency is how often an actor acts against the asset; Vulnerability is the probability that those actions become loss events, driven by resistance strength and susceptibility.
What to do instead
Ask two separate questions: 'How often does the threat agent attempt?' (Threat Event Frequency) and 'Given an attempt, how often does it succeed?' (Vulnerability). Control changes move Vulnerability, not Threat Event Frequency.
Assuming the factors are simply multiplied as point estimates (e.g., LEF 2 × LM 100,000 = risk 200,000) and reporting that product as the answer, ignoring that Open FAIR treats each factor as a distribution and risk as a distribution of outcomes.
The multiplication relationship is real, but candidates stop at the arithmetic and forget the probabilistic framing. Exam items often contrast a point estimate with a distributional answer.
What to do instead
State that each factor is a probability distribution (commonly lognormal for frequency and magnitude) and that risk is derived by Monte Carlo simulation or analytic composition. If an option presents a bare product with no distributional language, be suspicious unless the item explicitly asks for a point estimate.
Conflating Primary Loss with Secondary Loss - for example counting incident response costs or regulatory fines as primary loss, or counting lost productivity as secondary.
Both are loss magnitude components, and real incidents produce both at once. The distinction is who bears the loss and whether a secondary stakeholder is involved: Primary Loss falls on the organization from the event itself; Secondary Loss follows from the reactions of external parties (regulators, customers, shareholders).
What to do instead
Use the stakeholder test: 'Does this cost arise from the event happening to us, or from someone else's response to it?' Response, fines, litigation, reputation damage and customer churn are secondary; response is a frequent trap because it feels operational, but it is a secondary stakeholder reaction.
Skipping the scoping stage and jumping straight to estimating frequencies and magnitudes, so the analysis drifts into a vague topic ('cyber risk') rather than a defined risk scenario.
Candidates want to demonstrate quantitative knowledge and treat scoping as paperwork. But unscoped analyses produce estimates that cannot be validated or used, and exam items test whether the candidate knows scoping precedes estimation.
What to do instead
Always articulate the scenario in the canonical form: asset, threat community, threat effect, and the loss event. If a question describes an analysis that cannot be tied to one asset and one threat community, the answer usually involves returning to scoping.
Selecting factor values without calibrating to a defined unit of time and asset scope, producing estimates that are off by orders of magnitude (e.g., a per-year frequency applied per day, or a per-asset loss applied to the whole estate).
Open FAIR estimates are meaningless without an explicit time horizon and asset boundary. Candidates copy plausible-looking numbers from memory without checking the unit, and the arithmetic then looks right while being wrong.
What to do instead
Write the unit next to every estimate: 'events per asset per year' and 'loss per event in currency'. Before computing, restate the scenario's time horizon and asset population, and convert all inputs to that same basis.
Treating a calibrated estimate as a precise prediction and refusing to express uncertainty, or conversely refusing to give any estimate because data is incomplete.
Candidates confuse subjectivity with arbitrariness. Open FAIR estimates are calibrated subjective probabilities from subject-matter experts; they are defensible precisely because uncertainty is expressed in the distribution, not hidden.
What to do instead
Frame estimates as ranges with confidence levels ('90% confident the loss is between X and Y') and note that calibration training and expert elicitation are the intended methods. Reject both 'we need perfect data first' and 'this number is exact' as answer choices.
Using the analysis to produce a risk ranking alone, without connecting results to a decision - no comparison of options, no consideration of risk appetite, no cost-benefit of controls.
Candidates treat the analysis as the deliverable. In Open FAIR, the purpose is decision support: comparing the current state against proposed controls or alternative courses of action in loss-exposure terms.
What to do instead
For every analysis, state the decision it informs and the comparison being made. Express control value as the reduction in expected loss (and the shape change in the distribution) versus the cost of the control, and check the residual against the organization's risk appetite.
Believing a control that reduces Vulnerability also reduces Threat Event Frequency, and crediting the same benefit twice when evaluating a control set.
Controls often feel like they address 'the threat' broadly, and vendors describe them that way. In the taxonomy, controls map to specific factors: resistance strength affects Vulnerability; deterrence affects Threat Event Frequency (or the threat community's behaviour); avoidance and detection affect different points again.
What to do instead
Map each proposed control to exactly one factor before estimating its effect, and re-run the model with only that factor changed. If two controls target the same factor, check whether their effects overlap before summing the benefit.