ISO/IEC 42001 ↔ LedgerProof Receipt Mapping Field-by-field map of 38 Annex A controls to LedgerProof Receipt structure

Document purpose: Show how LedgerProof Receipts satisfy specific ISO/IEC 42001:2023 (AI Management Systems) controls. Hand this to any Chief Risk Officer, Chief Compliance Officer, or General Counsel evaluating LedgerProof for enterprise deployment.

ISO/IEC 42001 published: December 2023

LedgerProof Receipt format: LPR v1.0 (live in production); v1.1 in development; v1.2 in spec drafting

Coverage summary (v1.0 today): 10 fully covered · 10 partial · 18 customer-process scope · 7 of 8 controls in A.6 AI System Life Cycle are fully covered; the eighth (A.6.1.2) is partial

Stable URL: https://spec.ledgerproofhq.io/mappings/iso-42001

License: Published under CC BY 4.0 to enable unrestricted citation by EU institutions, Member State competent authorities, notified bodies, ISO 42001 internal auditors, and the press.

How to read this mapping

Full LedgerProof Receipts directly satisfy the control requirement. The auditor can verify by inspecting receipt fields.
Partial LedgerProof Receipts satisfy part of the control. The remainder is satisfied by the customer's existing GRC platform, policy documentation, or process controls.
Out of scope The control is satisfied by customer processes, not by LedgerProof. LedgerProof Receipts may still serve as supporting evidence inside those processes.

A.2 — Policies related to AI

Control	Title	Coverage	Receipt field / mechanism
`A.2.2`	AI policy	Out of scope	Customer policy responsibility; receipts can be referenced as the technical enforcement layer
`A.2.3`	Alignment with other organizational policies	Out of scope	Customer governance responsibility
`A.2.4`	Review of the AI policy	Out of scope	Customer cycle responsibility

A.3 — Internal organization

Control	Title	Coverage	Receipt field / mechanism
`A.3.2`	AI roles and responsibilities	Partial	`issuer_did` field identifies the responsible party for each AI output; receipts establish a provable chain of authority
`A.3.3`	Reporting of concerns	Out of scope	Customer process responsibility

A.4 — Resources for AI systems

Control	Title	Coverage	Receipt field / mechanism
`A.4.2`	Resource documentation	Partial	`system_metadata` field documents AI system, model version, and deployment context at the time of each receipt
`A.4.3`	Data resources	Partial	`data_lineage` field (when provided) documents input data sources for each output
`A.4.4`	Tooling resources	Out of scope	Customer SBOM responsibility; receipts can reference SBOM hashes
`A.4.5`	System and computing resources	Out of scope	Customer infrastructure documentation
`A.4.6`	Human resources	Out of scope	Customer HR responsibility

A.5 — Assessing impacts of AI systems

Control	Title	Coverage	Receipt field / mechanism
`A.5.2`	AI system impact assessment process	Out of scope	Customer process; LedgerProof Receipts serve as the evidence layer for the assessment
`A.5.3`	Documentation of AI system impact assessments	Full	Impact assessment outcomes anchored as `assessment_receipt/v1` entries; Foundation Canonical Registry resolves disputes
`A.5.4`	Assessing AI system impacts on individuals or groups	Out of scope (v1.0)	Customer process responsibility under ISO 42001 Control A.4 risk tiering. Annex III classification field deferred to OCPP-AI v1.2 `system_classification` profile (ETA Q4 2026); until then, the customer keys this in their GRC tool against the receipt hash
`A.5.5`	Assessing societal impacts of AI systems	Out of scope	Customer responsibility; LedgerProof can record outputs of such assessments

A.6 — AI system life cycle 7 of 8 controls fully covered, 1 partial

This section is the core of LedgerProof's coverage. Seven of the eight controls in A.6 are fully satisfied by LedgerProof Receipts; the eighth (A.6.1.2 — objectives for responsible development) is partial because objectives are deployer-declared. The receipt set is the AI system life cycle audit trail for events that have occurred.

Control	Title	Coverage	Receipt field / mechanism
`A.6.1.2`	Objectives for responsible development of AI systems	Partial	`responsible_ai_profile` field declares applicable framework (RIL commitments, Constitutional AI, etc.)
`A.6.1.3`	Processes for responsible AI system design and development	Full	Every design, training, and evaluation event anchored as a receipt; Foundation lineage chains (LPR 1.2) reconstruct the full development history
`A.6.2.2`	AI system requirements and specification	Full	`specification_hash` field anchors the requirements document; receipts cryptographically bind outputs to specifications
`A.6.2.3`	Documentation of AI system design and development	Full	Lineage chains (LPR 1.2) anchor every design artifact, model version, training run, and evaluation result
`A.6.2.4`	AI system verification and validation	Full	Verification events anchored as `verification/v1` receipts; cross-verifiable by any third party
`A.6.2.5`	AI system deployment	Full	Deployment events anchored; `deployer_id` field documents responsible party (GDPR-safe — email rejected at parse time)
`A.6.2.6`	AI system operation and monitoring	Partial (v1.0); Full (v1.1)	Each successful inference call emits a receipt evidencing the operation event. Continuous monitoring of failures, content-filter trips, and drift requires the `IncidentReceipt` schema landing in OCPP-AI v1.1 (ETA ~6 weeks); until then, the customer's operational monitoring system is the source of truth
`A.6.2.7`	AI system technical documentation	Full	Every documentation revision is anchored; Foundation Canonical Registry resolves which version is authoritative
`A.6.2.8`	AI system event logs	Full	Every AI-touched decision is a receipt; the receipt set IS the event log

A.7 — Data for AI systems

Control	Title	Coverage	Receipt field / mechanism
`A.7.2`	Data for the development and enhancement of AI systems	Partial	`training_data_hash` field documents training data corpus; data lineage chains anchor data provenance
`A.7.3`	Acquisition of data	Partial	`data_acquisition_source` field documents provenance
`A.7.4`	Quality of data for AI systems	Out of scope	Customer data quality processes; LedgerProof Receipts anchor quality-check outcomes
`A.7.5`	Data provenance	Full	Lineage chains (LPR 1.2 §3) cryptographically link every output to its input data sources
`A.7.6`	Data preparation	Partial	Data preparation outputs anchored

A.8 — Information for interested parties of AI systems

This section maps directly to Article 50 transparency obligations.

Control	Title	Coverage	Receipt field / mechanism
`A.8.2`	System documentation and information for users	Full	Receipt content is the documentation; verifier portal makes it accessible to any user
`A.8.3`	External reporting	Full	Audit-Ready Compliance Stamp PDF satisfies the regulator-facing reporting requirement
`A.8.4`	Communication of incidents	Out of scope (v1.0); Partial (v1.1)	`IncidentReceipt` schema (capturing failure_class, content_filter trigger, downstream_action_taken, responder signature) ships in OCPP-AI v1.1 (ETA ~6 weeks). Today: customer incident management system is the source of truth; post-mortem outcomes can be anchored via the existing `ChatbotSessionReceipt` profile
`A.8.5`	Information for interested parties	Full	Public verifier portal at `verify.ledgerproofhq.io` provides interested-party access; aligns with Article 50(1) chatbot disclosure

A.9 — Use of AI systems

Control	Title	Coverage	Receipt field / mechanism
`A.9.2`	Processes for responsible use of AI systems	Partial	Receipts establish the audit trail; customer policy defines acceptable use
`A.9.3`	Objectives for responsible use of AI systems	Out of scope	Customer responsibility
`A.9.4`	Intended use of the AI system	Out of scope (v1.0)	Intended-use classification field is deferred to OCPP-AI v1.2 `governance_context` profile (ETA Q4 2026). Until then, the customer declares intended use in their AIMS documentation and keys it against the receipt hash

A.10 — Third-party and customer relationships

Control	Title	Coverage	Receipt field / mechanism
`A.10.2`	Allocating responsibilities	Out of scope (v1.0)	Provider/Deployer classification under AI Act Article 25 is a customer legal determination. A `provider_deployer_classification` field will land in OCPP-AI v1.2 `governance_context` profile (ETA Q4 2026); until then, the determination lives in the customer's master service agreement and is keyed off the receipt hash
`A.10.3`	Suppliers	Out of scope	Customer vendor management; receipts can anchor third-party-vendor attestations
`A.10.4`	Customers	Out of scope	Customer relationship management

Coverage summary

Coverage rating	v1.0 (today)	v1.1 (~6w)	v1.2 (~Q4)
Full	10	12	14
Partial	10	9	10
Out of scope	18	17	14
Total Annex A controls	38	38	38

Critical insight for the CRO / CCO

LedgerProof v1.0 provides full or partial coverage of 20 of the 38 ISO/IEC 42001 Annex A controls (53%) — and 7 of the 8 controls in A.6 AI System Life Cycle are fully covered, with the eighth at partial coverage. A.6 is the heart of the standard.

The remaining 47% are customer-process controls that no implementation tool can satisfy alone. LedgerProof Receipts serve as evidence within those customer processes when needed.

Coverage grows to 55% with OCPP-AI v1.1 (IncidentReceipt schema closes A.6.2.6 and A.8.4) and 63% with OCPP-AI v1.2 (profile system: governance_context closes A.9.4 and A.10.2; system_classification profile re-opens A.5.4 as deployer-asserted).

How to use this document in regulator conversations

Hand it to your ISO 42001 internal auditor. Their job becomes easier when the technical evidence layer is documented.
Reference specific control numbers in your AIMS documentation. "Control A.6.2.6 is satisfied by LedgerProof Receipts; see attached LedgerProof Receipt sample."
Make the Audit-Ready Compliance Stamp PDF generation part of your scheduled AIMS reviews. The PDF is generated automatically; the regulator sees a consistent format.

Companion mappings

EU AI Act Article 50 ↔ LedgerProof Mapping — sub-clause-by-sub-clause coverage
NIST AI Risk Management Framework ↔ LedgerProof Mapping — coverage rating against NIST AI RMF Govern / Map / Measure / Manage functions
DORA Article 28 ↔ LedgerProof Mapping — ICT third-party risk management
MiFID II Article 16 ↔ LedgerProof Mapping — record-keeping requirements

Companion mappings publish progressively at https://spec.ledgerproofhq.io/mappings/. Sign up to be notified at ledgerproofhq.io/commercial/founding-members.

Document version control

Version	Date	Author	Changes
v1.0	June 2026	LedgerProof Foundation	Initial mapping against ISO/IEC 42001:2023 Annex A

When ISO/IEC 42001 is revised, this mapping will be revised accordingly. The current authoritative version is always at https://spec.ledgerproofhq.io/mappings/iso-42001.