Frameworks · Standards and guidance

qodiqa and ISO/IEC 42001

qodiqa checks each AI request before the call and keeps tamper-evident, offline-verifiable evidence. This page shows where that evidence relates to ISO/IEC 42001, and where it does not.

Standard
ISO/IEC
First edition, December 2023.
Verified 2026-11-03

Read the official text Back to all frameworks

Overview

What it is

Issuer: ISO/IEC
Type: Standard
Status: ISO/IEC 42001:2023, first edition (December 2023)
Official text: www.iso.org

ISO/IEC 42001:2023, Artificial intelligence: Management system. ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system inside an organisation. It is a management-system standard, like ISO/IEC 27001, and organisations can be audited against it.

Who it applies to. Any organisation that provides or uses AI-based products or services and wants a managed, auditable approach to AI risk and responsibility.

Where it meets qodiqa

The parts of ISO/IEC 42001 where the evidence matters.

Record-keeping and logging

Event logs that are hash-chained and checkable by an independent verifier.

Human oversight

Revocation, a kill switch and bound approvals for the human-oversight theme.

Accountability

Receipts and an audit trail give internal audit evidence they can verify offline.

Risk management

Measurable runtime output to feed a risk register.

Transparency

A disclosure block on responses and public protocol documents.

Traceability

A request hash ties each logged event to one request.

Mapping

What qodiqa provides, and what stays with you.

Requirement or control	What qodiqa provides	What stays with you
`Clause 8.1` Operational planning and control	Enforcement runs before each call, with a kill switch, revocation, token budgets and rate limits. This is a runtime control inside the operational controls the clause describes.	Planning, implementing and controlling the organisation’s operational processes for AI.
`A.6.2.6` Operation and monitoring	Fail-closed enforcement on every request, metrics, alert rules, health and readiness checks, and SIEM export.	Monitoring of model quality and of the wider system.
`A.6.2.8` Event log recording	Hash-chained audit entries, a transparency log and signed receipts record each enforced request, and an independent verifier can check them.	Deciding which life-cycle phases are logged, and logs outside the gateway.
`Clause 7.5.3` Controlling records	Tamper-evident records, configurable retention, legal holds and offline-checkable evidence packages for the records the gateway writes.	The organisation’s own documented-information procedures and all records outside the gateway.
`A.9.2` Responsible-use processes	Policy enforcement on input, output and tool results, content rules and human approval bound to one exact tool action.	The responsible-use policy, its objectives, training and the oversight roles.
`A.9.4` Use within intended purpose	Consent and tenant policy are checked before the call and a failed check returns a block with a reason; a decision is bound to the exact request.	Defining the intended purpose of each AI system.
`A.3.2` AI roles and duties	Role-based operator access, separation of duties for policy changes and an approver who is not the requester.	Assigning AI roles and duties across the organisation.
`A.2.4` AI policy review	Gateway policy changes go through draft, review, approval and publication, each step recorded with the policy version and hash.	The AI policy document itself and its review.
`A.8.2` User information	An AI-use disclosure block on every executed response, and published limitations and protocol documents.	Your user documentation and external reporting.
`A.8.4` Incident communication	Incident creation and tracking with evidence preserved for an investigation.	Communicating incidents to interested parties.
`A.7.2` Data management processes	Sensitive-data detection and redaction, tenant-scoped data access, retention and legal holds, erasure workflows, and hashes instead of text in audit records.	Data governance for your data resources, including training and acquisition.
`A.10.3` Supplier management	Provider routing is explicit, and the signed artifact names the provider the request is for.	Supplier assessment, contracts and the providers’ own controls.
`A.6.2.4` Verification and validation	Acceptance, negative-path, tenant-isolation and streaming tests, and CI release gates for the gateway.	Verification and validation of your AI system and its models.
`A.6.2.7` Technical documentation	Published limitations, protocol documents and doc-drift checks for the gateway.	Technical documentation of your AI system.
`Clause 9.1` Monitoring and measurement	Metrics, tamper-evident records and signed receipts give measurable runtime output that can be checked without trusting the operator.	Deciding what to measure, how often, and acting on the results.
`Clause 9.2.1` Internal audit, general	Receipts and proofs can be checked offline with keys obtained separately, so an internal auditor can test the records themselves.	The audit programme, the audit itself and management review.
`Clause 10.2` Nonconformity and corrective action	Incident records and reasons for blocked requests can be an input.	The corrective-action process and its follow-up.
`Clause 6.1.4` AI impact assessment	No assessment is provided. Recorded decisions, reasons and counts can be one input.	The AI risk assessment, risk treatment and impact assessment, and the AI management system itself (Clauses 4 to 10).

Identifiers verified against ISO/IEC 42001:2023 and ISO/IEC 27001:2022 on 2026-11-03. The standards are sold; their text is not reproduced here and the descriptors are the authors’ own. This is a mapping, not a certification.

Cross-check: the Regulatory Alignment Matrix, section 7

How it fits

What ISO/IEC 42001 asks, and what qodiqa produces.

AI event logs (Life-cycle controls) is supported by Hash-chained audit entries (Verifiable by a separate tool).
Operation and monitoring (Operation) is supported by Enforcement and metrics (Alerts and SIEM export).
Internal audit (Performance evaluation) is supported by Signed receipts and proofs (Offline verification).

Evidence

Evidence you can hand to an auditor.

Five artifacts, each checkable on its own

Consent artifact Signed with Ed25519, bound to one request, single use.
INTENT entry The audit entry written before the provider call.
Receipt A signed decision record that checks offline.
Audit export Hash-chained entries with a Merkle inclusion proof.
Anchor proof A signed checkpoint pinned outside the gateway.

Verify offline, from a clone of qodiqa-verify

node bin/verify.bundle.external.js \
  --keys examples/front-half/keys.json \
  --transparency-keys examples/front-half/transparency-keys.json \
  examples/front-half/bundle-with-proof.json

The example files ship with the repository and are signed with throwaway keys. The command exits 0 and prints "valid": true. For your own evidence, take keys and anchors from a source other than the gateway that wrote it.

Scope and limits

Technical evidence, not a compliance outcome

qodiqa provides technical evidence that relates to parts of ISO/IEC 42001. This is a mapping, not a certification: it is not a compliance certification, it is not legal advice, and no regulator or standards body has endorsed it.

What qodiqa does not address:

The management system itself: scope, policy, leadership, objectives and internal audit.
AI impact assessment and system life-cycle processes.
The organisation’s own management system, AI risk assessment, audits and certification are outside what a gateway can supply.
Only requests that pass through the gateway are checked, and a receipt proves a decision was recorded, not that it was correct.

Sources

The first link is the standard’s catalogue page on iso.org. The remaining links are qodiqa’s own documents. Checked on 2026-11-03; editions change, so read the current standard.

ISO/IEC 42001:2023, Artificial intelligence: Management system, ISO catalogue page accessed 2026-11-01
ISO, ISO/IEC 42001 explained accessed 2026-11-01
qodiqa specification: Regulatory Alignment Matrix (QODIQA-RAM-2026-001) accessed 2026-11-01
qodiqa-gateway: enforcement flow accessed 2026-11-01
Identifiers verified against ISO/IEC 42001:2023 on 2026-11-03; text not reproduced.

Next steps

See the evidence for yourself.

Read the spec section Run a simulation Quickstart