The single source of truth for how the engine produces its output. ALE catalog calibration, attack-path heuristics, audit mapping, control crosswalk, freshness policies. If a CISO asks where a number comes from, this is the page that answers. And the proofs behind a score are independently verifiable — re-check any proof bundle yourself, offline, at /verify.
The dollar-loss number is the headline of every CyberTwin assessment. Here's exactly how we calculate it, with sources for every input.
Estimated from the customer's industry, sector, headcount, and operating model. We err conservative — typically 30–40% lower than industry-mean estimates. Sources: customer's declared environment, calibrated against IBM Cost of a Data Breach 2025 industry segments.
Per-record cost by data sensitivity, anchored to IBM Cost of a Data Breach 2025 (≈ $160 per customer-PII record, more for PHI, less for names-only). IBM's own caveat is load-bearing: that per-record figure derives only from breaches under ~113,000 records and cannot be extrapolated linearly to mega-breaches — so we don't (see the loss law below). Refreshed when IBM publishes the annual report.
Verizon DBIR 2024 + Sophos State of Ransomware 2024 + Coalition Cyber Claims 2024. Probability adjusts for current security posture (a fintech with a full identity provider + endpoint protection + cloud security platform has a meaningfully lower probability than the same fintech with no endpoint product and no SIEM). Adjustments are deterministic and inspectable.
The annual loss expectancy is the mean of a seeded Monte Carlo loss distribution — not a single multiply. Each iteration draws a breach size, prices it with a sublinear cost law (anchored to IBM's per-record cost in the range IBM validates, then degrading as cost ∝ records^0.76 — the Jacobs law — above ~113k records, because a breach 10× larger is not 10× the loss), and multiplies by the industry- and posture-adjusted probability. We read P10 / P50 / P90 off the resulting distribution rather than multiplying the factors' percentiles (which would compound the tails). Same inputs always produce the same band. Source URLs for every benchmark are in the source ledger below.
Per-risk attribution. The register splits the median ALE across your risks in proportion to each risk's inherent score (likelihood × impact), so every risk carries its share of the real exposure and the per-risk dollars sum exactly to the total. It is an attribution to rank what to fix first — not an additive claim that each risk is a separate loss — and it's deterministic and inspectable, never a hand-waved split.
How a tier's savings are calculated — control by control. We do not turn a posture score into a savings percentage. Each recommended stack adds specific capabilities; each capability maps to cited FAIR-CAM control reductions (MFA → 99% of credential vulnerability, immutable backups → 85% of ransomware primary loss, and so on, each backed by ≥2 primary sources). We apply each reduction only to the risks that control actually mitigates, weighted by each risk's share of your exposure, then sum the residuals. A control that defeats credential attacks gets credit for the credential-risk slice of your book — never the whole portfolio. This is deliberately conservative: it is the reason a single control can't claim an outsized, whole-book reduction.
Two honesty consequences worth naming. First, savings are marginal: controls you already operate are priced into your current-state (do-nothing) baseline, so a mature program sees a smaller headline percentage from new spend — even when the dollar ROI stays high. Second, we surface a coverage gap: the share of residual exposure from risks that no control in the catalog yet addresses (today: AI-era and post-quantum risks, where calibrated control-efficacy data doesn't exist). We show it as residual rather than quietly assuming it away.
Compliance scoring is the second-most-scrutinized number in the report. Here's exactly how it works, including the limits we put on derived coverage.
Each catalog product carries explicit mappings to specific controls in our anchor frameworks (ISO 27001, NIST 800-53, GDPR, NIST CSF, CIS v8, PCI DSS). When a customer's environment includes a product with a direct mapping to a control, that control is scored as EXPLICIT — full audit weight. EU AI Act (Regulation (EU) 2024/1689 Articles 9-15 + Annex IV), CMMC L3 (L2 plus 20 enhanced controls from NIST SP 800-172), NIST AI RMF, and SDAIA AI have controls authored and catalogued, but are not yet among the 24 scored frameworks — on the roadmap, not counted in framework coverage.
Frameworks without authored per-product mappings (PDPL-KSA, NCA CCC, NCA CSCC, etc.) inherit coverage via the crosswalk table. If product X satisfies ISO 27001 A.5.16 and ISO 27001 A.5.16 maps to NCA ECC 1-5-3-1 and PDPL-KSA Article 19, we score those controls as DERIVED — capped at 75% per control to acknowledge the inference.
Two honest limits when direct evidence is thin. When NO control has an authored mapping for a framework (all-derived), we show no number at all — the framework reads `not directly scored` rather than a manufactured score. When some, but too little, of the score rests on direct evidence, the number is capped at 70/100 and annotated `(ceiling — limited direct evidence)`. Either way the headline can never overstate coverage we don't actually have.
This is why every score in your report carries a provenance label (EXPLICIT / DERIVED / MIXED). The math is auditable, the limits are documented, and the report is defensible at a real audit because we don't claim direct coverage where it doesn't exist.
These scores reflect what the engine can observe in your configuration, identity, and signal data — not governance, policy, training, or procedural controls, which need a separate attestation. The contradiction-detection panel is the sharp version of this gap.
Configuration extracted from cloud IAM, identity providers, endpoint platforms, network/edge, email, SIEM, and uploaded device configs. Identity-directory exports (group memberships, role assignments, factor enrollment). Signal data from the customer's own telemetry. These are the surfaces that produce EXPLICIT and DERIVED control verdicts — the ones a real audit could re-verify by inspecting the same artefacts we did.
Board-level oversight, written information-security policies, third-party contract review, employee security-awareness training, incident-response runbooks, business-continuity exercises, vendor due diligence. Most controls in NCA ECC v2, SAMA CSF, PDPL-KSA, UAE IA, DESC, DORA, and NIS2 fall in this bucket. No extractor — no matter how good — can score them from configuration. They need a separate attestation.
When a customer attests to a governance control (e.g. 'MFA is enforced for all administrators') and the engine's technical observation disagrees ('mallory@acme.io is an admin with no MFA factor enrolled'), the contradiction-detection panel surfaces the mismatch with both sides cited. That is the disciplined version of the technical-vs-governance gap — attestation on one side, observed configuration on the other, and the engine refuses to silently reconcile them.
Every framework score in the report carries the provenance label introduced in the section above (EXPLICIT / DERIVED / MIXED) plus, where applicable, an all-derived ceiling cap at 70/100. Together with the scope note above, that is how the engine signals — at audit-defensible resolution — what was observed, what was inferred, and what still needs a separate attestation. The short-form note rendered immediately above is reused on every in-product score surface so the framing stays consistent end to end.
Vendor pricing drifts 10–30% per year. A May 2026 PDF generated from a catalog last verified in February 2026 is silently stale. We refuse to ship that.
Every catalog entry carries the date its price was last verified against the source URL. Visible on the Library tab in-app and on the architecture stack output (in-app and PDF).
Full catalog re-verification every 3 months. Currently we're at 99 products, refresh date visible at the bottom of /pricing.
If a customer's environment includes products with last_priced_at over 6 months old, the assessment surfaces a warning: “Some products in your stack haven't been re-verified in 6+ months — pricing may have drifted. Check vendor pages before procurement.”
Cross-vendor attack paths require stitching capability graphs across products that don't natively share a data model. We're explicit about which edges are real-world-observed vs derived-from-config vs inferred-from-pattern.
Edges directly extracted from configuration. An AWS IAM policy granting s3:GetObject to a specific role; a FortiGate policy allowing traffic from an IP range to a specific port. Confidence: high. Audit defensibility: direct.
Edges inferred from configuration patterns plus known capability semantics. An Entra Conditional Access exclusion list for service accounts implies those accounts skip MFA, which combined with a Defender exclusion can yield a credential-pivot path. Confidence: medium. Customer can confirm or remove the edge in-graph.
Edges suggested by industry attack patterns when configuration is incomplete. Rendered as dashed lines with explanatory tooltips. The customer is told 'if your environment is typical, this path likely exists; verify by checking X.' Confidence: low. Always optional, never assumed by the report.
Every edge carries both a tactic code (e.g. TA0001 Initial Access, TA0008 Lateral Movement) and a technique code (e.g. T1078.004 Valid Accounts: Cloud Accounts, T1190 Exploit Public-Facing Application). The current edge-type → technique map covers 26 distinct techniques across 20 parent technique families, sourced from MITRE ATT&CK Enterprise v15+. Ambiguous mappings document the alternatives that were considered inline. The graph tooltip and PDF both render the technique code so SOC analysts and auditors can pivot from a path directly to the MITRE knowledge base.
Each path is matched against a library of 11 named threat groups (ransomware operators, financially motivated groups, and state-sponsored adversaries) segmented by industry + size band. Match strength is the count of group TTPs whose technique codes appear on the path edges; confidence is high if ≥50% of a group's TTPs match, medium if ≥2 match, otherwise low. Top-3 groups per path are surfaced in the panel + PDF.
The graph builder runs one extractor per vendor and stitches their output into a unified attack graph. Today 15 vendors have a graph extractor (identity, endpoint, network, edge/WAF, cloud-IAM, cloud- governance, email, SIEM). Inter-vendor stitches (e.g., Entra group → MDE endpoint group) are explicit dashed edges with the reason for the stitch surfaced in the tooltip — never fabricated.
Uploaded network diagrams are parsed into structured topology (strict-JSON output, deterministic post-processing, two diagram→JSON reference examples). Supported formats: PNG, JPG, draw.io. Visio support is metadata-only today (Visio (metadata-only)) until .vsdx shape extraction ships. Every topology node lands in the graph at confidence='inferred' until a real config upload promotes it to observed.
When an uploaded document contradicts an intake answer (severity info / warning / critical), the customer is shown a blocking modal for criticals (one at a time) and a non-blocking notice for warnings. The chosen resolution is recorded with an audit-log entry; for critical "use the document" resolutions the engine regenerates so the attack-path simulation reflects the corrected ground truth. Auto-mutating intake answers from free-text contradictions is deliberately deferred — the scan output can't yet point back to a specific intake question with certainty.
Every formula, every source, every assumption — the reasoning an auditor reviewing your CyberTwin assessment would want to see.
Updated quarterly. Last revision: May 2026.