How Tool Mappings Are Built
UCPA and TTI both run on the same foundation: ~92,000 mappings between security tools and framework safeguards. Here's how those mappings are produced, where AI is and isn't used, and what review workflow stands behind them.
The Dataset
Approximately 92,000 mappings across 8 mapped frameworks
Every coverage percentage, gap recommendation, and tool ranking in FrameworkMapper rests on the framework_mappings table — a relation between each tool in our catalog and the framework safeguards it can address. The table is populated programmatically; nothing in it is hand-edited in a spreadsheet.
Frameworks covered: CIS Controls v8.1, NIST CSF v2.0, NIST SP 800-53 Rev. 5 (323 base controls), NIST SP 800-171 Rev. 2, CMMC Levels 1 & 2, HIPAA Security Rule, and the Texas Cybersecurity Framework. GovRAMP and CJIS assessments run as overlays on the NIST SP 800-53 baseline, so they draw on the 800-53 mappings rather than a separate catalog.
Mapping Strengths
Three strengths, weighted into coverage
Every mapping is classified into one of three strengths. The classification drives the weighted coverage math used everywhere coverage is reported.
The tool's primary capability addresses the safeguard. Selecting it is the canonical way to implement that control.
Example: An MFA platform mapped direct to CIS 6.5 (Require MFA for Administrative Access).
The tool contributes meaningfully to the safeguard but isn't the primary control. A complementary tool or process is usually needed.
Example: An EDR platform mapped supports to CIS 8.1 (Establish an Audit Log Management Process).
The tool touches the safeguard's domain loosely. A dedicated control is almost certainly required to fully meet the safeguard.
Example: A general SIEM mapped partial to CIS 17.4 (Establish and Maintain an Incident Response Process).
See How coverage is measured for the weighting math and the "mapping is not implementation" caveat.
How They're Produced
AI-assisted classification, versioned prompts, two-stage review
-
1
Tool research
When a tool enters the catalog, an AI model researches its public-facing capabilities (vendor docs, product pages, third-party reviews) and produces a structured capability profile. The model is configurable per environment; today we use either Anthropic Claude (Sonnet 4.6 / Opus 4.7) or a self-hosted Open-WebUI model. The model choice is recorded with each generated record so historical decisions remain traceable.
-
2
Mapping classification
For each (tool, framework) pair, a second AI pass classifies the tool against each safeguard in that framework. The output is a value in {'direct','supports','partial', null} plus a short rationale string. The classifier uses a versioned prompt template stored in the ai_prompts table — every edit to the prompt creates a new row in ai_prompt_versions so the prompt that produced a mapping can be retrieved later. Output values are server-side-validated against the enum before insert.
-
3
Human review queue
Newly generated mappings are persisted with status = 'pending' and surfaced in an internal review queue. Reviewers (Viosoph security analysts) either approve the mapping unchanged, re-rate it (e.g., downgrade direct to supports), or reject it. Approval flips the status to 'approved' and stamps the reviewed_by / reviewed_at columns. Rejected mappings are deleted and the decision is fed back into prompt-template tuning.
-
4
Refresh triggers
Mappings are re-evaluated when (a) a source framework releases a new revision (e.g., CIS Controls v8.1 → a future v9), (b) a tool's product capabilities materially change, or (c) a customer disputes a mapping. The platform also runs an automated "drift" check that compares a tool's current capability profile against the profile that produced its mappings; significant drift requeues the tool for re-classification.
Review Status
Where we are with human review — in real numbers
We don't claim every mapping has been hand-validated. About half of the mappings in the catalog have been reviewed and approved by an analyst; the rest are AI-generated and still in the queue. The split below reflects the live dev catalog and is the same split that drives coverage math today.
| Framework | Approved | Pending review | Total | % Approved |
|---|---|---|---|---|
| CIS Controls v8.1 | 16,183 | 6,148 | 22,331 | 72.5% |
| HIPAA Security Rule | 4,349 | 4,041 | 8,390 | 51.8% |
| Texas Cybersecurity Framework | 4,072 | 4,619 | 8,691 | 46.9% |
| NIST CSF v2.0 | 4,791 | 6,109 | 10,900 | 44.0% |
| CMMC Level 2 | 5,628 | 7,588 | 13,216 | 42.6% |
| NIST SP 800-171 Rev. 2 | 5,138 | 7,401 | 12,539 | 41.0% |
| NIST SP 800-53 Rev. 5 | 5,076 | 7,822 | 12,898 | 39.4% |
| CMMC Level 1 | 1,320 | 2,239 | 3,559 | 37.1% |
| Total | 46,557 | 45,967 | 92,524 | 50.3% |
Honest disclosure: today's coverage math uses every mapping, approved or not.
The gap-optimization SQL filters by framework, not by review status. That means a customer's coverage % is computed using both approved mappings and pending AI-generated mappings. We chose this trade-off so coverage stays useful while review completes; the alternative (approved-only) would under-state coverage for newer frameworks. A future release will surface the approved / pending split per safeguard in the customer UI so the trade-off is visible at the row level.
AI Transparency
Where AI is used — and where it isn't
A clean line: AI helps us produce the catalog content. Every number a customer sees is deterministic and reproducible.
AI is used for
- Tool research — capability profiles built from public vendor materials at catalog entry and on refresh.
- Mapping classification — first-pass direct / supports / partial assignment for each (tool, safeguard) pair, then queued for human review.
- Gap-optimization narrative — the prose paragraphs in PDF reports and assessment summaries. Numbers in those reports come from deterministic queries; only the wording is AI.
AI is NOT used for
- UCPA priority scoring — a seven-factor weighted formula. Same inputs → same score, always.
- Tool Trust Index — four additive signals plus a deterministic KEV multiplier, calibrated per vertical.
- Coverage math — weighted-sum SQL with fixed coefficients (direct=1.0, supports=0.75, partial=0.5).
- Threat-actor data — manually curated from CISA / FBI / MS-ISAC / HHS / DBIR advisories; every actor record carries source URLs and dates.
- Any numeric output the customer sees — coverage %, priority score, TTI score, weight values, threat amplifiers. All deterministic.
Buyers in compliance-sensitive verticals (CMMC, healthcare, federal) sometimes need to attest that AI isn't making scoring decisions on their behalf. This page is intended to support that attestation. If you need a more detailed disclosure for an audit, contact us.
Validate For Your Environment
Treat the catalog as a planning aid, not an attestation
Even the strongest direct mapping says only that a tool has the capability to address a safeguard. Whether it actually does in your environment depends on configuration, deployment scope, monitoring, and operational maturity — things the catalog can't see. The footer on every page of FrameworkMapper says this; the coverage caveat on every gap-optimization API response says this; we say it here too because it's the single most important framing for using the platform responsibly.
- ›Review the mappings for the tools you actually deploy before treating coverage % as attestation-grade.
- ›If you find a mapping you disagree with, email us. Disputed mappings are reviewed and either re-rated or rejected; both outcomes feed back into prompt tuning.
- ›For compliance evidence, pair the platform's planning output with operational evidence (configuration audits, monitoring dashboards, incident logs). The platform won't replace those artifacts.