Who certifies an AI management system, and against what qualifications and criteria?
Across the earlier pages in this series, one thread runs through: ISO/IEC 38507 sets the direction a governing body should oversee, and ISO/IEC 42001 turns that direction into a management system. One question then remains: once an organization has built an AI management system (AIMS), who confirms its conformity, and with what qualifications and process? ISO/IEC 42006:2025 answers that question from the certification body's side. It sets out the requirements a body must meet to audit and certify an AIMS. This page looks at what 42006 asks of certification bodies and auditors, and what those requirements mean for an organization preparing for certification.
Introduction
This is the ninth and final page in the SC 42 AI standards series. The earlier pages covered ISO/IEC 22989 (AI concepts and terminology), ISO/IEC 23053 (a framework for ML-based AI systems), ISO/IEC 42001 (the AI management system), ISO/IEC 23894 (AI risk management), ISO/IEC 42005 (AI system impact assessment), ISO/IEC 5338 (AI system life cycle processes), and ISO/IEC 38507 (governance implications of the use of AI).
Where those eight pages looked at AI from inside the organization — its concepts, management, assessment, life cycle, and governance — ISO/IEC 42006 extends the view into third-party certification. It explains, once an organization has built an AIMS to ISO/IEC 42001, how a certification body may confirm that AIMS's conformity, and with what qualifications and procedures. As its full title says, 42006 sets requirements for bodies providing audit and certification of AI management systems.
Published in 2025 as a first edition, 42006 plays the same institutional role for AIMS certification that ISO/IEC 27006 plays for ISMS certification and ISO/IEC 17021-1 plays for management system certification in general: it underpins the credibility of the certificate. Its primary readers are certification bodies, accreditation bodies, and peer assessors, but it also matters to organizations preparing for certification, and to auditors and consultants. It is where the independence and competence expected of a certification body, how an audit is designed and how much time it needs, and what a certificate does and does not warrant, are all defined.
How to read this page
The table below flags the priority of each section from the perspective of an organization preparing for or maintaining ISO/IEC 42001 certification. Each core section opens with a one-sentence summary in italics, so the summaries and this table alone give you the overall shape.
| Section | What it covers | Certification prep | Relevant role |
|---|---|---|---|
| What is ISO/IEC 42006? | The standard's role and its relationship to 17021-1 | ● Essential | All |
| Core 1 — Consulting and certification cannot be combined | Impartiality and conflict-of-interest limits | ● Essential | Choosing the certification body |
| Core 2 — AI competence of auditors and audit teams | Technical competence, experience, transition period | ● Essential | Audit / internal audit |
| Core 3 — How audit time is determined | Auditor-day calculation under Annex A | ● Essential | Budget / certification lead |
| Core 4 — The certification process | Scope, SoA, stage 1 / stage 2, surveillance, recertification | ● Essential | Certification lead |
| Core 5 — What the certificate warrants | Certificate content, no product-certification implication, confidentiality | ○ Optional | Marketing / legal |
| The link to ISO/IEC 42001 | Completing the chain of trust in certification | ● Essential | Certification lead |
| What organizations should check | Certification-body selection and prep checkpoints | ● Essential | Certification prep team |
| Putting it into practice | Where to start, by situation | ● Essential | All |
● Essential — directly connected to preparing for and holding ISO/IEC 42001 certification. ○ Optional — useful depending on your role or interest.
What is ISO/IEC 42006:2025?
The core of ISO/IEC 42006:2025 is that it adds AIMS-specific requirements on top of ISO/IEC 17021-1. Where ISO/IEC 17021-1:2015 gives the general requirements for any management system certification body, 42006 reflects what is particular about AIMS as an object of certification and sets out the additional requirements a body must meet. That is why the text repeatedly points back to the relevant clauses of ISO/IEC 17021-1:2015 and, where needed, layers AIMS-specific requirements on top. It is the same construction ISO/IEC 27006 uses to add information-security specifics to ISO/IEC 17021-1.
The scope is clear. Implementing 42006's requirements helps a body that audits and certifies an AIMS demonstrate competence, consistency, and reliability. AIMS certification is a third-party conformity assessment activity in the sense of ISO/IEC 17000, and the body that performs it is a third-party conformity assessment body. The standard also states that accreditation bodies and peer assessors may use the document as a basis for assessing the competence of a certification body's personnel and the minimum requirements of its certification process.
Four normative references are cited: ISO/IEC 17000 (conformity assessment vocabulary), ISO/IEC 17021-1 (requirements for management system certification bodies), ISO/IEC 42001 (the AI management system), and ISO/IEC 22989 (AI concepts and terminology). In other words, understanding 42006 means understanding the concepts of 42001 and 22989 alongside it. If you have read the series from the start, how this standard connects to the earlier ones will already be visible.
Core 1 — A certification body cannot combine consulting and certification
The same body cannot provide AI, information-security, data-protection, or risk-management consulting to a client and also certify that client to ISO/IEC 42001. It is a conflict-of-interest limit that protects impartiality.
The first requirement 42006 stresses is the certification body's impartiality — its management of conflicts of interest. The standard states that a certification body must not provide consulting on AI, information security, data protection (for example, acting as an external data protection officer or running data-protection checks), or risk management to an ISO/IEC 42001 certification client. If a body were to certify a system it had itself helped build, the result would be a kind of "marking your own work," and the objectivity and credibility of the certification would be seriously undermined.
The standard also draws the line for activities near the boundary. Teaching general, publicly available information in an open training course, or the pre-audit work needed to understand the audit scope and a client's readiness, is not treated as consulting. On the other side, company-specific advice, activity that itself takes the form of an audit or is used as grounds to shorten certification audit time, and recommending specific solutions for the AIMS, an AI system, or AI-specific processes, all count as conflicts of interest. In particular, the standard states that a certification body cannot perform a client's internal audit on its behalf, and it cannot get around this by renaming the activity a "review" or "assessment." Pointing out an improvement opportunity that surfaces naturally during an audit — without recommending a specific solution — is not treated as consulting.
This clause has a direct meaning for organizations preparing for certification: the consulting firm that helped build your AIMS cannot also be your certification body for that engagement. On liability (5.3.2), 42006 adds a requirement that a certification body demonstrate insurance or an equivalent arrangement covering personal injury, property damage, and financial loss in proportion to the revenue of its audit and certification clients. The liability in question is not product liability, but liability for organization-level breaches of obligation arising from nonconformity with ISO/IEC 42001 and the resulting harm.
Core 2 — The AI competence required of auditors and audit teams
General management-system audit competence is not enough for an AIMS auditor. Understanding of AI concepts and terminology, the AI system life cycle, AI risk management, and AI system impact assessment is also required. The standards covered earlier in this series connect directly to these competence requirements.
The largest part of 42006 is the resource requirements (Clause 7), and personnel competence in particular. The standard splits the competences into general technical competence (7.1.2) and specific technical competence (7.1.3). For general technical competence, Table 1 sets out the additional knowledge and skills a body must define for each certification function under Annex A of 17021-1. The certification functions fall into three broad groups: performing the audit; reviewing the audit report and deciding on certification; and, through application review, determining the required audit team competence, composition, and audit time.
Under specific technical competence (7.1.3), 42006 spells out the knowledge an audit team must hold. As a baseline it needs an understanding of artificial intelligence itself, the technical aspects of the activity being audited, management systems and management practice, audit principles, and the monitoring, measurement, analysis, and evaluation of an AIMS. Beyond that, auditors need to understand AI concepts and terminology grounded in ISO/IEC 22989 and the AI system life cycle processes of ISO/IEC 5338. The team must also collectively hold knowledge of risk-management processes — notably ISO/IEC 23894 — and of impact assessment, risk assessment, data quality, and bias, drawing on standards including ISO/IEC 22989, ISO/IEC 42005, ISO/IEC 23894, ISO/IEC 5259-3, ISO/IEC TR 24027, ISO/IEC 27001, and ISO/IEC 27701. Read through the competence requirements and you can see exactly how the standards covered earlier in this series show up as required knowledge on an actual audit.
Two qualifications matter. First, no single person needs to hold all of this; the audit team meets it collectively — though some items, such as artificial intelligence and audit principles, must be held by every auditor individually. Second, the audit team must collectively be able to trace the signs of an incident that seriously and adversely affects people impacted by the client's AIMS back to the relevant elements of that AIMS. In other words, the team must be able to identify and confirm, during the audit, the real harm an AI system can cause to people.
The qualification bar for individual auditors (7.2.2) is high as well: professional education at a university-equivalent level; at least four years of practical experience in information technology or data protection plus at least one year of experience with AI systems; at least 24 hours of training covering AIMS auditing and audit management; and, within the last five years, at least ten audit-days or three management system audits. An audit team leader additionally needs to have participated across all stages of at least three management system audits.
The point of most practical interest is the transition period. For two years after publication, the team-leader requirement of participation in three ISO/IEC 42001 (AIMS) audits may be met instead by participation in three ISO/IEC 27001 (ISMS) audits. It is a time-limited measure that reflects a real situation — at the moment the AIMS certification market is opening, there are not yet enough auditors with 42001 audit experience — and it gives auditors with ISMS audit experience a realistic path into AIMS auditing. This is one reason a strategy of building ISO/IEC 42001 on top of an existing ISO/IEC 27001 base is a practical route for many organizations. Separately, 42006 does not allow outsourcing of audit activities: where 17021-1 permits outsourcing under certain conditions, that route is explicitly closed for the ISO/IEC 42001 certification scope.
Core 3 — How audit time is determined
AIMS audit time starts from the number of people involved in the AI life cycle, then is adjusted up or down by the organization's role and by complexity factors. Annex A provides the minimum basis.
The question organizations most want answered when preparing for certification is how long the audit will take. 42006 sets the minimum basis for calculating audit time in its normative Annex A. The starting point is the number of people involved in the AI life cycle: everyone involved in the AI life cycle under the organization's control — own staff and contracted staff, excluding external service providers — counted across all shifts. Audit time is measured in auditor-days, with eight hours counted as one day.
A distinctive feature is that the baseline time depends on the organization's role. Following the role distinctions of ISO/IEC 22989, an AI provider and an AI user sit lower than an AI producer taken as the reference, while an organization that combines several roles sits higher than the producer baseline. These figures are a starting point, not a number to use as-is: the standard requires the complexity adjustments in A.3.2 to be applied alongside. Those factors include the number of regulatory frameworks within the AIMS scope, the number of AI systems, the number of AI systems in high-risk or sensitive uses (for example, health, safety-critical, or uses affecting individuals' rights), the number of third-party contracts, and the number of controls documented in the statement of applicability (SoA). Every applicable factor must be reflected; the base figure alone cannot set the audit time. In particular, the greater the real impact an AI system has on the health and safety of individuals, groups, or society, the more audit time is required.
A few proportions are worth remembering. Even after planning and reporting time is set aside, on-site time must stay at or above 70% of the computed figure (this 70% draws on ISMS audit experience). Surveillance audits are typically about a third of the initial audit, and recertification at least two-thirds of it. Auditor travel time is not included in audit time, so it must be considered separately where relevant. An organization handling high-risk or sensitive-use AI should consider whether standard surveillance is sufficient and, where needed, may have to agree additional post-certification oversight.
Core 4 — The certification process: scope, SoA, staged audits
AIMS certification proceeds against the AIMS scope the organization defines, and the statement of applicability (SoA) is the key document showing which controls apply and which are excluded within that scope, and why. Certification is decided through a stage 1 and stage 2 audit, then maintained through surveillance and recertification. At each step 42006 adds AI-specific checks.
The process requirements (Clause 9) again build on the procedures of ISO/IEC 17021-1 and add what AIMS certification needs. At the pre-certification stage, the certification body has to ensure that the audit program covers all applicable management system requirements and that the client's stakeholder roles (producer, provider, customer, and so on, per ISO/IEC 22989) are identified. A single client may hold several roles.
The body must confirm that the AIMS scope the client has defined adequately covers the significant processes and risks associated with its AI systems. It also checks that the applied controls and the grounds for any exclusions are reflected in the SoA, and that at least one SoA exists for each certification scope. The audit criterion is ISO/IEC 42001. In the stage 1 audit the body reviews the geographic and regulatory particulars within the AIMS scope, and on that basis selects, on a risk basis, the evidence to be confirmed in the stage 2 audit.
The audit runs in two stages. In stage 1 the body reviews the AIMS design documentation and takes in the organization's context, its risk assessment and risk treatment, its AI policy, its information-security policy and objectives, and the client's audit readiness, in order to plan the stage 2 audit. The stage 1 result is recorded in a written report, and the body reviews whether to proceed to stage 2 and whether the stage 2 team is competent before moving on. The stage 2 audit evaluates whether the AIMS is effectively implemented and whether the client actually follows its own policies, objectives, and procedures. The certification decision and the maintenance of certification follow the requirements of ISO/IEC 17021-1, and 42006 requires that surveillance be tuned to the risks and impacts of the AI systems, with the rationale documented. The surveillance report must also include the results of actions on previous nonconformities, the SoA version, and any significant changes.
Remote auditing (9.2.4) is permitted, with conditions. The body analyzes risk factors — infrastructure, sector, audit type, competence — determines the level of remote auditing, and documents it. Where the risk assessment identifies an unacceptable risk to audit effectiveness, remote auditing cannot be used. On access to confidential and sensitive information (8.4.2), the body must inform the client that where information needing review — such as source code or raw data — cannot be provided, the audit cannot proceed until appropriate access is assured.
Core 5 — What the certificate does and does not warrant
An AIMS certificate must state the version of the SoA it rests on, and must make clear that the certificate does not authorize product, process, or service certification marks.
Under the information requirements (Clause 8), 42006 requires two additional pieces of information in the certification document (8.2.2). First, the version of the statement of applicability (SoA) on which certification rests. Second, a statement that the AIMS certificate does not authorize product, process, or service certification marks. This is a device for pinning down the meaning of the certification precisely. ISO/IEC 42001 certification means an organization's management system conforms to the standard — not that a particular AI product of that organization is safe or certified. The standard provides an example of the full set of certificate entries as a template in Annex C.
This distinction matters most at the marketing and communications stage. Saying "our company is certified to ISO/IEC 42001" is fine; recasting it as "our AI product is ISO-certified" can mislead readers into thinking the certification scope is a product certification. Where a product-level conformity mark is needed, 42006 points separately to the ISO/IEC 17065 scheme for product, process, and service certification, and explains that an AIMS certification document can be used within a 17065 scheme to avoid duplicate testing.
Where ISO/IEC 42006 sits in the regulatory landscape
Third-party assurance follows the same architecture almost everywhere: an accreditation body assesses and accredits a certification body, and the certification body issues a certificate. That architecture — accreditation body → conformity assessment body → certificate — is what 42006 and ISO/IEC 17021-1 formalize for AIMS. The EU AI Act relies on a comparable structure for high-risk AI systems, where member states designate conformity assessment bodies as notified bodies, often through their national accreditation bodies.
It is important, though, not to conflate the two. ISO/IEC 42001 certification, performed by a body conformant to 42006, attests that an organization's AI management system conforms to the standard. The EU AI Act's conformity assessment concerns whether a specific high-risk AI system meets the Act's requirements — a different object, at a different level. A 42001 certificate is not a substitute for AI Act conformity assessment, and 42006 itself keeps management-system certification separate from product-level certification (directing the latter to ISO/IEC 17065). As of 2026 the Act's own conformity infrastructure — designated bodies and the harmonized standards that would give a presumption of conformity — is still being built out, with the Commission's Digital Omnibus proposal (November 2025) tying the high-risk application dates to the availability of those support measures. In that setting, an accredited, robustly audited AIMS certificate is best read as evidence of governance maturity that supports readiness, not as regulatory conformity in itself. In the United States, the NIST AI Risk Management Framework remains voluntary with no certification regime; NIST maps it to ISO/IEC 42001, so AIMS certification complements RMF adoption rather than competing with it.
The link to ISO/IEC 42001
42006 is the standard that institutionally underpins ISO/IEC 42001:2023 certification. If 42001 is the set of management system requirements an organization must build, 42006 is the set of requirements a certification body must meet so a third party can judge that system's conformity credibly. The two standards address the requirements of two different actors — the organization being certified, and the body performing the certification. ISO/IEC 42001 is the criterion applied to the organization; ISO/IEC 42006 and ISO/IEC 17021-1 are the criteria applied to the body that certifies it.
Here the relationship to the earlier standards surfaces again. The auditor competence list includes 22989, 5338, 23894, and 42005; what the audit confirms includes 42001's risk assessment (6.1.2), impact assessment (6.1.4), and Annex A controls. In other words, 42006 shows how the earlier standards actually connect and are confirmed on an audit. The credibility of a certificate ultimately rests on who audited, with what competence, over how much time, and against what evidence.
One balance is worth noting. Where to place an AI governance or certification-readiness role in the organizational structure — a dedicated function, or a role connected to or integrated with existing governance, risk, quality, legal, or data teams — is a matter for the organization to decide by need. 42006 is a certification-body requirement; it does not dictate an organization's internal structure. What it protects is the objectivity of certification and the securing of the audit competence required.
What organizations should check when preparing for certification
42006 is written for certification bodies, but read from the preparing organization's side it becomes a useful checklist. (The points below are cases you may meet in practice, not categorical rules.)
- The certification body's independence — you cannot select the consulting firm that helped build your AIMS as the certification body for the same engagement. Plan consulting and certification as separate.
- Accreditation and auditor competence — check that the body holds appropriate accreditation and that the audit team holds AI-specific competence (22989, 5338, 23894, 42005, and so on). During the transition period, an auditor who meets part of the AIMS team-leader requirement on the basis of ISMS audit experience may be assigned.
- The basis for audit time and cost — check that the quoted audit-day figure rests on the number of people involved in the AI life cycle and on the complexity factors (regulatory frameworks, number of AI systems, high-risk uses, third-party contracts, number of SoA controls). An audit time that is too short can itself be a credibility concern.
- Completeness of the SoA — the statement of applicability shows which controls apply and which are excluded within the AIMS scope, and why. Confirm and close any gaps in advance so that significant AI-related processes, risks, and controls are not left out.
- A plan for access to confidential and sensitive information — agree in advance with the body how information needing review, such as source code or raw data, will be accessed and protected.
- Accuracy of how the certificate is described — the certificate means conformity of the management system and does not authorize a product-certification mark. Keep promotional wording within that boundary.
An internal audit cannot be performed on the organization's behalf by the certification body, so the organization must run it itself.
Putting it into practice — where to start
- If you are preparing for certification — at the body-selection stage, check independence, accreditation, and auditor competence, and ask for the basis of the audit-time calculation. Note that the documents actually needed will vary with your scope and the nature of your AI systems.
- If you already hold ISO/IEC 27001 — the fact that, during the transition period, ISMS audit experience can substitute for part of the AIMS team-leader requirement has a signal for organizations too: adding ISO/IEC 42001 on top of an ISO/IEC 27001 base can be a realistic approach.
- If you are an auditor or consultant — use 42006's competence list (7.1.3) as a self-check against your grasp of the series standards: 22989, 5338, 23894, 42005, and the rest.
To see the whole landscape again, the SC 42 AI Standards Map lays out how the nine standards fit together.
Key terms at a glance
| Term | Meaning |
|---|---|
| Certification body (CB) | The third party that audits and certifies the conformity of an AIMS |
| Accreditation body | The higher-level body that assesses and accredits the competence of a certification body |
| Impartiality / conflict of interest | The objectivity of certification / a situation where that objectivity is compromised, e.g. by combining consulting and certification |
| Statement of applicability (SoA) | The document recording which controls apply within the AIMS scope and the grounds for any exclusions |
| Auditor-day | The unit of audit time; eight hours counted as one day |
| Initial / surveillance / recertification audit | Surveillance is about a third of the initial audit; recertification at least two-thirds |
| Persons involved in the AI life cycle | The starting point for calculating audit time; own and contracted staff included, external providers excluded |
In closing — where the nine standards connect
ISO/IEC 42006:2025 gathers the discussion of AI governance and management systems across this series into the perspective of third-party certification. 22989 sets out AI concepts and terminology, and 23053 gives a base framework for describing AI systems. 42001 provides the criteria for managing all of this as an organizational management system; 23894 covers risk management, 42005 impact assessment, 5338 life-cycle operation, and 38507 governance oversight. One question then remains: who confirms, and against what criteria, that the system actually works?
By setting the qualifications and procedures of the certification body that performs that confirmation, 42006 underpins the chain of trust behind ISO/IEC 42001 certification.
The larger arc across this series is that AI governance is not staying at the level of vague principles; it is becoming a verifiable system. From what to do (concepts and frameworks), through how to manage, assess, and operate it (management system, risk, impact, life cycle), to who is accountable and oversees it (governance) and who judges it objectively (certification), the nine standards reference one another and connect into a single system. Taken one at a time, any one of them reads as abstract; taken together, they reveal a working framework for operating AI an organization can trust.
The standards will keep evolving. SC 42 continues to develop further standards on data quality, bias, and transparency, and alignment with regulation such as the EU AI Act will grow clearer. Even so, the nine standards this series has covered will remain a core foundation of AI governance. We hope these pages have been a small guide to understanding the source standards and applying them in practice and in audit.
📚 SC 42 AI Standards Series (complete)
← Previous: ISO/IEC 38507:2022 — Governance Implications of the Use of AI
📍 Current: ISO/IEC 42006:2025 — Requirements for AIMS Certification Bodies (final in the series)