The vendor disclosed that "a subset of customers" was affected. The board is asking what that means for the organization. The default answer is some variant of "we're investigating" or "we believe our exposure is limited." Neither is a defensible quantitative position. Neither survives the SEC examiner's question three years from now: on what basis did you determine materiality on Day 1?
Standard FAIR doesn't answer this question, because FAIR was built for a different problem structure. In standard FAIR, you estimate the probability that a threat event occurs. In a third-party incident, the threat event has already occurred. The question that needs an answer is whether you are within its scope — and if so, what the actual loss magnitude is given your specific dependency profile.
This piece formalizes the conditional exposure analysis that underlies the Dependency-Centric Third-Party Incident Response (DC-TPIR) framework, with worked example, Bayesian updating mechanics, and the calibrated-estimation protocol that keeps the numbers honest under time pressure.
The decomposition that makes estimation tractable
The exposure probability you actually need is P(Exposed | Incident, Dependency Profile). Estimating that quantity directly is hard. Decomposing it into three estimable factors is much easier:
P(Exposed | I, D) = P(InScope) × P(Affected | InScope) × P(Exploitable | Affected)
Where:
• P(InScope) — probability that the customer falls within the incident's affected population
• P(Affected | InScope) — probability that the customer's specific usage was impacted, given they're in scope
• P(Exploitable | Affected) — probability that exposure leads to actual harm given the customer's compensating controls
Each factor is independently estimable from observable evidence. Each factor updates over time as the incident evolves. The decomposition produces a coherent estimate rather than a single guess — and produces a confidence interval rather than a point estimate, which matters at the moment a regulator asks how the materiality determination was made.
Factor 1 — P(InScope): start from vendor disclosure language
The vendor's disclosure language carries a prior. The prior table is derived from analyzing several hundred historical vendor incident disclosures against actual customer-impact data:
The priors are starting points, not final answers. They get refined within the first hours of the incident as the vendor publishes more specific scope criteria — segment, tier, region, product feature — that you can check directly against your account.
Factor 2 — P(Affected | InScope): three overlap dimensions
Being in scope doesn't mean being affected. A customer in the affected population may not have been using the affected feature, in the affected time window, with the affected data classes. The conditional probability is the weighted combination of three overlap scores:
P(Affected | InScope) = ωf · Of + ωd · Od + ωt · Ot
• Of — Feature overlap: fraction of incident-affected features the customer actually uses
• Od — Data overlap: binary indicator (1 if any overlap with affected data classes; 0 otherwise)
• Ot — Time overlap: fraction of vendor's exposure window during which the customer had activity
Weights ω sum to 1; typical practice is ωf = 0.4, ωd = 0.4, ωt = 0.2 — adjust based on the failure mode profile of the specific incident.
The mechanical part is straightforward. The interesting part is what each overlap actually measures.
Feature overlap
If the vendor disclosed that "customers using Feature X" were affected and you used Feature X, O_f = 1. If you didn't, O_f = 0. If the affected features aren't yet specified, use 0.5 (maximum uncertainty) and update as vendor publishes more detail.
Data overlap
Pull the data-flow record for the vendor. For each data class the vendor disclosed as affected (e.g., "session tokens," "customer PII," "support case attachments"), check whether your usage included that data class. Binary indicator: 1 if any overlap; 0 if none.
Time overlap
The vendor's disclosed exposure window is a date range. Pull your activity logs for that window. Compute the fraction of the window during which you had usage that would have placed you in the exposure path. O_t = (your activity hours during window) ÷ (total window hours).
Factor 3 — P(Exploitable | Affected): control effectiveness
Even an affected customer may not actually suffer harm. The compensating controls you have in place reduce the probability that exposure converts to loss. For each of the four failure modes the incident triggers, the compensating-control map is different:
P(Exploitable | Affected) = 1 – control effectiveness. The control effectiveness number is itself an estimate with uncertainty; document the reasoning behind whichever value you pick.
Worked example — Okta-style identity provider breach
The vendor disclosure: "A threat actor accessed our customer support case management system. A subset of customers' session tokens and configuration data may have been exposed. Investigation is ongoing."
Failure modes triggered: Confidentiality (data exposure) + Control (session tokens could enable admin access). Φ = (1, 0, 0, 1).
Your dependency profile: Okta is your sole identity provider. SSO to 47 SaaS applications. MFA enforced for all employees. Twelve support tickets in the past year, three of which contained HAR files (which can carry session tokens).
Factor 1 — P(InScope)
Vendor language is "subset of customers" → prior 0.30. No tier / segment / region criteria published yet, so no adjustment. P(InScope) = 0.30.
Factor 2 — P(Affected | InScope)
Feature overlap O_f: support case management system is the affected feature; we use support; O_f = 1.0. Data overlap O_d: HAR files may contain session tokens; we have HAR files in 3 of 12 support tickets; O_d = 1.0. Time overlap O_t: 3 tickets fall within the disclosed exposure window of 12 we filed; O_t = 0.25. Weighted: 0.4(1.0) + 0.4(1.0) + 0.2(0.25) = 0.85.
Factor 3 — P(Exploitable | Affected)
Compensating controls: MFA enforced, but session tokens bypass MFA by design (the token IS the authenticated state). Network segmentation present but Okta's SSO trust crosses many tenant boundaries. Control effectiveness estimated at 0.30. P(Exploitable | Affected) = 0.70.
Combined
P(Exposed) = 0.30 × 0.85 × 0.70 = 0.18, or 18%.
"We estimate 18% exposure to the Okta incident, with a confidence interval of 8% to 32% accounting for the three sources of uncertainty in our estimate. The exposure is driven primarily by the support case management system (where we had 3 active HAR file submissions during the disclosed window) and the inability of MFA to compensate for stolen session tokens. We are treating this as material pending vendor scope narrowing." That sentence beats "we're investigating." It also beats "we believe our exposure is limited." And it gives the SEC examiner three years from now exactly what they need to evaluate the materiality determination.
Loss magnitude — converting exposure to dollars
Once exposure probability is established, the loss magnitude conditional on exposure depends on the failure mode profile. Each mode has its own loss function parameterized by the dependency profile:
For the Okta example: containment cost ($50K credential rotation across 47 SaaS apps), forensics ($150K), potential secondary breach (~$1M with ~10% probability), regulatory notification if PII determined to be in HAR files (~$200K with ~50% probability). Expected loss magnitude if exposed: $50K + $150K + 0.1·$1M + 0.5·$200K = $400K.
Combined risk exposure: P(Exposed) × E[LM | Exposed] = 0.18 × $400K = $72K.
Bayesian updating — when new information arrives
Vendor incidents evolve. Hour 4, the vendor publishes scope criteria. Day 2, the vendor identifies specific affected features. Day 5, the vendor confirms whether you're in the affected list. Each update is new evidence that should refine the exposure estimate via Bayes' theorem.
P(Exposed | It+1) = [L(E | Exposed) × P(Exposed | It)] / [L(E | Exposed) × P(Exposed | It) + L(E | ¬Exposed) × (1 – P(Exposed | It))]
Where E is the new evidence, and L(E | state) is the likelihood of observing E given each state. The update produces a posterior probability that's coherent with both the prior estimate and the new evidence — far better than reframing the estimate from scratch each time the vendor publishes new information.
Worked example of updating through an incident:
T+0 — Initial disclosure
"Investigating potential security issue." P(InScope) = 0.50. P(Exposed) = 0.50 × 0.50 × 0.80 = 0.20.
T+24 — Vendor narrows
"Affects customers using Feature X." You don't use Feature X. Update P(Affected | InScope) from 0.5 to 0.05 (allowing residual uncertainty). P(Exposed) = 0.50 × 0.05 × 0.80 = 0.02.
T+48 — Vendor confirms
"Customer organization not in affected population." Update P(InScope) from 0.50 to 0.02 (allowing for vendor error). P(Exposed) = 0.02 × 0.05 × 0.80 = 0.001.
Decision
Accept residual risk. Archive incident record with the full update log as audit trail.
Calibration — keeping the estimates honest under pressure
Real-time incident response is the worst conditions for unbiased probability estimation. Time pressure exacerbates availability heuristic (overweighting recent vivid incidents) and anchoring (insufficient adjustment from initial estimates). The Tetlock superforecasting research demonstrated that calibration training — iterative practice with feedback — reduces these biases substantially.
Practical calibration protocol for an incident response team:
Pre-incident calibration
Annual 50-question baseline assessment producing a calibration curve (stated confidence vs actual accuracy). Quarterly refreshers. Reference-class reasoning training (estimate against similar historical incidents before making a fresh estimate). Brier score tracking per estimator.
During-incident discipline
Decomposition (estimate the three factors separately rather than the joint). Independent estimation (multiple team members estimate independently before discussing). Explicit confidence intervals (state ranges, not point estimates). Aggregation via inverse Brier score weighting (better-calibrated estimators get more weight).
The combined effect: a team that practices calibration produces 30–40% more accurate exposure estimates under time pressure than a team that doesn't, with the gap most pronounced exactly when the stakes are highest.
The bottom line
Conditional exposure analysis decomposes a hard estimation problem into three tractable ones, produces a coherent exposure probability with explicit uncertainty bounds, updates that probability as the incident evolves through formal Bayesian inference, and grounds the entire analysis in calibrated estimation that survives scrutiny from regulators and auditors. It's the mathematical core of vendor incident response done as a discipline rather than as an improvisation — the work that converts "we believe our exposure is limited" into a defensible quantitative position that compounds across incidents.
Run the conditional analysis on real incidents, with real numbers
vCISO Lite operationalizes the DC-TPIR conditional exposure analysis — auto-pulling vendor disclosure language and computing scope priors, querying your dependency profile for the three overlap dimensions, surfacing the compensating-control map per failure mode, propagating uncertainty through to a defensible confidence interval, and running the Bayesian updates as new information arrives. Built for the security teams that need their materiality determinations to survive both Day-1 stakeholder pressure and Year-3 regulator review.
If your team is making vendor incident exposure calls from gut feel and you're tired of explaining the rationale three months later, visit vcisolite.com to learn more and get started.
The mathematical foundations of conditional exposure analysis are formalized in the working paper "DC-TPIR: A Dependency-Centric Framework for Quantitative Third-Party Incident Response", which extends the FAIR model to handle conditional exposure assessment given observed vendor incidents.
Where this matters next
Someone else's breach: why vendor IR is its own discipline — the strategic context that establishes why conditional exposure analysis exists as a distinct methodology rather than a FAIR extension.
Stay, exit, or mitigate: the vendor incident decision framework — what to do with the exposure estimate once produced, including risk-adjusted cost computation and decision anti-patterns.
Mitigation debt: the silent risk that accumulates between vendor incidents — the institutional-memory dimension that determines how the conditional exposure estimate updates between incidents at the same vendor.
Cyber risk quantification for mid-market — the FAIR-based five-scenario methodology that conditional exposure analysis extends with the conditional-on-incident structure.
Vendor concentration risk: the dimension per-vendor TPRM misses — the standing-program companion. The exposure analysis above answers "what is the loss from THIS incident at THIS vendor"; concentration analysis answers "how many of our other vendors share this same upstream and would land in the same exposure model next."