Methodology

How the Coverage Simulator calculates your compliance ceiling

The simulator returns one number per framework: the share of controls your selected integrations evidence today, and the maximum you could reach if you connected every available integration. The math is small enough to run client-side in milliseconds. This page documents exactly how.

The data model

The simulator runs over a frozen matrix at docs/coverage_matrix_propagated.json. Each row is one (integration × framework) pair with three fields that drive the math:

full_control_refs controls the integration evidences via a typed FINDING_MAP. High-confidence, audit-defensible.
partial_control_refs controls the integration evidences via keyword-matching against control text. Present, but lower-confidence.
denom the framework's total control count. The denominator for percentage math.

28 integrations × 6 frameworks = 168 rows. Last refresh: 2026-05-01.

The calculation

For each framework, given a set of selected integrations:

Full coverage = |union of full_control_refs across selected integrations| ÷ denom
Any coverage = |union of (full_control_refs ∪ partial_control_refs) across selected integrations| ÷ denom

The union is the deduplication: if M365 evidences SOC 2 CC6.1 fully and Okta also evidences CC6.1 fully, that's one control covered, not two. Standard set math, no fancy scoring.

About the denominator

What counts as one "control" is opinionated. SOC 2 has Trust Services Criteria (~358) that decompose into points of focus (~600+); auditors vary on whether to evaluate at the criterion or point-of-focus level. We currently count parent criteria as the denominator. ISO 27001 (138 controls in Annex A 2022), NIST CSF v2.0 (127 sub-categories), CMMC v2 (427 control objectives), CIS v8 (171 safeguards), and HIPAA (120) follow similar parent-level counting.

A different denominator choice yields a different percentage sometimes by 30%+. We picked the most commonly-cited level for each framework; an auditor working at a finer granularity will get different numbers from the same matrix data.

Full vs partial what they mean

Full evidence

Comes from a deep-tier integration. Each deep integration ships with a typed FINDING_MAP defining which findings it produces and which controls each finding evidences. Example: M365's "MFA enforced via Conditional Access" finding maps to SOC 2 CC6.1, ISO 27001 A.5.16, NIST CSF PR.AA-04, etc.

Per-finding mappings are explicit, reviewed, and versioned. When an auditor asks "show me the evidence for CC6.1," the integration emits a row with the finding ID, the timestamp, the source data, and the control reference.

Partial evidence

Comes from a standard-tier integration. Standard integrations don't define explicit per-finding mappings. Instead, evidence is generated by keyword-matching the integration's output against the control text.

This works for "this integration is plausibly relevant to this control" but not for "this integration definitively evidences this control." So we count it as partial.

What full / partial actually measure

Important caveat: the deep-vs-standard distinction reflects how the mapping was created, not its objective evidence quality. A well-tested keyword match could be more precise than a hand-typed mapping made by a tired engineer at midnight.

What we mean by "full" is "we wrote an explicit mapping and reviewed it internally." What we mean by "partial" is "we matched the integration's output against control text and the result fired." Both are subject to internal review only, not third-party audit. We discuss external validation below.

Why two partials don't promote to full

This is where most compliance marketing lies. The temptation: if Tenable evidences CC6.6 partially (vuln scanning) and ServiceNow also evidences CC6.6 partially (ticketing), surely together that's full evidence?

Sometimes yes, often no. The default for our simulator is "still partial." Promotion to full requires explicit per-pair confirmation that the two integrations evidence different dimensions of the same control:

Additive (becomes full): the two partials evidence DIFFERENT dimensions of the same control. Example: Tenable evidences vuln identification (one dimension of vuln management); a separate ticketing integration evidences remediation tracking (different dimension). Together they cover both halves.
Redundant (stays partial): the two partials evidence the SAME dimension at different sample populations. Example: CrowdStrike + SentinelOne both partial-cover an IR-process control via "EDR signal" same dimension, just two tools.

Without an explicit pair-relationship entry, the simulator defaults to redundant. This is conservative on purpose. The alternative assuming additivity by default silently inflates ceilings and makes prospects believe their stack is more covered than it is.

The process-control floor (and what's actually in the gap)

Some controls structurally cannot be evidenced by integrations. They require:

Policy work written documents (acceptable use, incident response plans, business continuity).
Attestation signed statements from people (background checks, training acknowledgments, vendor agreements).
Manual procedure periodic tasks performed by humans (quarterly access reviews, annual risk assessments, tabletop exercises).
Human review judgment calls (severity classifications, exception approvals, control-design assessments).

The gap between your bar and the ceiling on the simulator is this floor but not only this floor. Honest decomposition of what's in the gap:

Genuinely structural process controls (the four bullets above) the largest piece, true floor.
Controls that could be covered by integrations we don't yet ship. Example: HRIS integration would evidence background-check controls. We don't ship one yet; until we do, those controls show as floor even though they're technically evidenceable.
Controls where two partials additively combine. Tenable + ServiceNow on vuln management is the classic case (identification + remediation tracking). The simulator promotes these to full when both members of a complementary pair are in your selection. The seed pair-list is hand-curated and conservative; pairs we haven't catalogued yet stay partial.

We sell the gap as "process floor" for clarity, but #2 and #3 contribute too. SOC 2's true structural floor is closer to 40% than the apparent 55%; the rest is build-out we owe ourselves.

What the simulator does NOT do

Score your tenant. The public simulator runs on hypothetical stacks. The authenticated version (inside the product) factors in your real evidence freshness, control mappings, and audit windows.
Replace an audit. Coverage % is not the same as audit readiness. Auditors evaluate evidence quality, time-bounded sampling, and control-design effectiveness none of which a percentage captures.
Promise a passing score. Even at the integration ceiling, the process floor remains. Real compliance is integration coverage + policy work + attestation + manual procedure + human review.
Account for the audit period. Coverage shown is for "today, going forward." Audits cover periods (typically 3, 6, or 12 months); evidence collected today doesn't retroactively cover Q1 if you connected the integration in Q3. The authenticated version factors in audit windows; the public version assumes evergreen coverage.
Account for tenant-specific applicability. Some controls don't apply to all customers (HITRUST in non-healthcare, certain CMMC enclaves only for DoD work). The public simulator counts every control as applicable; the authenticated version applies tenant-specific scoping.

External validation status

Our mappings are reviewed internally, not externally audited. No firm (Coalfire, Schellman, A-LIGN, etc.) has signed off on the FINDING_MAP entries or the keyword-match standard-tier mappings. The methodology is reproducible from the published JSON; the authority is ours, not an auditor's.

What this means in practice:

You can challenge any specific (integration × control) mapping by reading the matrix file. We'll engage with the disagreement publicly.
Our deep-tier mappings often align with AICPA's SOC 2 implementation guide and NIST CSF v2.0 Informative References, but we don't yet badge each mapping with the external authority that backs it. Roadmap item.
Third-party auditor validation of the deep-tier mappings (specifically for SOC 2 trust services criteria) is a strategic investment we're scoping. When that ships, we'll publish the validation letter.

If you're a buyer evaluating coverage claims from any GRC platform, ask: "Has your mapping been reviewed by an auditing firm? Which firm? Can I see the report?" Most platforms can't answer affirmatively. We can't either, today but we don't claim otherwise.

Why this matters competitively

Drata, Vanta, and Cynomi marketing tends to claim percentages without showing the work. "80% SOC 2 coverage" measured how, against what denominator, with what dedup rules? The answer is rarely defensible.

Our published methodology lets you (a) reproduce our numbers, (b) flag specific mappings you disagree with, and (c) compare like-for-like with competitors. That's the standard we hold ourselves to and it's the standard a sophisticated buyer should hold any GRC platform to.

How the matrix is updated

The matrix is regenerated whenever:

A new integration is added (deep or standard tier).
A finding map is updated (new finding kinds, refined control mappings).
A framework's control set changes (e.g., NIST CSF major version bumps).

Each refresh replaces the frozen JSON file in the repo, which the simulator imports at build time. There is no live database lookup the math is fully static for both the public and authenticated versions.

Open questions we're working on

Cross-framework mapping inference. Our team is building an LLM pipeline to propose new control-to-control mappings between frameworks (SOC 2 ↔ ISO 27001, etc.). Output is reviewed by humans before promoting to authoritative.
Pairwise additivity entries. The current default is "partials are redundant." We're identifying specific (integration A × integration B × control) pairs where the additive case applies, with documented reasoning per pair. The simulator will surface these once enough are catalogued.
Time-bounded coverage. A control evidenced today doesn't help an audit covering Q1 if you connected the integration in Q3. The authenticated version factors in audit windows; the public version assumes "today, going forward."

References

The simulator itself toggle integrations, see the math live
The frozen matrix file: docs/coverage_matrix_propagated.json in the open-source product repo
The evidence weight rubric: docs/evidence_weight_rubric.md
Blog for posts on integration coverage, audit-readiness, and compliance program design