Open FAIR Foundation common mistakes
Open FAIR Foundation · Understand the traps and how to avoid them.
Treating the Open FAIR analysis as a qualitative red/amber/green exercise, assigning heat-map labels or severity ratings instead of deriving a monetary loss exposure range.
Candidates arrive from IT audit or ERM backgrounds where risk registers use ordinal scales, and the exam's insistence on calibrated, quantitative output feels impractical or unfamiliar.
What to do instead
Before answering, ask whether the output is a probability distribution of loss in financial terms. If the stem describes categories, colours, or 'high/medium/low', it is not Open FAIR. Practise restating qualitative scenarios as annualised loss exposure (ALE) ranges with explicit units and confidence bounds.
Confusing Risk with Loss Event Frequency in the taxonomy, e.g., stating that risk equals the frequency of threat agent action.
Everyday language uses 'risk' and 'likelihood' interchangeably, and the Factor Analysis of Information Risk ontology splits risk into frequency and magnitude components that candidates collapse under exam pressure.
What to do instead
Memorise the ontology tree: Risk = f(Loss Event Frequency, Loss Magnitude); Loss Event Frequency = f(Threat Event Frequency, Vulnerability); Threat Event Frequency = f(Contact Frequency, Probability of Action); Vulnerability = f(Threat Capability, Resistance Strength). Recite it until you can label any node in a scenario instantly.
Leaving Loss Magnitude as a single figure and omitting the primary/secondary split across the six loss forms (productivity, response, replacement, fines and judgments, competitive advantage, reputation).
Candidates think of 'the cost of the incident' as one number and forget that secondary losses (response, fines, reputation, competitive advantage) are often larger and harder to estimate than primary ones.
What to do instead
For each scenario, build a 2x3 grid: primary versus secondary against the six loss forms, and state which forms are material. Note that secondary loss frequency can differ from primary loss frequency because stakeholders react selectively.
Producing a point estimate such as 'the risk is $4.2 million' rather than a calibrated range with a most-likely value and confidence level.
Spreadsheets and management reporting reward single numbers, and candidates mistake precision for rigour, missing that Open FAIR treats estimates as probability distributions.
What to do instead
Always answer with a range (e.g., 90% confidence interval), a most-likely value, and the basis of the estimate. Reject any option that presents an unqualified point value as the analysis result.
Skipping the scoping and framing step, then analysing an asset or scenario that does not match the decision the stakeholder needs to make.
Candidates jump straight to factor decomposition because it feels like the technical core, treating framing as administrative overhead.
What to do instead
Use the standard sequence: identify the decision, scope the asset and threat community, define the loss event, then decompose. Check every stem for a stated decision or stakeholder; if the analysis does not serve it, the answer is wrong.
Treating Threat Capability and Resistance Strength as absolute rather than relative to a specific threat community, and failing to compare them on a common scale.
Candidates read 'capability' as an intrinsic property of an attacker and 'resistance' as an intrinsic property of a control, missing that vulnerability emerges from their comparison for a defined community.
What to do instead
Always ask 'capable relative to what?' and 'resistant against whom?' State the threat community explicitly (e.g., organised crime, insider, script kiddie) and express both factors on a comparable ordinal or percentage scale before judging vulnerability.
Substituting control existence for Resistance Strength, concluding that a deployed control makes vulnerability low without evidence of its effectiveness.
Compliance training teaches that implemented controls reduce risk, so candidates assume deployment equals effectiveness and ignore that Resistance Strength is about the probability a threat event becomes a loss event.
What to do instead
Distinguish 'the control is deployed' from 'the control resists this threat community at this capability level'. Look for evidence of tested effectiveness, coverage, and failure modes; treat mere deployment as insufficient evidence.
Confusing Probability of Action with Contact Frequency, or assuming contact always implies a threat event.
Both sit under Threat Event Frequency, and candidates conflate 'how often they touch us' with 'how often they choose to act', which inflates threat event estimates.
What to do instead
Separate the two: Contact Frequency is how often a threat community could reach the asset; Probability of Action is the likelihood they attempt an action given contact. Threat Event Frequency is the product, not either input alone.
Ignoring uncertainty and calibration, presenting factor values as known facts without confidence levels or ranges, and failing to use subject-matter experts as calibrated estimators.
Candidates believe quantitative means certain, and lack practice with calibration training, so they overstate confidence and understate the width of their ranges.
What to do instead
Attach confidence intervals to every factor estimate, document the source (expert, historical data, industry data), and prefer calibrated SME elicitation over personal intuition. Recognise that wide, honest ranges are more correct than narrow, unsupported ones.
Relying on a single industry benchmark or vendor data point as the sole basis for a factor estimate, without adjusting for the organisation's context.
Benchmark reports are easy to cite and appear authoritative, so candidates treat external averages as directly applicable to a specific asset and threat community.
What to do instead
Use external data as a starting point, then adjust for differences in asset value, exposure, control environment, and threat community. State the adjustment rationale and widen the range when extrapolating beyond the data's population.