Most cyber-risk dashboards produce a single number and ask you to trust it.
“Your risk score is 73.” “Likelihood: High.” “Exposure: significant.”
Those numbers are not defensible to a CFO. Not because they are necessarily wrong. Because there is no reasoning trail attached. When the CFO asks why, the answer is some version of “the model said so.” Boards have stopped accepting that answer in 2026, and they were right to.
This article walks through one specific class of risk number — a conditional exposure during an active third-party incident — and shows what it looks like when the reasoning trail is published with the number. The example is taken directly from the Continuous Indicators conditional view, with the math behind it.
The scenario
A credential-exfiltration campaign is hitting GitHub-integrated organizations. Public disclosure happened six days ago. Fourteen affected organizations have been confirmed. The customer in question uses GitHub for source control, with a non-trivial integration surface — CI runners, repo tokens, push notifications.
The board wants to know: are we exposed, and how much?
The product produces an answer: $612K expected exposure, 2.4× the stated $250K appetite. Now we have to defend the number.
The Bayesian decomposition
Expected exposure decomposes into two factors:
Expected exposure = P(you are affected) × loss if affected
Loss if affected comes from the FAIR-based loss model the customer already maintains for this asset class. The model produces a distribution; the headline is the median ($1.8M for this case), with a P10–P90 band ($1.8M–$3.4M). That part is conventional risk quantification, and it is not the interesting part.
The interesting part is P(you are affected). For the GitHub campaign, the system computes that probability through Bayesian updating from a base rate plus the customer’s specific signals. Here is the full breakdown, exactly as the product publishes it.
Base rate · across GitHub orgs (12%)
From the disclosure, 14 orgs confirmed affected out of the population the campaign is targeting. The platform's incident-intelligence module tracks the base incidence rate as new confirmations arrive. 12% means roughly 1 in 8 of the targeted orgs are confirmed hit so far. Base rate updates as more confirmations land.
+ org-wide token scopes (+14%)
The customer's GitHub integration uses org-wide personal access tokens with broad permission scopes. The campaign specifically targets exfiltration of broad-scope tokens. The +14% adjustment reflects the historical correlation between this configuration and successful exfiltration in past similar campaigns. Pulled from the configuration profile the scanner has on file.
+ no secret rotation in 92 days (+9%)
Long-lived secrets are higher-likelihood targets than recently-rotated ones. The customer's secrets-rotation telemetry shows the last GitHub-token rotation was 92 days ago. The +9% adjustment is the standard increment for >90-day secrets in this asset class.
+ 3 repos with long-lived PATs (+3%)
Three repositories are configured with long-lived personal access tokens rather than short-lived OIDC tokens. Each long-lived PAT is an additional exposure surface. The +3% reflects the marginal increment from three additional surfaces.
- IP allowlisting enabled (-4%)
The customer's GitHub org has IP allowlisting enabled for the source-control API. Allowlisting reduces the success rate of token-exfiltration attempts that originate from non-customer IPs. The -4% reflects the historical effectiveness of this control in past similar campaigns. Negative adjustments matter as much as positive ones — they are what makes the decomposition fair.
Posterior — P(you're affected) = 34%
Base rate 12%, plus org-wide token scopes (+14%), plus no secret rotation in 92 days (+9%), plus 3 repos with long-lived PATs (+3%), minus IP allowlisting enabled (-4%). 34% posterior probability. This is what gets multiplied against the $1.8M loss-if-affected to produce the $612K expected exposure number.
The CFO can challenge any line. “Why does no rotation in 92 days only add 9%? It seems high. Show me the historical data behind that adjustment.” The product produces the historical data. The number is auditable in a way a single-number risk score is not. The conversation moves from “trust the model” to “here is the evidence; let’s talk about it.”
What this is not
This is not novel mathematics. Bayesian updating with explicit priors is standard practice in actuarial science, insurance underwriting, and clinical decision support. What is novel is the application: third-party incident exposure has historically been assessed by gut feel and post-incident questionnaires. Putting it into a Bayesian framework with auditable priors and publishable adjustments is a methodology choice, not a math breakthrough.
The methodology behind it — Dependency-Centric Third-Party Incident Response, or DC-TPIR — is documented in detail in the “Someone Else’s Breach” cluster of articles (linked below). The product runs it. The methodology is published. The numbers are reproducible from the inputs.
What this also is not
This is not a black-box machine-learning score. There is no opaque model that produces a number you cannot question. Every adjustment is a published rule with a documented source. When the rule does not apply to the customer, the adjustment is zero and the line still appears in the breakdown (so the CFO can see what was checked and what was not).
The lazy version looks like this: an opaque model produces “Your GitHub incident exposure is HIGH.” A footnote notes that the model is proprietary. The CFO is asked to approve $400K in immediate containment spend on the basis of HIGH. The CFO asks how HIGH was computed. The vendor says it cannot disclose the model. The CFO declines the spend. The customer takes the loss. This is not a strawman; this is a common failure mode in cyber-risk reporting in 2026.
How the indicator updates while the incident is active
Every term in the decomposition can change. As more confirmations come in from the disclosure, the base rate moves. As the customer rotates secrets in response to the incident, the +9% adjustment shrinks toward zero. As IP allowlisting gets tightened, the -4% becomes -7%. The posterior updates within the hour.
The actions the customer takes feed directly back into the indicator. Containment shows up in the math, not just on the incident-response tracker. The team sees their work move the number in real time, which is a meaningfully better feedback loop than “the incident closed two weeks ago and the next quarterly report will reflect it.”
The compounding effect across the dependency graph
One conditional indicator at 34% probability is one number. The product runs the same computation across every active campaign currently visible from the customer’s integration footprint. Some are low-probability and low-exposure; the system reports them but does not surface them. The Risk Posture Index aggregates all of them.
When two or three active campaigns simultaneously implicate the same dependency — say, three concurrent campaigns targeting GitHub-integrated orgs — the indicators stack. The aggregate exposure climbs faster than the individual ones would suggest. The dependency graph is the only place that compounding effect is visible, and the structural-indicator layer is what surfaces it.
The next article in this series walks through the verified competitive landscape: which enterprise GRC platforms charge what for KRI management, what they actually deliver, and where the gap sits.
Where this matters next
Why your KRIs stopped predicting anything — the pillar. The conditional indicator above is one of four indicator categories — the one that fires during active incidents.
Forward risk vs. backward risk: the board report that shows where you're headed — the framing the auditable Bayesian decomposition sits inside. Forward risk pressure is exactly what this indicator measures.
The $150K GRC dirty secret: manual KRIs at enterprise prices — why no enterprise GRC platform publishes its risk-score reasoning the way the breakdown above does. The methodology gap, in dollars.
Conditional exposure analysis: why your risk isn't what the vendor reported — the full methodology behind the conditional indicator — DC-TPIR, decomposition rules, worked example.
Someone else's breach: why vendor IR is its own discipline — the strategic context. The cluster pillar that establishes vendor incident response as its own discipline, distinct from per-vendor TPRM and from internal IR.