ISO 42001 Annex A to EU AI Act Articles 9 to 15: A Control Crosswalk
ISO/IEC 42001 Annex A gives direct support for the management-system parts of Articles 9 to 15, mainly risk management, and partial or indirect support for the system-level parts, such as automatic event logging, human oversight design and cybersecurity. Certification does not by itself establish EU AI Act conformity.
Using the crosswalk in practice
- Confirm that the system is classified as high-risk and record whether you are provider or deployer.
- For each article, list the Annex A controls you have implemented with records, separately from those that exist only as policy.
- Rate coverage as direct, partial or indirect using a stated method, and keep the rating rationale with the row.
- Mark each residual gap as organizational or runtime-dependent, and assign an owner.
- For Articles 12, 14 and 15, check what system-generated evidence exists today of what the system was permitted to do and what it did.
- Test the evidence by asking an independent reviewer to answer an audit question from the records alone.
What this crosswalk covers and what it does not
ISO/IEC 42001:2023 is a voluntary management system standard for artificial intelligence. It asks an organization to define policy, assign roles, assess risk and impact, and run controlled processes across the AI life cycle. EU AI Act Articles 9 to 15 are different in kind. They set requirements for high-risk AI systems, and the Act states that these requirements are necessary to mitigate risks to health, safety and fundamental rights. The crosswalk therefore applies only to systems classified as high-risk, and classification is determined by the Act's own rules.
The coverage ratings below are the author's assessment, made at the level of Annex A control themes rather than individual control numbers. Direct, partial and indirect describe how far a theme addresses the wording of the article. They are not an official mapping, and they do not replace a review of your own control set against the Article text and the licensed standard.
Two scope points matter before reading the tables. First, conformity under the Act runs through its own requirements and its own mechanism for harmonised standards and common specifications. When a reference to a harmonised standard is published in the Official Journal, the Act provides for the Commission to repeal the common specifications covering the same requirements. Certification to ISO/IEC 42001 is not a substitute for that route. Second, settle provider or deployer status for each system first. The same article can generate different evidence depending on who builds the system and who operates it, so record which party owns each artifact. As of November 2026, implementation guidance for ISO/IEC 42001 is still under development within ISO/IEC JTC 1/SC 42.
Crosswalk: Articles 9 to 11
Each row lists the Annex A control themes that support the article, the coverage strength, the residual gap and the evidence an auditor would typically expect. The evidence lists are practitioner expectations, not published certification-body requirements.
- Article 9: Risk management: Annex A themes: AI policy, AI risk and impact assessment, life cycle risk controls. Coverage: direct. Gap: the Act requires a risk management system that is established, implemented, documented and maintained for the specific high-risk system, so a generic organizational process is not enough. Evidence: risk management procedure, per-system risk register, treatment decisions, review and update records, one set of evidence per verb.
- Article 10: Data and data governance: Annex A themes: data management, data quality, data acquisition and preparation for AI systems. Coverage: partial. Gap: the Act's requirements on training, validation and testing data, including bias examination, call for dataset-specific practices beyond a general data management control. Evidence: data management procedures, quality criteria, preparation records, bias examination results.
- Article 11: Technical documentation: Annex A themes: AI system documentation, life cycle documentation, record of design and testing decisions. Coverage: partial. Gap: the Act expects structured technical documentation that is kept current, which is more prescriptive than management-system documentation. Evidence: technical file, design and test records, version history, change approvals.
Crosswalk: Articles 12 to 15
These four articles contain most of the requirements that cannot be met by policy alone. The gaps in the third and fourth rows are the ones most likely to need technical controls in the system itself.
- Article 12: Record-keeping: Annex A themes: event logging and recording within life cycle controls. Coverage: partial. Gap: automatic recording of events is a property of the system, not a policy. A management-system control can require logs, but it cannot produce them. Evidence: system-generated event records, retention settings, access controls on the records, periodic review records.
- Article 13: Transparency and information to deployers: Annex A themes: information for interested parties, system documentation for users, communication of limitations. Coverage: partial. Gap: the Act's content and clarity expectations for instructions for use are specific to the system. Evidence: instructions for use, user-facing disclosures, communication records, version-matched documentation.
- Article 14: Human oversight: Annex A themes: responsible use of AI systems, roles and responsibilities, competence and training. Coverage: partial. Gap: oversight has to be designed into how the system operates, including the ability to intervene. Roles and training do not show that intervention happened. Evidence: oversight role assignments, training records, approval, override and intervention records.
- Article 15: Accuracy, robustness and cybersecurity: Annex A themes: verification and validation, system monitoring, and security-related life cycle controls. Coverage: partial for accuracy and robustness, indirect for cybersecurity. Gap: Annex A does not set accuracy metrics or technical security measures. Cybersecurity depends on an adjacent security management system and technical controls. Evidence: declared metrics, test and resilience results, security assessments, access control and incident records.
Which gaps management-system controls can close
Sort every residual gap in the tables into one of two groups. Organizational gaps concern policy, process and documentation: the Article 9 risk process, Article 10 data practices, Article 11 documentation structure and Article 13 instructions. A management system is the right tool for these, and ISO/IEC 42001 gives a workable structure for assigning owners, setting review cycles and keeping records of decisions.
The second group is different. Article 12 asks for events to be recorded by the system. Article 14 asks for oversight that can act on the system's behavior. Parts of Article 15 concern resistance to misuse and unauthorized use. In each case an auditor or regulator asking what an AI system was permitted to do and what it did is asking for system-generated evidence. A policy document stating that logging and oversight are required is an assertion. It is not evidence that either took place.
This split also reduces duplicated effort. Teams that map every gap to documentation tend to produce more policy while the system-level questions stay open. Teams that sort gaps first can assign management-system work to the compliance function and technical work to engineering and security.
Where runtime enforcement produces audit-ready evidence
This section is deliberately narrow. It applies only to requirements where a decision made in the execution path can be recorded as evidence: Article 12 record-keeping, Article 14 human oversight and parts of Article 15 cybersecurity. This is a practitioner interpretation. It is not a finding that any tool satisfies these articles.
The unit of evidence is an individual interaction or tool call. When policy is enforced at runtime, each request can be allowed, redacted or blocked, or escalated for human approval, and the decision is recorded with the policy that produced it. For Article 12, that yields event records created by the system rather than assembled afterward. For Article 14, an escalation for approval creates a record of a human decision on a specific action. For Article 15, blocking a disallowed tool call or redacting sensitive content is a technical measure with a record behind it.
Trussed enforces policy in the execution path across models, agents, tools and MCP servers, and generates audit-ready evidence from enforcement that is mapped to the EU AI Act among other frameworks. The limits matter. This does not cover model or dataset provenance, transaction-level governance, or end-to-end tracing of agentic workflows. It does not address Article 10 data governance, Article 11 documentation or accuracy metrics. Neither ISO certification nor any tool is sufficient for conformity. Runtime evidence is one input to a conformity case that also needs the management-system controls above.
Coverage strength used in this crosswalk
Direct
An Annex A control theme addresses the requirement at the management-system level.
Partial
Annex A addresses part of the requirement. The Act asks for more specific or technical content.
Indirect
Coverage depends on adjacent controls, such as information security management, outside Annex A.
Runtime-dependent
Evidence must be produced by the AI system or its execution path, not by policy documents.
Review your Article 12, 14 and 15 evidence
If your Annex A controls are in place but system-generated evidence is thin, talk through how enforcement in the execution path produces records of individual interactions and tool calls.
Explore Agent and Tool-Call EnforcementHow does your AI governance program compare?
See where your program has gaps in less than 2 minutes.