Meridian Health Plan: Scoping a Board Question in Six Weeks
Meridian Health Plan covers 3.2 million members. Its board has adopted a risk appetite statement: no single scenario may exceed $25M at the 90th percentile over a 12-month horizon. The security team has two analysts and six weeks. The newly hired risk lead proposes to run a Monte Carlo analysis of all 640 applications in the CMDB plus 41 third parties, using automated questionnaire data, and to sum the results into one enterprise figure for the board. At the two-week mark the questionnaire response rate is 18%, the analyst is feeding the commercial vulnerability scanner's 1-10 risk scores straight in as loss event frequency inputs, and the steering committee is deadlocked over whether email is one asset or twelve. The audit committee has meanwhile asked a narrower question: whether the claims-processing SaaS vendor being onboarded next quarter, which will handle 40% of claims, could push a single scenario past the $25M threshold.
1. Diagnose the scoping error and propose a scope that actually answers the audit committee's question. Specify the asset, threat community, analysis period, unit of loss, and risk metric.
Read the worked answer
The plan is bottom-up enumeration, not scoping. Scoping in FAIR starts from the decision and the appetite, then selects the assets and scenarios that could change the decision. Analysing 681 items with an 18% response rate produces a large, low-confidence number that answers nothing the board asked, and the steering committee's argument about email is a symptom: without a decision to anchor the scope, granularity is unresolvable.
A scope that answers the audit committee:
- Asset: claims data and the claims-processing service, including the SaaS vendor's processing environment to the extent it affects Meridian's loss. The vendor is in scope because it concentrates 40% of claims, not because it is a third party.
- Threat community: external actors targeting the vendor, plus the vendor's insiders and any of their subcontractors. The vendor's own control environment is part of Meridian's resistance strength.
- Analysis period: 12 months, aligned to the appetite horizon and to the first contract year.
- Unit of loss: US dollars, annualised, split into primary and secondary forms.
- Risk metric: 90th percentile annualised loss exposure compared with the $25M threshold, reported alongside the 50th percentile.
Add two to four other candidate scenarios selected through a quick risk landscape exercise, and state exclusions explicitly in the report so the board knows what the number does not cover.
2. Critique the use of the commercial vulnerability scanner's 1-10 risk scores as loss event frequency inputs, and state what evidence would be minimally sufficient in six weeks.
Read the worked answer
The scanner score is an ordinal severity rating generated by a different model. It encodes neither frequency nor loss; a 9 does not mean 9 events, and it does not mean events are nine times more likely than a 1. Feeding it in as LEF manufactures precision and launders a prioritisation score into a probability. If the board later asks why one application shows 0.9 events per year, there is no answer.
Minimally sufficient evidence in six weeks:
- A risk landscape to identify which scenarios could plausibly reach $25M. Most of the 640 applications cannot, and that eliminates them without analysis.
- Calibrated SME estimates of TEF, vulnerability, and loss per event for the shortlisted scenarios, decomposed into components so experts answer narrow, estimable questions rather than guessing an overall frequency.
- Analogous data: the vendor's SOC 2 report and audit findings, contractual liability caps, claim volume and per-record cost benchmarks, industry incident counts for comparable processors.
- Distributions, not scores: 5th, 50th and 95th percentiles with documented rationale.
The 18% questionnaire response rate is not the binding constraint. Most respondents are irrelevant to this question, and chasing a higher rate would consume the six weeks without improving the estimate.
3. The steering committee still wants one enterprise risk number. Explain why summing 640 application-level results will misstate enterprise risk, and describe a defensible aggregation.
Read the worked answer
Summing application-level annualised loss exposures misstates enterprise risk for several reasons:
- Double counting. A single event, such as compromised identity infrastructure, produces losses across many applications. Summing counts the same loss repeatedly.
- Shared controls. One control protects many applications, so the reductions cannot be added and the residual exposures are not independent.
- Common cause. A cloud provider outage or a directory compromise hits many applications at once. Independent summation assumes away exactly the correlation that makes enterprise risk interesting.
- Noise accumulation. Precision at the application level is low; adding 640 low-precision estimates produces a large number that looks stable but is mostly accumulated error.
- Wrong shape. The sum of means hides that enterprise risk is concentrated in a few scenarios with fat tails.
A defensible aggregation: define a small set of mutually exclusive scenarios that together cover the material risk landscape, each with a loss distribution over the same 12-month period and the same loss unit. Combine them with an explicit correlation assumption or a common-cause stress case, and test how much the total moves when a single shared dependency fails. Report the aggregate as a distribution, with the top three contributing scenarios named, and state the 90th percentile against the appetite. That is a number the board can use and a number the team can defend.