ISO 42001 for public sector AI

Public bodies and their suppliers use ISO 42001 to organize the evidence the EU AI Act asks for, but the standard does not replace the Act's own duties. This guide explains what each side owns and how to plan the work.

Book a callTalk to us
On this page

Does ISO 42001 satisfy public sector AI obligations?

A public body or supplier facing a high-risk AI deadline needs one fact settled first: ISO/IEC 42001:2023 does not by itself satisfy Article 27 or Article 26 of the EU AI Act. It is a management system standard. It asks an organization to establish, run and improve an AI management system, and its Annex A controls give that system structure. The EU AI Act imposes specific legal duties on deployers and providers, and those duties have to be met in their own right. An ISO 42001 management system can produce much of the evidence a regulator or assessor will ask for, but it does not replace the fundamental rights impact assessment, the registration step or the explanation duties. Only an independent certification body can issue an ISO 42001 certificate, and a certificate is not a legal conformity finding under the AI Act.

The right answer depends on the body's role. A public authority that only uses a high-risk system is a deployer, and its duties sit mainly in Article 26 and Article 27. A body that builds or substantially modifies a system and places it on the market or puts it into service is a provider, with a different set of obligations. Many public bodies are both, for example when they customize a supplier's model for their own casework. Before scoping any ISO 42001 work, the organization should map each AI system to its role and to the Annex III use it serves. Annex III points 5(b) and (c) (credit scoring and life and health insurance pricing) matter for public bodies that touch those uses, so confirm the exact Annex III point for every system in the inventory against the consolidated text of the AI Act.

For each system, ask the implementation partner and the certification body to show which Annex A controls the statement of applicability covers and which legal duties remain separate work. Deadlines in the AI Act have been amended, so check the current application dates against the consolidated AI Act text and the AI Act Service Desk before setting a plan. Keep in mind that the European Commission has said ISO/IEC 42001 does not match the AI Act's quality management system, which is a separate matter from the management system this standard describes. Scope and legal review should be confirmed in writing with counsel, and the outside help you buy should be clear about which parts it prepares and which parts the organization and its independent assessor own.

How public bodies and suppliers divide the work

A public body that puts a high-risk AI system into use is a deployer under the EU AI Act. The body decides how the system is used, on which people, under which oversight, and it must carry out the fundamental rights impact assessment before first use and register the use where the Act requires it. ISO/IEC 42001 gives the body a management system to run these duties consistently, and the body owns the outcome of every decision it makes with the system.

  • What the body owns: the AI policy, the decision to deploy, the impact assessment and its conclusions, human oversight arrangements, and the explanations given to affected people.
  • What a partner can prepare: the impact assessment templates, the register of use entries, deployment and monitoring records, and operating procedures for the system.
  • What the body must keep current: logs of operation and the provider's instructions for use, which feed the impact assessment and data protection assessments.
  • What only an auditor can issue: a certificate under ISO/IEC 42001, based on a certification body's audit of the management system.
  • Who reports to the regulator: the body notifies the market surveillance authority of the impact assessment results where Article 27 requires it.

Before signing a contract, confirm with legal counsel which systems fall under Annex III and which registration duties apply to your authority.

How the fundamental rights impact assessment connects to ISO 42001 impact controls

Article 27 of the EU AI Act asks public bodies and certain deployers to assess fundamental rights impacts before first use, and ISO/IEC 42001 Annex A.5 asks for a documented AI impact assessment process. The cards below show how the steps of one can feed the other, and where to confirm the overlap with your auditor before relying on it.

Identify affected groups

Start by listing the people and groups the system touches: applicants, claimants, employees, and the staff who rely on its output. ISO/IEC 42001 Annex A.5 asks for impacts on individuals or groups to be assessed separately from impacts on society, so record the two views as distinct entries. Check that the group list matches the population the deployer actually serves, not only the population the provider described.

Map rights at risk

For each affected group, record which fundamental rights could be affected, such as non-discrimination, privacy, good administration or access to public services. This is the step where the Article 27 assessment is most specific to the deployer's own context. Use the impact assessment record under Annex A.5 to hold the reasoning, and ask your legal team to confirm the rights list before it is treated as final.

Assess likelihood and severity

Score each identified impact by how likely it is and how serious it would be for the person affected. Annex A.5 expects a documented method, so the scoring rules should be written down and applied the same way across systems. Record who reviewed the scores and when, because an assessor will test whether the method was followed rather than whether the result looks reasonable.

Define mitigation and human oversight

Each significant impact needs a documented response: a design change, a human review step, a restriction on use, or a decision not to deploy. These measures tie to the Annex A.9 use controls and the A.6 life cycle controls that govern how the system is operated. Confirm with your assessor which mitigations are evidenced by logs, training records or configuration baselines, since each needs its own proof.

Keep the notification record

Article 27 requires the deployer to notify the market surveillance authority of the results of the assessment. Keep a dated record of what was notified, to whom, and what was sent, alongside the internal impact assessment it summarizes. This record also supports the external reporting obligations in Annex A.8, so check that the two sets of records use the same version of the assessment.

Confirm the mapping with your assessor

ISO/IEC 42005:2025 gives guidance on AI system impact assessment and is the natural reference for building the A.5 process, but this page does not supply a line-by-line mapping from its clauses to Article 27 steps. Ask your certification body or legal adviser to confirm which steps of your fundamental rights assessment satisfy which Annex A.5 expectations, and record that confirmation in the statement of applicability.

Right to explanation and reporting to interested parties

A public body that deploys a high-risk AI system in Annex III must be able to explain decisions to the people they affect. Under Article 86(1) of the EU AI Act, a person subject to a decision based on the output of such a system, where the decision has legal effects or similarly significant adverse effects on their health, safety or fundamental rights, is entitled to clear and meaningful explanations of the AI system's role in the decision and the main elements of the decision. ISO/IEC 42001 does not contain this right, and the standard is not a substitute for it. What it contributes is an auditable trail: a documented way to find out what the system did, who can ask about it and how the answer reaches the person. The organization should first confirm with its legal counsel which decisions fall within Article 86(1) and which of its own processes must produce explanations.

Annex A control A.8.3 asks the organization to provide capabilities for interested parties to report adverse impacts of the AI system. For a public body, this means a documented channel that citizens, staff and representative groups can use to raise a concern, with a named owner who triages it, records the outcome and feeds it into the impact assessment and the risk register. Control A.8.5 asks the organization to determine and document its obligations to report information about the AI system to interested parties, which is where the public body lists what it owes to affected persons, oversight bodies and market surveillance authorities. Related A.8 controls cover documentation for users and incident communication. Evidence an assessor would expect includes the reporting procedure, a sample of logged reports with their dispositions, the obligations register and the template explanation used for affected persons. Ask the organization to confirm the retention period for these records against its own legal requirements.

How a public body prepares before first use

This sequence moves a public body from an unconfirmed view of its AI system to a documented go or no-go decision before first use. Each phase produces a record that the next phase relies on, and the final decision stays with the organization.

  1. Confirm the Annex III classification

    The organization's legal or compliance lead, with the system provider's technical file, checks whether the system falls under an Annex III high-risk category and which point applies. The team also confirms whether the use is in critical infrastructure, since that exclusion changes the Article 27 scope. The output is a signed classification memo that names the Annex III point, the reasoning, and the owner. Confirm the current consolidated text of the AI Act with counsel before relying on it, because the text was amended in 2026.

  2. Establish the fundamental rights impact assessment scope

    Before first use, the deployer determines whether it is a body governed by public law, a private entity providing public services, or a deployer of the credit scoring or life and health insurance pricing uses in Annex III points 5(b) and 5(c). If it is, it scopes the Article 27 assessment to the people and groups the system could affect. The output is a scope statement that lists affected groups, the rights at stake, and the decision points the system informs. Ask the market surveillance authority or legal advisers which documentation format they expect.

  3. Complete the impact assessment and its documentation

    Operational owners, data protection staff and affected-group representatives assess the system's likely impact on fundamental rights, the safeguards in place, and the steps taken if harm occurs. This phase draws on the impact assessment process in ISO/IEC 42001 controls A.5.2 to A.5.4 and the related ISO/IEC 42005 guidance. Where a GDPR data protection impact assessment already exists, the fundamental rights assessment complements it rather than replacing it. The output is a dated assessment record with named approvers and a list of residual risks.

  4. Notify the authority and register the high-risk use

    The deployer notifies the market surveillance authority of the assessment results as Article 27 requires, and a public authority deployer registers the use under Article 49 before using a system that is listed in the EU database. The registration fields follow the information set out in Annex VIII of the AI Act. The output is a notification record and a registration confirmation that are kept with the classification memo. Confirm the notification format and any procedural steps with the relevant national authority.

  5. Collect supplier evidence and provider information

    The deployer requests from the provider the instructions for use, technical documentation, logging capability, and the information needed for GDPR data protection impact assessments under Article 26(9). It also checks the provider's own conformity or governance evidence, including any ISO/IEC 42001 certificate and its scope. Procurement and the business owner review the evidence against the use case. The output is a supplier evidence file with gaps logged and a named owner for each open gap.

  6. Run the management system gap review

    A governance team maps the existing AI policy, roles, risk process, life cycle controls, and information for interested parties to the Annex A controls and clauses 4 to 10 of ISO/IEC 42001. The team records which controls apply, which are excluded with justification in the statement of applicability, and which need work. The output is a gap register with owners and a plan that the organization approves. Any external readiness review should be confirmed in writing as a preparation exercise, not as an audit.

  7. Record the go or no-go decision

    An accountable senior official reviews the classification memo, impact assessment, registration, supplier evidence and gap register together, then decides whether the system may go into first use, with conditions or without. The decision record names the approver, the conditions, and the trigger for a fresh review, such as a material change to the model or its use. The output is a signed decision record that auditors and the authority can trace back to each earlier phase.

Supplier controls that public buyers should write into contracts

Public bodies rarely build AI alone, so much of their ISO 42001 evidence sits with suppliers. The Annex A controls in the third-party and customer group ask the organization to split life cycle responsibilities, manage AI suppliers and meet customer expectations. Each card below is a clause a buyer can turn into a contract term or a due diligence question.

Allocate life cycle responsibilities in writing

Control A.10.2 asks the organization to allocate responsibilities for the AI system across its life cycle among itself, its partners, suppliers, customers and third parties. For a public body, the contract should name who designs, trains, deploys, monitors and retires each system, and who answers to citizens. Check that every life cycle stage in your AI register has a named owner on both sides. Gaps in this split are where accountability disappears.

Review supplier AI products and services

Control A.10.3 covers how the organization manages suppliers of AI products and services, including how it selects them and checks their conformity with its own requirements. Public buyers should ask for the supplier's own AI management system scope, its impact assessments and any certificate it holds from an independent body. Confirm that the supplier can show these records before award, not after deployment.

Require provider documentation for deployers

A deployer of a high-risk system relies on the provider's instructions to meet its own duties. Under Article 26 of the EU AI Act, the deployer must use the system according to the provider's instructions for use, and the provider should supply the information that the deployer needs. Ask for instructions for use, known limitations, intended purpose and the logging capabilities before signing. Treat missing instructions as a blocking issue.

Secure access to AI system logs

Deployers of high-risk systems must keep logs generated by the system to the extent they are under their control, and must retain them for an appropriate period. Where the supplier hosts the system, the contract must set out which logs the buyer receives, in what format and how fast. Agree log retention, export rights and access for audits, so the public body can answer a complaint or an inquiry from its own records.

Set supplier duties to report adverse impacts

Control A.8.3 requires the organization to provide ways for interested parties to report adverse impacts, and A.8.5 requires it to document its reporting obligations. A supplier that learns of a failure, bias or security incident affecting a public deployment must pass that information on within a set time. Write notification duties, contact points and cooperation on investigations into the contract, and test them with a tabletop exercise before go-live.

Write customer expectations into the contract

Control A.10.4 asks the organization to take account of customer expectations about AI systems, which for a public body means citizens, service users and oversight bodies. Turn those expectations into service levels for accuracy monitoring, human review, complaint handling and change notices. Ask suppliers to confirm how they will tell the buyer about model updates that change behavior, since an unannounced change can affect the explanations the public body must give.

Questions public bodies ask before procurement

Does the EU AI Act require ISO 42001 certification for public bodies?

No. The AI Act does not require ISO/IEC 42001 certification. The European Commission describes the standard as a way to set up an AI management system, and it says the standard does not match the quality management system the Act expects. That role is covered by a separate standard, EN 18286, which the Commission cited in the Official Journal in October 2026. Obligations that bind a public body, such as the fundamental rights impact assessment under Article 27 and registration under Article 49, apply whether or not you hold a certificate. Certification is a voluntary choice that can help show structured governance to procurement teams. Confirm the current position with your national authority and legal counsel.

How much internal staff time does an ISO 42001 programme need?

The effort depends on how many AI systems are in scope, how many are high-risk under the AI Act, and how much governance documentation already exists. The standard does not set a time commitment, so ask for effort by role in any written scope. Most public bodies involve an accountable senior owner, system owners for each AI use case, data protection and legal staff, procurement, security, and the teams that train staff. The heaviest work usually falls at the start: inventorying systems, policies, and impact assessments. Recurring work includes monitoring, internal audit, management review, and supplier reviews. Ask any partner to separate one-time and recurring hours in the quote so you can plan staffing beyond the first year.

Can our own team implement ISO 42001 without outside help?

Yes. The organization owns its controls, and many public bodies build the management system with their own staff. Outside help is most useful for specific work: a gap analysis against the Annex A controls, configuring open-source tooling that keeps AI governance records, building evidence pipelines, and preparing documentation for an audit. Keep the roles separate. An implementation partner prepares systems and evidence, and only an independent certification body issues a certificate, so the firm that helped you build the system should not also certify it. DeployOpen works on fixed scope agreed in writing and does not issue audit reports or certificates. Decide early which parts your team will own, because that decision shapes the scope you ask for.

How long does ISO 42001 take for a public sector body?

The timeline depends on scope and systems, and no fixed duration applies. The main drivers are the number of AI systems in scope, whether any are high-risk under the AI Act, how clean your data sources and supplier records are, whether you already run an ISO 27001 management system that can be extended, and how quickly internal approval chains move. Certification body scheduling also adds lead time. For AI systems that will be used in the EU, the fundamental rights impact assessment must be complete before first use, so deployment dates may set the deadline. Ask for a milestone plan that ties each system to its go-live date, and confirm how the plan changes if a system is delayed.

Who signs the fundamental rights impact assessment for a public authority?

The organization decides who signs, and no consultant or auditor can sign on its behalf. Article 27 places the duty on the deployer, and the deployer must notify the market surveillance authority of the results. In practice, public bodies usually assign an accountable senior owner, with input from the data protection officer because the assessment complements any GDPR data protection impact assessment, plus legal counsel and the business owner of the system. Consider how affected groups are consulted and record that process. ISO/IEC 42005 gives method guidance for AI impact assessment, and it can structure the work. Confirm the sign-off model and notification route with your national authority before the first use.

How do we ask AI suppliers for evidence of their controls?

Request the provider's information package and map each item to your own controls before signing. For high-risk systems, Article 26 sets obligations on deployers that depend on what the provider supplies, including the instructions and information needed to use the system within its intended purpose. Ask for:

  • Intended purpose, limitations, and instructions for use
  • Logging and monitoring capabilities you can access
  • A named contact and process for reporting adverse impacts and incidents
  • Data processing terms for any GDPR data protection impact assessment
  • Their ISO/IEC 42001 certificate, if claimed, verified with the issuing certification body and its accreditation status

Record each answer against the supplier controls in Annex A (A.10) and the reporting obligations (A.8.5), so the evidence is ready for your own audit.

How to choose an auditor or implementation partner

An auditor issues the certificate and an implementation partner prepares systems and evidence, so the two roles must stay separate. The cards below cover what to verify about the certification body, how to confirm the partner is independent of it, and what to settle in writing before work starts.

Check certification body accreditation

ISO does not certify organizations, and external certification bodies do. Accreditation of those bodies is voluntary, so a certificate from an unaccredited body may carry less weight with your customers and regulators. Ask the body which accreditation body accredits it, request the scope of that accreditation, and confirm that the scope names ISO/IEC 42001 explicitly before you commit budget.

Confirm ISO/IEC 42006 competence requirements

ISO/IEC 42006:2025 sets requirements on top of ISO/IEC 17021-1 for bodies that certify AI management systems. Ask whether the auditors assigned to your engagement have documented AI-specific competence, and whether the body's processes follow the 42006 requirements. Public bodies should also ask how the auditor will test the Annex A controls on impact assessment and information for interested parties.

Require independence from the certifier

A partner that prepares your AI management system should not also be the body that audits it. Ask the partner to state in writing that it has no ownership, shared management or consulting-to-certification arrangement with the certification body. Ask the certifier to confirm it has not designed the controls it will assess. Independence protects the certificate's credibility when a contracting authority or regulator reviews it.

Ask for public sector delivery experience

Public bodies face procurement rules, records obligations and fundamental rights reviews that private firms may not have handled. Ask the partner to describe, in general terms, the public sector work it has done and the types of evidence it produced. Ask for anonymized examples and for references that the partner can offer with permission. Treat any refusal to describe experience as a reason to look elsewhere.

Define what stays with your organization

The organization owns its AI policy, its risk acceptance decisions, its statement of applicability and its registration and reporting duties under the EU AI Act. Ask the partner to list in the agreement which deliverables it prepares and which decisions your staff must make. Name an internal owner for AI governance so that accountability does not transfer to the consultant at the end of the engagement.

Settle the fixed-scope written agreement

Most implementation work is fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Before signing, confirm the systems in scope, the Annex A controls covered by the statement of applicability, the evidence the partner will hand over, and who pays the certification body directly. Ask what is excluded, how changes to scope are priced, and what support runs after the audit.

What must stay with the public body

The public body owns its AI controls, its management decisions and its statement of applicability. Under clause 6.1.3 of ISO/IEC 42001, the organization must decide which Annex A controls are necessary, and justify including or excluding each one. That justification reflects the body's own risk picture, its legal duties and its public accountability, so it cannot be delegated to an implementation partner. Before any work starts, the body should name an accountable owner for AI governance, approve the statement of applicability itself, and confirm who signs off on the fundamental rights impact assessment under Article 27 of the EU AI Act.

DeployOpen prepares systems, configuration, documentation and evidence for the body's assessments. It does not issue audit reports, attestations or certificates. Those come only from an independent certification body or auditor, and ISO itself does not certify organizations. Readers should also keep the legal boundary clear: holding ISO/IEC 42001 certification is not a guarantee of compliance with the EU AI Act, and it does not discharge the body's duties as a deployer under Article 26 or its obligations under Article 86 to explain individual decisions. Ask any certification body to confirm in writing what its certificate does and does not cover.

A separate point often causes confusion. The European Commission has said that ISO/IEC 42001 does not match the Act's quality management system, for which CEN and CENELEC approved EN 18286 in June 2026. The Commission cited EN 18286:2026 in the Official Journal on 14 October 2026 under Implementing Decision (EU) 2026/2274. These documents concern the Act's quality management system for providers, not ISO 42001 itself. Public bodies that procure high-risk systems should confirm with their legal team which of these instruments their suppliers must meet, and should not treat an ISO 42001 certificate as evidence against EN 18286.

What usually delays public sector AI projects

This sequence walks public bodies and their suppliers through the checkpoints where public sector AI projects most often stall, so that roles, registration, provider documentation and impact assessment ownership are settled before the system goes live.

  1. Confirm the deployer and provider roles

    Before any build or purchase decision, the public body establishes whether it is the provider, the deployer, or both for each AI system, using the definitions in the EU AI Act. Legal and procurement leads usually own this, with the AI governance owner checking the answer. Many delays start here because a body that buys a system from a vendor and then changes its purpose or adds its own data can take on provider duties without planning for them. The step is done when a written role determination exists for every system in scope and has been reviewed by counsel.

  2. Check whether the use falls under high-risk rules

    The organization compares each use case against the Annex III categories of the EU AI Act to decide whether it is a high-risk system and whether the Article 27 fundamental rights impact assessment applies. The check should record the intended purpose in plain terms, since purpose determines classification. Legal review and the business owner of the use case share this work. The output is a classification memo that names the applicable articles and states the reasoning, so that the project timeline reflects the obligations that follow.

  3. Request provider documentation before contract signature

    A public body deploying a high-risk system needs information from the provider to meet its own duties, including the instructions for use, the information needed for registration and the information needed for a GDPR data protection impact assessment. Procurement teams should write these items into the tender or contract as deliverables, not as optional attachments. A common delay is discovering late that the vendor cannot supply them. The step is complete when a documentation request is signed off by the vendor and the contract names the documents, their versions and their delivery dates.

  4. Assign ownership of the impact assessment

    The organization names one accountable owner for the fundamental rights impact assessment and, where it applies, a separate owner for the GDPR data protection impact assessment, along with the people who contribute evidence. Ownership should sit with the body that deploys the system, because the duty falls on the deployer, even when a partner drafts the material. Unclear ownership is one of the most common reasons assessments are started late or approved without review. The step is done when the owners, reviewers and approval route are recorded in the AI governance register.

  5. Complete the fundamental rights impact assessment

    The owner runs the assessment before first use, covering the processes the system supports, the people likely to be affected, the risks to fundamental rights and the measures to mitigate them, including human oversight and ways for affected people to raise concerns. Independent reviewers and the data protection officer should challenge the draft. The output is an approved assessment document with a decision on whether to proceed. The assessment must be finished before the system is used, so the timeline should treat it as a gating item rather than a parallel task.

  6. Notify the authority and register the high-risk use

    Once the assessment is approved, the deployer notifies the market surveillance authority of the results as Article 27 requires, and a public authority deployer registers the use in the EU database under Article 49 before using the system. The compliance lead should confirm the registration fields against the information listed in Annex VIII of the EU AI Act before submission. Delays happen when the registration is treated as an administrative afterthought. The step is done when registration evidence and the authority notification are filed with the assessment record.

  7. Set up the channels for affected people and reporting

    Before go-live, the organization makes sure people affected by a decision based on the system can receive a clear explanation of the AI's role and the main elements of the decision, and that they can report adverse impacts. The service owner, legal team and the team that handles complaints should test the process with a realistic walkthrough. The step produces written procedures, staff briefing notes and a tested route for reports, mapped to the information obligations in the ISO/IEC 42001 controls A.8.3 and A.8.5.

How DeployOpen prepares public sector AI evidence

DeployOpen works on ISO 42001 for public sector AI as an implementation partner. We prepare the systems, controls and records that an ISO 42001 management system needs, inside your own infrastructure, while your organization keeps ownership of its AI governance decisions and an independent certification body makes any certification decision.

How we scope

  • Engagements are fixed-scope, with the systems, AI use cases and Annex A controls agreed in writing before work starts.
  • The written scope names which AI systems and public service processes fall under the management system and which are excluded.
  • We review the draft statement of applicability with your team so each included and excluded control has a recorded justification.
  • Scope also records which fundamental rights impact assessments and deployer registrations apply to each use case.

How we build

  • We set up the AI inventory, use case register and documented information in the systems you already run.
  • Impact assessment templates are built to cover fundamental rights, affected groups and the human oversight arrangements for each use.
  • Logging, event records and technical documentation are configured on self-hosted open-source platforms in your own environment.
  • Supplier and third-party controls are documented, including the information your providers must supply to you.

How we hand over

  • Deliverables include the policies, procedures, records and evidence files mapped to the agreed Annex A controls.
  • Your staff receive documented runbooks so they can operate the evidence process after the engagement ends.
  • Testing results from security assessments of AI systems are documented alongside the governance evidence.
  • Handover states clearly which records remain your responsibility and which items an independent auditor will need to review.

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
  • Retainers can cover updates to impact assessments when a public body changes an AI system or its purpose.
  • Support can include preparing evidence packs for internal audit, management review and external assessment requests.
  • Ask any implementation partner to confirm in writing what they will not do, including issuing audit reports or certificates.

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com