Answering a Board Question in Euros: Method Architecture at Meridian Insurance
Meridian Insurance Group holds a qualitative ISO/IEC 27005 register of 240 risks, scored on a 5×5 matrix by three analysts across six business units. The board has asked for 'the top ten IT risks expressed in euros' to decide whether to increase the €5m security budget, and the regulator has asked how model risk is documented and challenged. The CISO has ten weeks, one quantitative analyst, and three years of incident data: 14 recorded events with losses between €20,000 and €1.8m. Two business units have no loss data at all; one subsidiary already uses OCTAVE Allegro worksheets and wants to keep them; the actuarial team offers calibrated-estimation support and FAIR training, and a vendor is pitching CRAMM. The CISO must also keep the existing register usable for ongoing treatment decisions, not just produce a one-off board paper.
1. Recommend a method architecture and justify it against at least two alternative approaches, including how you handle missing loss data.
Read the worked answer
Recommend a two-tier architecture: ISO/IEC 27005 as the governing process, FAIR applied to a screened subset, and OCTAVE Allegro retained for the subsidiary only where its output can be mapped into the register.
Why FAIR for the board question. The board asked for euros. FAIR decomposes risk into loss event frequency and loss magnitude, with magnitude split into six forms - productivity, response, replacement, competitive advantage, fines and judgments, reputation - and produces distributions rather than point estimates. With 14 incidents and two units lacking data, calibrated estimation (eliciting P10/P50/P90 ranges from subject-matter experts and simulating) is more defensible than inventing a single annualised figure. The observed range of €20,000–€1.8m is exactly the shape of input FAIR expects.
Why not FAIR everywhere. 240 risks in ten weeks with one analyst is impossible, and many register entries are too coarse to decompose. Screen first - the qualitative register ranks the candidates - then quantify the top 15–25 scenarios by business unit. FAIR for the few, qualitative for the many, keeps the register usable for treatment decisions after the board paper.
Why not OCTAVE Allegro as the primary method. It is scenario-based, workshop-driven and inexpensive, and its business-driver criteria suit the subsidiary, but it produces relative risk scores rather than monetary ranges, so it cannot answer the board question directly.
Why not CRAMM. Asset-driven with weighted confidentiality, integrity and availability valuation, it is strong for countermeasure selection but non-monetary and labour-intensive on legacy asset inventories. Decline the vendor pitch on fit, not on quality. NIST SP 800-30 is worth borrowing for threat-source and threat-event structure inside the quantified scenarios.
2. What must be documented, and how do you prevent inconsistency and double counting when the methods are combined?
Read the worked answer
Documentation and consistency are the answer to the regulator's model-risk question.
1. One methodology document, management-approved before work starts: purpose, scope, the screening rule, which scenarios were quantified, scales, aggregation rules and roles. Evidence that it was followed matters as much as the document.
2. Translation rules between tiers. If qualitative 'likelihood 4' maps to a frequency band in FAIR, publish the mapping and use it in both directions; otherwise the same risk will show different results depending on which method was applied, and the board will notice.
3. One scenario taxonomy and one set of impact definitions across all six units, so a FAIR loss magnitude and an OCTAVE consequence rating describe the same business effect. Convert the subsidiary's worksheets into register entries with cross-references rather than running them in parallel.
4. No naive aggregation. Do not sum median losses across correlated scenarios - one ransomware event can trigger several register entries. Combine distributions, state correlation assumptions, and report the portfolio as P10/P50/P90 rather than a single total.
5. Uncertainty per estimate: confidence level, assumptions list, named sources, calibration training for estimators, and independent challenge. The actuarial team is well placed to review the model, not to author it.
6. Back-test against the 14 known events: does the model's frequency and severity envelope contain them? Treat the absence of recorded events in the two data-free units as a possible detection gap, not as low risk.
7. Version control, review cycle and a trigger list for re-quantification: an incident above a threshold, major architecture change, or regulatory change.