ISO 42001 vs EU AI Act vs DORA: A Control Crosswalk for Banks and Insurers

Most banks and insurers I work with are running three AI governance conversations at once. Risk wants ISO/IEC 42001 because it is certifiable and auditors understand management systems. Legal is tracking the EU AI Act because credit scoring and insurance pricing are high-risk. And the CIO's team already lives inside DORA, which has applied since 17 January 2025.

Run separately, those become three control libraries, three evidence trails and three audit cycles for the same AI systems. This guide maps them onto each other so you can design each control once.

The Three Frameworks in One Paragraph Each

ISO/IEC 42001:2023 is a voluntary, certifiable standard for an AI management system (AIMS). It follows the same clause structure as ISO 27001 — context, leadership, planning, support, operation, performance evaluation, improvement — and adds an Annex A of 38 AI-specific controls across 9 objectives, from AI policy to third-party relationships.

The EU AI Act (Regulation 2024/1689) is law. Prohibited practices have been banned since February 2025. Obligations for Annex III high-risk systems apply from 2 December 2027, after the EU's 2026 Digital Omnibus postponed the original August 2026 date; AI embedded in regulated products (Annex I) follows in August 2028. For financial services, the relevant Annex III entries are creditworthiness assessment and credit scoring of individuals, and risk assessment and pricing for life and health insurance.

DORA (Regulation 2022/2554) governs ICT risk for EU financial entities. It does not mention AI specifically — it does not need to. An AI system is an ICT system, so DORA's ICT risk management framework, incident reporting, resilience testing and third-party risk rules already apply to every model you run in production.

The One Thing to Get Right: ISO 42001 Is Not AI Act Compliance

ISO/IEC 42001 is not a harmonised standard under the AI Act, so certification does not give you a presumption of conformity. What it gives you is the governance machinery the Act assumes exists: a risk management process, impact assessments, lifecycle controls, internal audit and continual improvement.

Treat ISO 42001 as the backbone, then add the AI Act's system-level requirements — technical documentation, logging, transparency, human oversight, accuracy and robustness — and DORA's operational resilience requirements on top. That is the order in which the crosswalk below is built.

The Crosswalk

Each row is one control area you design once, evidence once and audit once. Article references are to the AI Act and DORA; clause references to ISO/IEC 42001.

Control area	ISO/IEC 42001	EU AI Act	DORA
Governance & accountability	Clause 5 (leadership, AI policy); A.2, A.3	Art. 17 quality management system (providers); Art. 26 deployer obligations	Art. 5 management body responsibility for ICT risk
Risk management	6.1.2 AI risk assessment; 6.1.3 risk treatment	Art. 9 risk management system	Art. 6 ICT risk management framework
Impact assessment	6.1.4 AI system impact assessment; A.5	Art. 27 fundamental rights impact assessment (deployers of credit scoring and insurance pricing)	No direct equivalent — pair with GDPR Art. 35 DPIA
Data governance	A.7 data for AI systems	Art. 10 data and data governance	Art. 9 protection and prevention (data integrity and confidentiality)
Lifecycle & documentation	Clause 8 operation; A.6 AI system life cycle	Art. 11 technical documentation; Art. 12 record-keeping (logging)	Art. 6 documented ICT risk framework
Transparency	A.8 information for interested parties	Art. 13 transparency to deployers; Art. 50 transparency obligations	—
Human oversight & use	A.9 use of AI systems	Art. 14 human oversight; Art. 26 deployer use and monitoring	—
Accuracy, robustness & security	A.6 verification and validation	Art. 15 accuracy, robustness and cybersecurity	Arts. 8–11 identification, protection, detection, response; Arts. 24–26 resilience testing
Monitoring & incidents	Clause 9.1 monitoring; A.6 operation and monitoring	Art. 72 post-market monitoring; Art. 73 serious incident reporting	Arts. 17–19 ICT incident management and major incident reporting
Third parties & suppliers	A.10 third-party and customer relationships	Art. 25 responsibilities along the AI value chain	Arts. 28–30 third-party risk, register of information, contract terms
Internal audit & improvement	Clause 9.2 internal audit; Clause 10 improvement	Art. 17 quality management system	Art. 6 regular internal audit of the ICT risk framework

Where ISO 42001 Leaves Gaps for Financial Institutions

If you already have ISO 42001 (or are working towards it), these are the areas where I consistently find extra work for AI Act and DORA:

• System-level technical documentation. ISO 42001 asks for lifecycle documentation; the AI Act's Art. 11 and Annex IV specify its content per high-risk system. Plan for a documentation template per system, generated from your MLOps pipeline rather than written by hand.
• Automatic logging. Art. 12 requires high-risk systems to log events automatically over their lifetime. That is an engineering requirement on your serving platform, not a policy.
• Fundamental rights impact assessment. Deployers of credit scoring and life/health insurance pricing systems must run one under Art. 27. ISO 42001's impact assessment is a good starting template, but the Art. 27 content is specific.
• Incident reporting clocks. AI Act serious-incident reporting and DORA major-incident reporting have different triggers and deadlines. Build one incident intake with two classification paths, so one event does not start two uncoordinated processes.
• Register of information. DORA requires every ICT third-party arrangement in a register. LLM providers, model APIs and AI SaaS belong there, with the contract terms Art. 30 requires. ISO 42001's A.10 does not go that far.
• Resilience testing. DORA testing — and threat-led penetration testing for significant entities — should cover AI systems that support critical or important functions. ISO 42001 does not require it.

How to Build One Control Set Instead of Three

1. Start from an AI inventory. Every model, vendor AI feature and LLM integration, with its owner, purpose and data. Classify each against AI Act risk tiers and flag which support DORA critical or important functions.
2. Adopt the ISO 42001 structure as the backbone. Policy, roles, risk process, internal audit. If your organisation already runs ISO 27001, extend that management system instead of creating a new one.
3. Write controls against the crosswalk rows, not against frameworks. One control per row, with references to all three frameworks in its metadata. Auditors for each framework then test the same control.
4. Automate evidence in the platform. Lifecycle gates in CI/CD, model registry approvals, automatic logging and drift monitoring produce evidence continuously. Spreadsheets do not survive the first audit cycle.
5. Sequence by risk and deadline. High-risk Annex III systems first — they need to be ready by 2 December 2027. Twelve to eighteen months is a realistic build time for the full stack, so the start date is now.

Should You Certify to ISO 42001?

Certification is worth it when customers, partners or your group require it, or when you want an external audit rhythm to keep the management system alive. It is not worth it as a substitute for AI Act readiness. My usual advice for a bank or insurer: build to the ISO 42001 structure now, close the AI Act and DORA gaps in the same programme, and decide on certification once the controls are running and producing evidence.

If you want to know where your AI systems stand against this crosswalk, the AI readiness assessment covers governance, infrastructure and compliance in one fixed-fee engagement, and our AI governance consulting builds the controls. For a quick self-check first, use the EU AI Act compliance checklist.