Which ISO AI standards do buyers need alongside ISO 42001?
When a customer questionnaire, contract or regulator points you to ISO/IEC 42001, the first thing to establish is that ISO/IEC 42001 is the only certifiable management system standard in this family. The others are supporting guidance or rules for the bodies that certify, so they inform how you do the work but do not produce a certificate on their own. ISO/IEC 22989 sets the AI terminology your documents should use, ISO/IEC 23894 gives AI risk management guidance, and ISO/IEC 42005 covers AI system impact assessment. ISO/IEC 42006 applies to certification bodies, not to your organization directly.
Which of the others matter depends on your role in the AI supply chain. An organization that builds AI systems will look hardest at the life cycle and data standards, such as ISO/IEC 5338 for AI system life cycle processes, ISO/IEC 8183 for the AI data life cycle, and the ISO/IEC 5259 series on data quality. An organization that only buys and uses AI will focus on third-party relationships, use controls and impact assessment. Organizations that run AI systems in production should also check the status of ISO/IEC FDIS 24970 on AI system logging, which is still at the FDIS ballot stage, so treat it as a design reference rather than a settled requirement.
Start by reading the customer's wording closely. Ask whether they want certification, a documented alignment or answers to a questionnaire, because each expects different evidence. Then ask your assessor, or a certification body you are considering, which of these standards it will use as reference during the audit. Confirm the current status of each document on the ISO website before you cite it in a contract, since amendments and new editions can change what a customer expects.
How each standard in the family fits around ISO 42001
ISO/IEC 42001:2023 is the only standard in this family that an organization certifies against. It sets requirements for establishing, implementing, maintaining and continually improving an AI management system, and it applies to any organization that provides or uses products or services that use AI systems. ISO/IEC 42006:2025 sits beside it. It was published on 7 July 2025 as edition 1 (31 pages) and sets requirements for bodies that audit and certify AI management systems, on top of ISO/IEC 17021-1. ISO does not certify organizations itself. External certification bodies do, and accreditation of those bodies is voluntary.
- ISO/IEC 42001:2023: edition 1, published 18 December 2023 by ISO/IEC JTC 1/SC 42 (51 pages). Certifiable: yes, through clauses 4 to 10.
- Annex A controls: 38 reference controls. The organization decides which apply through a statement of applicability under clause 6.1.3.
- ISO/IEC 42006:2025: defines what auditors and certification bodies must do, so it matters when you judge whether a certificate is credible. An organization does not certify against it.
- Accreditation path: Global ACI's recognition arrangement does not list ISO/IEC 42001 as an endorsed sub-scope in version 3.3 (August 2026), so confirm the accreditation route directly with the certification body.
- Revision status: ISO lists no amendment or revision in progress as of October 2026.
Before relying on a certificate in a contract, check the certification body's accreditation scope and confirm that its audit approach reflects ISO/IEC 42006:2025.
ISO/IEC 22989:2022 establishes AI concepts and terminology for developing other standards and for communicating among stakeholders. It was published on 19 July 2022 as edition 1 (60 pages), and ISO reports that two amendments are under development. ISO's FAQ also places ISO/IEC 23053 in this group as a framework for describing AI systems that use machine learning. Neither standard is certifiable. Their value is that they give policies, contracts and audit records a shared vocabulary.
- ISO/IEC 22989:2022: defines AI terms and concepts. Not certifiable.
- Amendments in progress: ISO reports two amendments under development. Check their status before quoting a definition in a contract.
- ISO/IEC 23053: a framework for describing machine learning based AI systems. Confirm its edition and publication date on the ISO site before citing it.
- Policy and scope wording: definitions drive the AI policy, the scope of the management system and the list of AI systems in your inventory.
- Supplier and customer questionnaires: shared terms prevent a vendor and a buyer from answering the same question about an AI system in different ways.
Check that your AI inventory, policy and contracts use the same definitions, and that each cited term matches the current edition of the standard.
ISO/IEC 23894:2023, published on 6 February 2023, gives guidance on AI risk management. ISO/IEC 42001 treats risk and impact assessment as separate activities, and ISO/IEC 42005:2025 covers impact. It was published on 28 May 2025 as edition 1 (39 pages) and guides assessing how AI systems and their foreseeable applications may affect individuals, groups and society. Neither standard is a certification standard. They inform the risk and impact clauses of ISO/IEC 42001 and the Annex A.5 controls on impact assessment.
- ISO/IEC 23894:2023: AI risk management guidance that supports risk identification, assessment and treatment under the 42001 risk clauses. Not certifiable.
- ISO/IEC 42005:2025: AI system impact assessment guidance covering individuals, groups and society, which supports the Annex A.5 controls.
- Separate assessments: ISO/IEC 42001 keeps impacts on individuals or groups separate from impacts on society, so your method and records should show both.
- Crosswalks: NIST publishes an ISO/IEC 42005 to NIST AI RMF crosswalk and an NIST AI RMF to ISO/IEC FDIS 42001 crosswalk. Use them as starting points and verify each mapping against your own method.
- Regulatory overlap: the EU AI Act Article 27 fundamental rights impact assessment is a separate legal requirement for certain deployers. Ask counsel whether an ISO-based assessment covers it.
Check that each risk and impact assessment names its owner, its method and the standard it followed, because auditors test those records directly.
These standards and drafts supply the method behind the Annex A.6 life cycle controls, the Annex A.7 data controls and the event logging expected in operation. ISO/IEC 5338:2023 defines AI system life cycle processes that organizations can use to define, control, manage, execute and improve AI systems. ISO/IEC 8183:2023 is ISO's AI data life cycle framework and applies to any organization that uses data to develop or operate AI systems. ISO/IEC 5259-1:2024, published in July 2024, gives the overview and terminology for data quality in analytics and machine learning. Parts 2 to 5 cover models, measures and guidelines. ISO/IEC FDIS 24970 covers AI system logging and has been at the FDIS ballot stage since 28 August 2026. These are guidance documents rather than certification standards.
- ISO/IEC 5338:2023: life cycle processes that map to the Annex A.6 controls on design, verification, deployment and operation.
- ISO/IEC 8183:2023: data life cycle framework that supports the Annex A.7 controls on acquisition, provenance and preparation.
- ISO/IEC 5259-1:2024: data quality overview and terminology, with parts 2 to 5 for detailed models, measures and guidelines.
- ISO/IEC FDIS 24970: AI system logging at the FDIS stage, so it is not yet a published standard. Confirm its status with ISO before writing it into a control.
- Shared evidence: logs, data lineage and life cycle records are the artifacts auditors request for A.6 and A.7.
Confirm which of these you cite as published and which as drafts, and check that your logging design matches your retention and access requirements.
Which standards can be certified and which only guide
The ISO AI family mixes certifiable requirements with reference guidance. Only ISO/IEC 42001 is the standard an accredited body assesses an organization against, while the rest shape how the management system is built and how the certification body is held to account.
ISO/IEC 42001 is the certification target
ISO/IEC 42001:2023 is the standard an external certification body assesses your AI management system against. Its requirements sit in clauses 4 to 10, and its Annex A controls are evaluated through your statement of applicability. Confirm with the certification body that it will audit against edition 1 and state which Annex A controls it expects to see justified.
ISO does not certify
ISO publishes standards but does not issue certificates to organizations. Accredited certification bodies perform audits and issue certificates, and accreditation of those bodies is voluntary. Ask any prospective body whether its accreditation covers ISO/IEC 42001 specifically, and request the accreditation scope in writing before signing.
ISO/IEC 42006 governs the certifiers
ISO/IEC 42006:2025, published 7 July 2025, sets requirements for bodies that audit and certify AI management systems. It adds to the general requirements of ISO/IEC 17021-1 for certification bodies. Ask the certification body how it meets these additional requirements, including competence for AI topics in its audit teams.
ISO/IEC 23894 as a reference
ISO/IEC 23894:2023 gives guidance on AI risk management. Auditors do not certify against it, but many organizations use it to design their risk assessment and treatment process inside ISO/IEC 42001. Ask the certification body which risk references it will accept as evidence of method, and confirm the edition.
Guidance standards used as references
ISO/IEC 22989 (terminology), ISO/IEC 42005 (impact assessment), ISO/IEC 5338 (life cycle), ISO/IEC 8183 (data life cycle) and ISO/IEC 5259 (data quality) inform how you write procedures and evidence. None is a certification scope. Agree with the certification body which of these it will treat as informative references and which it will not examine.
Confirm the edition and references
Before audit planning, ask the certification body to confirm in writing the edition of ISO/IEC 42001 it audits against, the version of any guidance it cites, and whether it will examine ISO/IEC FDIS 24970 logging requirements, which remain at the draft stage. Record the answers in your audit plan so scope disputes are settled before stage 1.
Why ISO/IEC 42006 changes how you choose an auditor
When you choose a body to certify your ISO/IEC 42001 management system, the first question is not price or timing but whether that body is qualified to audit AI management systems at all. ISO/IEC 42006:2025, published on 7 July 2025, sets requirements for bodies that audit and certify AI management systems, and it adds those requirements on top of ISO/IEC 17021-1, the general rules that apply to certification bodies for management systems. A firm that is competent for ISO 27001 audits has not, by that fact alone, shown the AI-specific competence that 42006 expects. Ask each candidate how its auditors are qualified for AI systems and how it has adapted its audit process to the 42006 requirements.
Accreditation is voluntary. ISO does not certify organizations, and certification bodies may operate without accreditation, so a certificate from an unaccredited body may carry less weight with your customers and regulators. Accreditation also has to be checked at the scope level. The Global ACI status for version 3.3 (August 2026) does not list ISO/IEC 42001 as an endorsed sub-scope of the recognition arrangement, although it does list ISO/IEC 27001 with ISO/IEC 27006-1. Do not assume that an accreditation for management system certification covers AI management systems. Ask each body in writing for its accreditation scope for ISO/IEC 42001, the accreditation body that granted it, and the date of the current accreditation, then confirm those details on the accreditation body's public register before you sign.
Build this check into your shortlist before you request quotes, because it changes which bodies you can consider and how long the engagement takes. If a body cannot show AI-scope accreditation, decide whether you accept an unaccredited certificate for your customers or contracts, and record that decision in your management review. Also confirm that the body will not perform the readiness work for you, since preparing your evidence and auditing it must stay with separate parties.
Risk management and impact assessment are separate activities
ISO/IEC 42001 treats AI risk management and AI system impact assessment as separate activities, each with its own guidance standard. The cards below separate what each one covers, where they connect, and what to confirm before relying on crosswalk mappings.
AI risk management guidance
ISO/IEC 23894:2023, published 6 February 2023, gives guidance on managing risk from AI systems. It helps teams set up the risk assessment and risk treatment work that the management system depends on. Organizations use it to decide how risks are identified, scored and treated, and who signs off on residual risk. It is guidance, not a certifiable requirement, so an auditor tests whether your own risk process runs and produces records.
AI system impact assessment
ISO/IEC 42005:2025 gives guidance for assessing how an AI system and its foreseeable applications may affect individuals, groups and society. It asks teams to look beyond technical failure to harms such as discrimination, unfair outcomes or effects on rights. Its output is a documented assessment tied to a specific system and context of use, which ISO/IEC 42001 requires as its own activity under Annex A.5.
Why the two activities stay separate
Risk management asks what could go wrong for the organization and how to control it. Impact assessment asks how the system could affect people and society, including people who are not customers or users. A single risk register rarely captures both. Check that your AI risk records and impact assessment records each have their own owner, method and review cycle, and that they cross-reference the same AI system inventory.
Where the two activities connect
Impact assessment findings often become risk inputs, and risk treatment decisions can change the design that the impact assessment described. For example, an illustrative credit scoring model might trigger a fairness impact finding that then adds a risk treatment such as a human review step. Record that link explicitly so an auditor can trace one decision through both activities.
Crosswalks map both to the NIST AI RMF
NIST publishes crosswalks that map ISO/IEC 42005 to the NIST AI Risk Management Framework, and map ISO/IEC FDIS 42001 to the same framework. These are useful starting points for teams that report against both. Treat each mapping as a reference that needs checking, not as proof of equivalence, and confirm the exact clause and subcategory pairs against the NIST documents before you cite them to a customer or assessor.
Confirm the mapping before relying on it
Crosswalks reflect the document version and interpretation at the time they were written, and a mapping can be partial even when two items look similar. Ask your certification body and your NIST AI RMF reviewer how they will read each mapping. Keep a short note recording which version of each document you used and who checked the pairing.
Life cycle, data and logging standards that produce evidence
The standards in this group do not certify anything, but they give you vocabulary and structure for the evidence that ISO/IEC 42001 auditors ask for under Annex A.6 (AI system life cycle), A.7 (data for AI systems) and the event log control in A.6. ISO/IEC 5338:2023 defines AI system life cycle processes that an organization can use to define, control, manage, execute and improve its AI systems. Used as a reference model, it helps you decide which life cycle stages need recorded decisions, such as requirements, design, verification and validation, deployment and operation, and which owner signs off each one. Your ISO/IEC 42001 documentation then points to those records instead of inventing stage names during an audit.
ISO/IEC 8183:2023 is ISO's AI data life cycle framework and applies to any organization that uses data to develop or operate AI systems. It maps naturally onto the data controls in A.7, covering data management processes, acquisition, provenance and preparation. For each dataset, confirm that you can show where it came from, the lawful basis or contractual right to use it, how it was transformed, and who approved its use. The ISO/IEC 5259 series on data quality for analytics and machine learning, with part 1 published in July 2024 as the overview and terminology part, supports the A.7 data quality control. Parts 2 to 5 cover models, measures and guidelines, so check which parts your quality metrics depend on before you cite them.
Questions buyers ask about the ISO AI standards family
Which ISO AI standard can an organization actually get certified against?
Only ISO/IEC 42001 is a certifiable management system standard. ISO does not certify organizations; external certification bodies do, and their accreditation is voluntary. The other standards in the family, such as ISO/IEC 22989 for terminology, ISO/IEC 23894 for risk management guidance and ISO/IEC 42005 for impact assessment, provide guidance that you can use inside the management system but are not certification schemes in their own right. Certification bodies audit against ISO/IEC 42001 and, for their own accreditation, follow the additional requirements of ISO/IEC 42006:2025. Ask any certification body to confirm in writing which standard its certificate will name and whether its accreditation covers AI management systems.
Do we have to implement every related AI standard to pass an ISO 42001 audit?
No. ISO/IEC 42001 does not require you to adopt every related standard. Clause 6.1.3 requires a statement of applicability that lists the necessary Annex A controls and justifies including or excluding each one. The organization decides which references it adopts, and it records that decision in the statement of applicability. An auditor will test whether the chosen approach is justified, consistent with your risks and actually operated, so an unexplained exclusion is a finding risk. Treat ISO/IEC 23894 and ISO/IEC 42005 as candidate methods for the risk and impact processes your controls require, and document which ones you use and why.
How do auditors use ISO/IEC 22989 terminology during an audit?
ISO/IEC 22989:2022 establishes AI concepts and terminology so that policies, risk registers, system descriptions and contracts use the same words. Auditors do not usually certify you against it, but they read your documentation for consistent meaning. If your AI policy says "model" in one place and "system" in another without definition, or your supplier agreements use different terms for training data and inference data, the inconsistency becomes an observation. Adopt a glossary that cites ISO/IEC 22989, map your internal terms to it, and use the glossary across the AI policy, impact assessments and supplier records so that evidence reads consistently.
Is ISO/IEC 42005 impact assessment required for ISO/IEC 42001 certification?
ISO/IEC 42001 requires you to assess AI system impacts through its Annex A impact assessment controls, but it does not name ISO/IEC 42005 as mandatory. ISO/IEC 42005:2025 gives guidance on assessing how AI systems and their foreseeable applications may affect individuals, groups and society. Many organizations use it as the method behind their impact assessment controls, and a crosswalk from ISO/IEC 42005 to the NIST AI RMF is available from NIST. Whichever method you choose, your statement of applicability must show how the impact assessment controls are met, and your records must show that assessments were performed for the systems in scope.
How long does this work take, and what does it need from our team?
No researched fact in this page gives a duration, so confirm timelines with the certification body and your implementation partner in writing. The effort depends on how many AI systems are in scope, how much governance already exists, how mature your risk and data processes are, and how many suppliers provide AI components. Your team must supply named owners for AI policy, risk and impact decisions, system inventories, data documentation, supplier contracts and technical evidence such as logs and test records. Ask any partner to list those owners, the review meetings they require and the artifacts they will prepare, so the timeline reflects work your staff can realistically provide.
Can an implementation partner handle these standards for us?
A partner can prepare systems, documentation and evidence against the standards you choose, including mapping the statement of applicability, drafting procedures, configuring logging and documenting risk and impact processes. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and it prepares controls and evidence for assessments. It does not issue audit reports or certificates, and it does not make the decisions that belong to your organization. Those decisions, including which standards you adopt, who owns AI governance and what risks you accept, stay with you. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
Which standards in the family are still in development and should we wait for them?
You do not need to wait. ISO/IEC 22989 has two amendments under development, and ISO/IEC FDIS 24970 on AI system logging has been at the FDIS ballot stage since 28 August 2026. Published standards such as ISO/IEC 5338, ISO/IEC 8183 and the ISO/IEC 5259 series are usable now as guidance. Before you design logging or data controls around a draft, check the current status on the ISO page for that standard and record the version you relied on in your documentation. Plan to review your controls when a relevant standard changes, and record that review in your management review records.
Which AI standards should we start with if our budget and team are limited?
Start with the requirements of ISO/IEC 42001 itself, because that is what a certification body audits. Build the scope, AI policy, roles, AI system inventory and statement of applicability first, then fill in the risk, impact and data processes. Use ISO/IEC 22989 for shared terminology from day one, since it costs nothing to adopt and prevents confusion later. Add ISO/IEC 23894 and ISO/IEC 42005 where your risk and impact processes need a documented method, and bring in ISO/IEC 5338 or ISO/IEC 8183 only for the systems whose life cycle or data processes need structure. Confirm the sequence with your certification body before committing budget.
How to check a certification body or consultant before signing
ISO/IEC 42001 certificates come only from external certification bodies, and implementation help comes from consultants or partners who prepare the evidence. Each check below separates those roles so you can confirm who issues the certificate, who prepares the work, and whether the two are kept apart before you sign anything.
Confirm accreditation scope
ISO does not certify organizations, and accreditation of certification bodies is voluntary, so ask whether the body holds accreditation for ISO/IEC 42001 specifically and not only for a general management system scheme. Request the accreditation certificate and its scope document, then check both with the accreditation body that issued them. Confirm the scope names the standard edition you will be audited against, ISO/IEC 42001:2023.
Confirm assessment against ISO/IEC 42006
ISO/IEC 42006:2025, published 7 July 2025, sets requirements on top of ISO/IEC 17021-1 for bodies that audit and certify AI management systems. Ask the body to show how its audit process, auditor competence and certification decisions meet those additional requirements. A body that only cites general management system audit rules has not addressed the AI-specific requirements in that standard.
Ask how independence is protected
Ask the certification body whether it, or any related company, has provided implementation, gap analysis or design services to the same client in the past two years. Ask the consultant the same question about the certifier it recommends. Get the answer in writing with the name of the person who signs off independence. A conflict is not automatically disqualifying, but it must be disclosed and managed before the audit is booked.
Check referenced standard editions
Ask which editions of ISO/IEC 42001, ISO/IEC 23894, ISO/IEC 42005 and ISO/IEC 22989 the auditor will reference, and whether any of them have been replaced or amended since your plan was written. ISO/IEC 22989 has two amendments under development, and ISO/IEC FDIS 24970 on AI system logging is still at ballot stage, so confirm which of these the auditor treats as normative for your scope and which are only guidance.
Confirm consultants do not certify
A consultant or implementation partner may prepare policies, impact assessments, technical records and evidence, but must not issue audit reports or certificates. Ask for a written statement that the firm does not issue attestations or certifications, and confirm that the statement of applicability, internal audit and management review remain owned by your organization. Any document that claims certification from a consultant is a warning sign.
How the EU AI Act harmonized standards differ from ISO/IEC 42001
ISO/IEC 42001 is not the harmonized standard for the EU AI Act's quality management system, and the European Commission says so directly. The Commission's position is that ISO/IEC 42001 helps an organization set up an AI management system, but it does not match the quality management system the AI Act requires. The standard that CEN and CENELEC approved for that purpose is EN 18286, approved in June 2026. The Commission cited EN 18286:2026 in the Official Journal on 14 October 2026 under Implementing Decision (EU) 2026/2274. Before you scope any AI governance project, ask your regulator, notified body or customer which of these standards they name, because a certificate to one does not establish conformity with the other.
The practical difference lies in what each document is used to show. ISO/IEC 42001 is a management system standard that can be certified by an accredited certification body, so an organization can use it to demonstrate a governed AI program to customers. The EU AI Act quality management system is a regulatory obligation for specific providers of high-risk AI systems, and EN 18286 is the harmonized standard that supports presumption of conformity with that obligation. Your team should confirm with counsel whether any of your AI systems fall in the high-risk category, which determines whether EN 18286 is relevant at all. Where it is, expect the ISO/IEC 42001 management system to serve as a foundation rather than as a substitute for the EU-specific documentation.
Two checks help you plan. First, read the cited EN 18286:2026 text through the EUR-Lex link to the implementing decision and confirm which parts of the Official Journal citation apply to your product. Second, map your existing ISO/IEC 42001 policies, risk records and technical documentation against the quality management system the regulator describes, and record the gaps as separate work items. Ask any implementation partner to show which deliverables satisfy ISO/IEC 42001 clauses and which are prepared for the AI Act, so that certification scope, the statement of applicability and the regulatory file stay distinct.
How to plan standards coverage before an ISO 42001 audit
This sequence turns a customer or regulator request into a scoped set of AI systems, a statement of applicability that names the supporting standards, and an evidence pack that an independent certification body can test.
Confirm the requirement that triggers the work
Start by identifying exactly what the customer, contract or regulator asks for. Some requests need an ISO/IEC 42001 certificate from an accredited certification body, while others only ask for a documented AI management system or a questionnaire answer. Write the requirement down, name the party that set it, and note whether it asks for certification, a self-declaration or evidence on request. The output is a one-page requirement record that the governance owner signs off, and it defines the finish line for every later step.
Map the AI systems in scope
Build an inventory of the AI systems the organization develops, provides or uses that fall inside the requested scope. For each system, record its purpose, the teams that build or operate it, the data it consumes, the third-party models or services it depends on, and the people affected by its outputs. Ask the business owners to confirm the list, because shadow AI tools are often missing from procurement records. The output is a scoped system register that the certification body will later use to judge whether the boundary is credible.
Select supporting standards for the statement of applicability
Decide which related standards the organization will cite when it justifies Annex A controls in the statement of applicability required by clause 6.1.3. ISO/IEC 23894 is the usual reference for risk treatment, ISO/IEC 42005 for impact assessment, ISO/IEC 22989 for shared terminology, and ISO/IEC 5338 or 8183 for life cycle and data processes. Standards that are guidance rather than certifiable requirements should be cited as methods, not as proof of conformity. Confirm each reference with the certification body before it appears in the document. The output is a list of referenced standards, each tied to the Annex A controls it supports.
Document inclusion and exclusion of each Annex A control
Work through the 38 Annex A controls across the nine objective areas and decide, for each control, whether it applies to the scoped systems. Record the justification for every inclusion and exclusion in the statement of applicability, because the standard requires a reason for each decision. Review the draft with legal, privacy and product owners so that exclusions do not hide gaps in data or third-party responsibilities. The output is an approved statement of applicability with a justification and an accountable owner for each control.
Prepare evidence for each Annex A area
For every included control, collect the records that show it operates in practice, such as the AI policy, role assignments, impact assessment reports, data provenance logs, model verification results, deployment approvals, user documentation and incident records. Keep the evidence in a versioned repository with dates, owners and review history. Where the organization uses self-hosted open-source tooling, configure logging and documentation so that records are generated during operation rather than assembled before an audit. Ask the implementation partner to confirm which records are generated automatically and which still need a human sign-off. The output is an evidence index that maps each control to specific artifacts.
Run an internal review against the evidence
Before the external audit, have someone independent of the implementation team sample the evidence and test whether each record matches the statement of applicability. Check that the AI system register matches what engineering actually runs, that impact assessments were completed before deployment, and that the management review and internal audit clauses have happened. Log every gap with an owner and a closure check. The output is a gap register with its closure status, which shows the certification body that the organization tests its own system before asking anyone else to.
Hand the evidence to an independent certification body
Share the scope, statement of applicability, evidence index and gap register with an accredited certification body and agree the audit plan in writing. Confirm whether the body is accredited for ISO/IEC 42001 and whether it applies the additional requirements in ISO/IEC 42006:2025. The certification body issues any report or certificate. DeployOpen and other implementation partners prepare systems and evidence but do not issue audit results. The output is an audit plan and a documented handover that separates the organization's controls from the auditor's findings.
How DeployOpen prepares systems and evidence for ISO 42001
DeployOpen works on the ISO AI standards family around ISO/IEC 42001 by preparing the systems and documented evidence that an organization's own AI governance depends on. We deploy and harden self-hosted open-source platforms inside your own infrastructure, and we do not issue audit reports or certificates, which only an independent certification body can do.
How we scope
- Engagements start with a written scope that names which AI systems, standards and Annex A controls are covered.
- We agree deliverables, environments and responsibilities with you before any work begins, so ownership of each control is clear.
- Scope also records what stays with your team, such as the statement of applicability and management decisions.
How we build
- We deploy and configure self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks.
- We set up logging, access records and version history so that events from AI systems can be traced and shown to an assessor.
- Where the scope includes it, we run security testing of AI systems and agents and record the findings and remediation.
How we hand over
- You receive the documented configuration, the evidence mapped to the agreed controls, and the runbooks your team needs.
- Documentation is written so your internal owners and an independent auditor can follow how each control is operated.
- Handover is complete when the agreed deliverables in the written scope are accepted by your named owner.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope work.
- Retainers can cover platform upgrades and evidence refreshes ahead of your surveillance or recertification audits.
- Confirm with us in the quote which support tasks and response arrangements are included before the retainer begins.
