ISO 42001 evidence for AI procurement in the EU

Procurement should obtain the complete certificate, including schedules and scope attachments. A logo in a presentation, an auditor’s training credential or a statement that the supplier follows ISO principles does not establish organisational certification.

ISO/IEC 42001:2023 concerns an AI management system. Its published structure covers organisational context, leadership, planning, support, operation, performance evaluation and improvement. These processes can produce useful risk assessments and operating records. They do not establish that every product version has passed the tests required for the customer’s intended use. (ISO/IEC 42001:2023, clause 1 and contents, clauses 4–10; ISO, ISO/IEC 42001 explained, sections 2, 3 and 5.)

Use this checking sequence:

1. Match the named certificate holder to the contracting supplier. Record any different developer, service operator or group company. A parent’s certificate covers a subsidiary only where the certified scope includes the relevant entity and activities.
2. Read the activities and sites covered. Check development, operation, support and outsourced work against the proposed service. Ask the supplier to identify which product versions and lifecycle activities fall within that boundary. Product identification within a management-system scope does not convert the certificate into a product approval.
3. Record the exact standard and edition, certificate number, issuer, issue date, expiry date and scope amendments. Distinguish ISO/IEC 42001:2023 from a European adoption or another standard.
4. Verify current certificate status through the issuer’s official service or an applicable certificate database. Match identifiers and scope. If no entry appears, obtain confirmation through independently verified issuer contact details; absence from a database alone does not establish fraud.
5. Check the named certification body in its accreditation body’s directory. Inspect the accreditation schedule for AI management-system certification, relevant locations and any suspension or withdrawal. Accreditation for another management standard does not establish accreditation for ISO/IEC 42001.
6. Retain the dated verification record and obtain relevant audit findings, corrective-action status and the supplier’s explanation of exclusions. Agree how procurement will receive later status changes.

The first two checks follow the standard’s organisational boundary. The remaining steps are proposed buyer controls informed by ISO’s certification guidance and certificate-verification services. Accreditation concerns the certification body’s competence; certification concerns the assessed management system. Neither determines the buyer’s statutory role. (ISO/IEC 42001:2023, clause 3.1, note 2; ISO, Certification; IAF CertSearch, How to verify a company certificate.)

ISO/IEC 42006:2025 supplements ISO/IEC 17021-1:2015 for bodies auditing and certifying AI management systems. Check the accreditor’s applicable scheme and transition rules; a reference to either certifier standard is not the supplier’s own ISO/IEC 42001 certificate.

Where scope excludes the activity being purchased, procurement should seek corrected evidence or evaluate that activity separately. It should record the uncovered activity rather than describe the entire service as certified.

The customer’s legal and product owners should agree a written description of the intended function, users, affected people, deployment country and product version. They should identify the decisions the system makes or influences. Those facts determine the evidence request.

A non-EU supplier placing its system on the Union market under its own name can be the provider. A business using that system under its authority is generally a deployer. Check separately whether a Union-established person places the foreign-branded system on the market and therefore meets the importer definition. Purchase from abroad alone is an insufficient role analysis. Where applicable, obtain the non-EU provider’s Union authorised-representative mandate. (AI Act, Articles 2(1), 3(3), (4), (6) and (20), 22 and 23.)

Screen prohibited practices first. A current certificate cannot permit conduct prohibited by Article 5. If the proposed function is prohibited, the responsible product owner must remove it or change the actual design and use sufficiently to fall outside the prohibition. Contractual assurances cannot cure the prohibited activity.

For high-risk classification, distinguish two routes. Article 6(1) requires the relevant Annex I product or safety-component connection and the specified third-party conformity-assessment condition. The amendments exclude specified non-safety functions and assessments concerned solely with non-health-and-safety risks. A function whose failure endangers health or safety remains a safety component. Annex I Section B has a separate, limited application regime. (Articles 2(2) and 6(1)–(1c).)

Article 6(2) covers Annex III uses, including specified recruitment, education and creditworthiness functions. The Article 6(3) exception requires the stated absence of significant risk and a qualifying listed function. A general claim that a human reviews outputs is insufficient. Annex III systems that profile natural persons remain high-risk. A provider relying on the exception must document its assessment and meet the relevant registration obligation when applicable. (Articles 6(3)–(4) and 49(2); Annex III.)

Revisit roles if the customer rebrands the system, substantially modifies it or changes a non-high-risk system’s intended purpose so that it becomes high-risk. Article 25 can make the customer a provider. The contract should require a role review before the relevant change takes effect. The EU AI Act readiness guide explains the wider classification exercise.

Attach dates to the applicable duties

On 29 October 2026, the amended Article 113(c) postpones Chapter III, Sections 1–3, except Article 6(5), until 2 December 2027 for Article 6(2)/Annex III systems and 2 August 2028 for Article 6(1)/Annex I systems. Those dates do not postpone every AI Act provision. Conformity, registration and incident provisions outside those sections require their own applicability analysis.

Original prohibitions and AI-literacy provisions already apply, as do applicable general-purpose AI model duties and Article 50 transparency duties. Preserve their exceptions and transitions. Providers of general-purpose AI models placed on the market before 2 August 2025 have until 2 August 2027 to comply with their applicable obligations. Providers of synthetic-content systems placed on the market before 2 August 2026 have until 2 December 2026 for Article 50(2)’s marking duty. That transition does not postpone every Article 50 obligation. The two prohibitions added by the 2026 amendment also apply from 2 December 2026. (Articles 4, 5, 50, 111(3)–(4) and 113(a)–(c).)

For an existing high-risk system, examine Article 111(2): first market placement or putting into service, the relevant application date and later significant design changes matter. Public-authority uses have an additional 2 August 2030 compliance backstop. A recently signed procurement contract does not establish the first-market date or remove a transition.

Procurement should require an evidence-delivery schedule tied to the actual deployment and legal dates. A demand for future evidence can be a contractual condition before the corresponding statutory duty applies.

Ask the supplier to connect each response to the identified system version, intended purpose and responsible legal entity. A general policy can explain a process; the buyer also needs the records produced when that process was applied.

Check the claimed conformity route

Where the high-risk regime applies, request the conformity-assessment route and its completion evidence, the signed EU declaration of conformity, relevant CE-marking information and required registration. A separate notified-body certificate is needed only where the applicable route requires one. (AI Act, Articles 43–49; Annexes V–VII.)

Annex III points 2–8 generally use internal control under Annex VI. That procedure includes checking the quality management system and technical documentation. Annex III point 1 has different conditions for involving a notified body. Systems also covered by Annex I Section A follow the applicable sectoral route under Article 43(3). Check any purported notified body against its notified scope, separately from its ISO certification accreditation. (Articles 30, 35 and 43; Annex VI.)

EN 18286:2026 was cited in the Official Journal on 14 October 2026 through Commission Implementing Decision (EU) 2026/2274. It concerns quality management for AI Act purposes and is distinct from ISO/IEC 42001:2023 and its European adoption. Ask which standard, clauses and legal requirements the supplier actually relies on.

Any presumption must remain within its legal coverage. Article 40(1), for high-risk systems, refers to covered Chapter III, Section 2 requirements; Article 17’s quality-management duty sits in Section 3. The amended Article 40(2) also addresses standardisation supporting Sections 2 and 3. Buyers should therefore require the supplier’s precise legal and technical mapping for an Article 17 conformity claim, together with implementation records. An ISO certificate does not settle that question or establish conformity with the whole Act. (Articles 17 and 40(1)–(2); Decision (EU) 2026/2274, recitals 3, 5–6, Article 1 and Annex.)

Send a version-specific evidence request

The following requests translate the applicable duties into procurement evidence. Access to complete confidential files should be negotiated where the buyer has no statutory entitlement to receive them.

• Intended purpose and instructions: request the system description, permitted uses, exclusions, operating conditions, dependencies and instructions for the purchased version. Confirm that the intended deployment fits those limits. (Articles 11 and 13; Annex IV, point 1.)
• Data and rights: obtain data-source and preparation descriptions, suitability and bias-testing evidence, identified gaps, and the legal basis for relevant processing. Establish controller and processor roles, restrictions on using customer data for training, and international transfer arrangements. ISO certification does not establish a GDPR lawful basis or dataset rights. (AI Act, Article 10; Regulation (EU) 2016/679, Articles 5, 6, 9, 28, 35 and Chapter V.)
• Technical and testing records: request an Annex IV index and sufficient supporting material to examine risk management, validation, accuracy, robustness and cybersecurity. Test results should identify the version, method, relevant population, limitations and responsible reviewer. A generic upstream model card does not establish downstream application conformity. (Articles 9, 11 and 15; Annex IV, points 2–5.)
• Human oversight: obtain the controls for interpreting outputs, detecting limitations, overriding decisions and stopping operation. The customer must appoint people with the competence, training, authority and support required for its deployment. Check Article 27’s fundamental-rights assessment trigger for Article 6(2) systems, excluding Annex III, point 2. It applies to deployers that are bodies governed by public law or private entities providing public services, and to deployers of the creditworthiness and insurance systems specified in Annex III, points 5(b) and 5(c). Complete applicable worker and affected-person notices. (Articles 14, 26 and 27.)
• Logs and incidents: require usable logging arrangements, relevant incident history, unresolved corrective actions, the monitoring plan and named escalation contacts. Allocate notifications under the applicable statutory triggers. Provider and deployer duties differ. Retention must distinguish the ten-year provider-document rule from the generally six-month minimum for controlled operating logs, with the stated legal exceptions. (Articles 18–20, 26(5)–(6), 72 and 73.)
• Changes and upstream dependencies: request the model and component register, release history, intended-purpose changes and reassessment procedure. Identify who can change the service and what evidence arrives before activation. A substantial modification can require a new conformity assessment; predetermined learning changes documented in the initial assessment have a specific exception. (Articles 3(23), 25 and 43(4); Annex IV, points 2(f) and 6.)

For integrated general-purpose AI models, check the supplier’s role and the applicable Chapter V duties separately. Article 53(1)(b)’s information right serves downstream system providers; it does not give every purchaser unrestricted access to a model provider’s files. The open-source exception has conditions, and systemic-risk models attract further duties. (Articles 53–55.)

The guide to AI Act risk assessments and governance documents explains the underlying document categories.

Check the supplier’s country and data route

EU conformity does not resolve the supplier’s export obligations. For supply from Great Britain, the exporter should classify relevant software and technology and check destination and end-use restrictions. An authorisation is required where the applicable export rules trigger it. A certificate or an EU customer contract does not supply that permission. Northern Ireland has a different dual-use regime. (Assimilated Council Regulation (EC) No 428/2009, Articles 3–4; Export Control Order 2008; ECJU, UK strategic export controls.)

For personal data sent from the EU to a UK supplier, the current UK adequacy decision provides a transfer route. It does not remove other GDPR duties or settle onward transfers to another country. Record hosting, support access, subprocessors and onward destinations before approving the data flow. (Regulation (EU) 2016/679, Articles 28 and 44–45; Commission Implementing Decision (EU) 2021/1772, as amended by Decision (EU) 2025/2574.)

Legal and procurement teams should turn the accepted evidence into identifiable contractual commitments. The following are proposed negotiating positions; they become contractual duties when agreed.

The certification warranty should identify the holder, standard edition, certificate number, issuer and covered activities. Require the supplier to confirm the disclosed status and scope at signing and the agreed deployment milestone. If certification is a purchasing condition, specify the required continuing scope and accreditation rather than requiring undefined ISO compliance.

Require notice without undue delay of suspension, withdrawal, expiry, scope reduction or an accreditation change affecting the certificate. Require advance notice of known non-renewal and planned scope changes. Set concrete renewal-evidence dates against the actual certificate and procurement timetable. A renewal application should not be treated as proof that certification continues.

Separately warrant the accuracy of supplied evidence and require compliance with laws applicable to the supplier’s identified activities when those laws apply. Schedule the required documents, recipients, update triggers and permitted confidentiality arrangements. Preserve legally required regulator access. Agree redaction, secure review or independent assessment where proportionate; confidentiality must not leave the buyer unable to discharge its own duties.

Article 25(4) requires a written agreement in the specified relationship between a high-risk provider and suppliers of integrated systems, models, tools, services, components or processes, subject to its open-source qualification. It is not a universal statutory requirement for every ordinary deployer purchase. Where that provision applies, the agreement must address the information, capabilities, technical access and assistance needed for compliance. Other evidence rights must have their own legal or contractual basis.

Incident clauses should preserve awareness times, evidence and immediate escalation routes. Do not use a single reporting period that could defeat a shorter statutory deadline. Change clauses should cover model substitutions, retraining, new data uses, hosting changes and functions that alter classification or oversight. Require an agreed assessment and approval process, with a controlled emergency-security route and subsequent review.

Specify remedies for evidence failure: withholding deployment approval, remediation, suspension of affected uses and termination where agreed. Allocate transition assistance, data return or deletion and access to records needed after exit. Liability limits and indemnities require review under the chosen governing law; an allocation of contractual responsibility does not displace statutory duties.

Remove claims that ISO has certified the supplier itself, that a management-system certificate proves the product is EU AI Act approved, or that it automatically covers every subsidiary and version. State the verified holder, scope and status. Identify product conformity evidence separately.

The customer’s legal owner should approve the classification and applicable dates. Its technical owner should confirm that the evidence concerns the configured product and intended use. The deployment owner should confirm oversight, notices, data controls and operating arrangements. Procurement should verify the agreed evidence and contract conditions.

Record one of these decisions:

• Proceed for the documented version and use when applicable legal requirements and agreed acceptance conditions are satisfied. Retain the evidence references, approval date, owners and change triggers.
• Approve contracting with deployment conditions where identifiable gaps can be closed. Assign each missing document or product change to an owner and deadline. Keep the affected use disabled until the conditions are met.
• Stop the proposed use where it is prohibited, a required permission is absent, or essential evidence cannot establish that the applicable duties can be met. Identify the function, permission or evidence that must change before reconsideration.

A verified certificate can satisfy a defined procurement requirement. The deployment decision still depends on the particular system and the customer’s actual use. Review that decision when the certificate changes, the product changes or the deployment exceeds its approved scope.