Control Framework Mappings

A machine-readable mapping from Permit v1 fields and audit-export-bundle artifacts to specific control IDs across 14 published frameworks. Use this when you need to answer “which Keel evidence can support which control evidence requirement?”

The canonical artifact lives in the open Permit Spec repository:

JSON: keelapi/keel-permit/mappings/control-frameworks.schema-mapping.json
Verification methodology + framing-discipline guardrails: keelapi/keel-permit/mappings/README.md

What’s mapped

Framework	Coverage	Permit fit
California Civil Code §1798.105(d)	(d)(2) security/integrity carve-out; (d)(8) legal-obligation carve-out	Permit timestamp + retention support deletion-exception defense
11 CCR §7150 / §7152 / §7155 (CPPA ADMT regulations)	Risk Assessment Requirements effective Jan 1, 2026	Permit decision + decision_details provide direct support for §7152(a)(3)(G); §7152(a)(6)(A)(iv) via policy_id versioning
EU AI Act Article 12 + 26(6)	High-risk AI logging + deployer ≥6-month retention	Hash chain + Production 180d retention exceeds 26(6) floor
GDPR Article 17(3)(b)	Legal-obligation deletion carve-out	Permit retention scoped to legal/regulatory requirement
AICPA SOC 2 Trust Services Criteria (2017 with Revised Points of Focus 2022)	All 33 common criteria CC1.1 through CC9.2	Hash chain + signed exports map to CC7.2 (anomaly monitoring + change detection); CC8.1 (change management) via policy versioning; CC9 (risk mitigation) via budgets
NIST AI RMF 1.0	Functions GOVERN, MAP, MEASURE, MANAGE with subcategories	14 subcategory mappings; strongest under GOVERN 1.4, MAP 1.1, MEASURE 2.7
ISO/IEC 42001:2023	Clauses 4-10 + Clause 3 definitions + Annex A controls	Clause 9 (Performance evaluation) + Annex A.6.2.8 (AI-System Recording of Event Logs) are the strongest fits — Keel substrate IS this control
OWASP Top 10 for LLM Applications (2025)	LLM01:2025 through LLM10:2025	9 item mappings; strongest under LLM06 (Excessive Agency) — Permit is the pre-execution authorization for every agent action
MITRE ATLAS	14 tactics + ~50 techniques	13 technique mappings concentrated in AI Model Access, Execution, Exfiltration, Impact tactics
OWASP API Security Top 10 (2023)	API1:2023 through API10:2023	8 item mappings; API4 (Unrestricted Resource Consumption) and API5 (Broken Function Level Authorization) are the strongest evidence-support fits
OWASP ASVS v5.0.0	All 17 chapters	6 chapter mappings under V4, V8, V11, V13, V14, V16
FedRAMP / NIST SP 800-53 Rev 5	AU, AC, CM, CA, IR, SI, SC families	23 control mappings; AU family is the strongest fit (AU-9 Protection of Audit Information, AU-10 Non-repudiation, AU-12 Audit Record Generation)
CIS Critical Security Controls v8.1	All 18 controls	7 control mappings; Control 8 (Audit Log Management) is the strongest fit
PCI DSS v4.0.1	All 12 requirements	4 mappings narrowly scoped to AI workloads that touch a customer’s Cardholder Data Environment; Requirement 10 (Log and monitor) is the primary fit

What is verified vs draft

Three verification tiers, distinguished in the JSON’s verification_status block:

Verbatim verified (20 entries) — control IDs and titles fetched directly from an authoritative source on 2026-05-10 (AICPA TSP Section 100 PDF, iTeh ISO/IEC publication preview, NIST 800-53 Rev 5 catalog, OWASP/MITRE/PCI SSC publications, etc.).
Verbatim verified (pre-2026-05-10), 2 entries — EU AI Act Art 26(6) and GDPR Art 17(3)(b), verified in earlier work.
Two-source corroborated, 1 entry — ISO/IEC 42001:2023 individual Annex A control titles (ISMS.online + Mindsetcyber agree on all 38 IDs and semantic content; differ only on stylistic conventions). Exact verbatim typography remains medium-confidence pending the paywalled official Annex A pages.

What Keel is NOT — important framing

Several of the frameworks mapped above have certification/authorization regimes. Keel API, Inc. is NOT certified or authorized under any of them:

Keel is NOT FedRAMP authorized — no JAB Provisional Authorization, no Agency ATO, not listed on the FedRAMP Marketplace. The FedRAMP mapping describes how Keel-produced evidence can support a customer’s NIST 800-53 control implementations within the customer’s existing FedRAMP-authorized boundary.
Keel is NOT PCI-DSS validated — no Attestation of Compliance, no Report on Compliance. The PCI mapping applies narrowly to AI workloads that touch a customer’s Cardholder Data Environment.
Keel is NOT SOC 2 attested — controls are implemented and reviewable today; third-party SOC 2 Type II attestation engagement follows commercial validation. The SOC 2 mapping describes which Trust Services Criteria the Keel substrate supports.
Keel is NOT ISO/IEC 42001 certified — same posture.

The mappings describe how Keel substrate supports a customer’s compliance posture, not Keel-side authorization, certification status, legal advice, audit opinion, or a statement that any customer satisfies a control. The customer and its assessor determine sufficiency.

Explicit non-mappings

The JSON also documents 15 explicit non-mappings — controls and frameworks that Keel substrate does NOT address — so over-claim risk is bounded:

13 of 20 NIST 800-53 control families (Physical Protection, Maintenance, Personnel Security, etc.) are entirely customer responsibility, not Keel substrate
12 of 18 CIS Controls (asset inventory, malware defense, network monitoring, training, penetration testing, etc.) are entirely customer responsibility
8 of 12 PCI DSS requirements are out-of-scope for Permit substrate
API7 (SSRF) and API8 (Security Misconfiguration) in OWASP API Top 10 are explicitly not addressed
4 of 14 MITRE ATLAS tactics (Reconnaissance, Discovery, Persistence, Lateral Movement, C2) are SOC/EDR responsibility, not Permit scope

How to use this

For an auditor or procurement reviewer:

Open the JSON artifact in the keel-permit repo.
Look up the specific control ID you need to evidence (e.g., NIST 800-53 AU-9, SOC 2 CC7.2, ISO/IEC 42001:2023 A.6.2.8).
Read the permit_evidence and evidence_type fields (necessary, direct_support, or partial).
Verify the cited Permit fields against your own audit export — fields are documented in Permit v1 and Closure v2 .

For a developer integrating Keel:

The mapping tells you which Permit fields are evidence-load-bearing for your customer’s compliance program.
Wire-format guarantees in the spec mean these field semantics are stable across Permit v1.

Independent Verification Overview — the verifier’s claim and trust boundary
Three Trust-Root Channels — how verifiers obtain Keel’s public keys
Timestamp Authority Scope — what RFC 3161 timestamps witness and don’t witness
Tampering Detection Matrix — failure codes a verifier emits

The framework mapping artifact is updated whenever a framework releases a new revision or a regulation moves from proposed to adopted. Last updated: 2026-05-10.