ISO 42001 for Self-Hosted AI: What Auditors Actually Ask For (and What Your Infrastructure Has to Prove)

Key Points:

• ISO/IEC 42001:2023 certifies an AI management system (AIMS), never a model. The certificate covers the policy, roles, risk assessments, impact assessments and controls your organization runs around AI, inside a scope you declare. There is no such thing as a "certified model".
• Certification needs the full Clause 4-10 management system (context and scope, leadership and AI policy, planning, support, operation, performance evaluation, improvement) plus a Statement of Applicability that implements or excludes each of the 38 Annex A controls with a written justification.
• Two requirements are AI-specific and cause most early findings: the AI risk assessment and treatment process, and the AI system impact assessment, which must cover consequences for individuals, groups and societies. ISO 27001 has no equivalent impact assessment.
• For self-hosted AI, most audit evidence is infrastructure evidence: which cloud account and region the models run in, who can reach the inference endpoints, how each deployed version got there and who approved it, what is logged and for how long, and how you prove the running state matches the approved one.
• Certification is a two-stage external audit by an accredited body, then annual surveillance audits over a three-year certificate. "Audit-ready" means your platform produces evidence every day, not that someone screenshots dashboards the week before Stage 2.

Enterprise buyers now ask about AI governance in the same breath as SOC 2. A-LIGN's 2026 benchmark found that 80% of companies using AI already get questions from customers about their AI risk management practices (A-LIGN 2026 Compliance Benchmark Report). ISO/IEC 42001 is the certificate those buyers increasingly name.

Most teams I talk to discover the gap during a security review, when a buyer asks where their self-hosted model runs, who can deploy to it, and how they know the version in production is the one that was approved. The answers exist in someone's head. Auditors want them in records. This guide covers what the standard actually requires and what your infrastructure has to prove.

What is ISO/IEC 42001 actually certifying - the model, or the organization?

ISO/IEC 42001:2023 certifies an AI management system: the governance, roles, risk processes and controls your organization operates around AI, inside a scope you declare. It does not certify that a model is accurate, fair or safe, and no accredited body issues a certificate for a model.

• The standard. ISO/IEC 42001:2023 was published in December 2023 (Schellman), and DNV describes it as "the first international and certifiable management system standard for artificial intelligence management systems" (DNV).
• An AIMS in one sentence. It is the set of policies, objectives and processes an organization uses to develop, provide or use AI systems responsibly, as Microsoft's summary of the standard puts it (Microsoft Learn).
• What a certificate says. Organization name, scope statement, standard and edition, the certification body and its accreditation mark, and validity dates. Nothing about model quality.
• The scope statement is the first line buyers read. Microsoft lists exactly which services its certificate covers, from GitHub Copilot to Microsoft Foundry (Microsoft Learn). If your scope covers "the internal HR chatbot", a buyer evaluating your inference API will notice.
• Roles. The standard builds on the roles in ISO/IEC 22989: AI provider, AI producer, AI customer (which includes AI users), AI partner and AI subject. Self-hosting an open-weight model usually makes you a provider of your own AI system and a customer of a third-party component, the weights.
• Self-hosting moves the evidence burden to you. The isolation, logging and residency controls an API vendor would carry now sit in your cloud account, so you produce that evidence yourself.

Buyers conflate five things. Only two of them end in a certificate.

The AI Act matters for timing. It entered into force on 1 August 2024, prohibitions applied from 2 February 2025, GPAI obligations from 2 August 2025, and the AI Omnibus pushed most high-risk obligations to 2 December 2027 (European Commission). Buyers in Europe already want governance evidence before that date arrives.

What does ISO 42001 require clause by clause before an auditor will certify you?

ISO 42001 follows ISO's harmonized structure, so Clauses 4 through 10 are mandatory and auditable: context and scope, leadership and AI policy, planning, support, operation, performance evaluation and improvement. An auditor asks for documented evidence against every one of them, and you cannot exclude a clause the way you can exclude an Annex A control.

• Clause 4. Organizational context, interested parties, your declared role in the AI lifecycle, and the written AIMS scope.
• Clause 5. Top management commitment, a documented AI policy, and named owners for AI risk. Expect the question "who signed this, and when?"
• Clause 6. AI risk assessment and treatment, the AI system impact assessment, measurable AI objectives and the Statement of Applicability. Schellman notes that Clause 6 "goes a step further than some of the other familiar ISO standards" by requiring an impact assessment of consequences "on individuals, groups, and societies" (Schellman).
• Clause 7. Competence and awareness records, communication, and controlled documented information that is versioned, approved and retrievable on request.
• Clause 8. Operational planning and control. This is where auditors walk through your deployment pipeline, environment separation, change approval and per-release lifecycle records.
• Clause 9. Monitoring and measurement, an internal audit programme, and management review minutes with decisions and actions.
• Clause 10. Nonconformity handling, corrective action records and continual improvement.

Mandatory documented information should come out in minutes: scope, AI policy, risk and impact assessment results, Statement of Applicability, AI objectives, internal audit results, management review results and corrective actions. If producing any of these needs a Slack thread, fix that first.

Which ISO 42001 Annex A controls hit your self-hosted AI infrastructure hardest?

Annex A of ISO 42001 contains 38 controls organized into 9 control objectives (Schellman), and for self-hosted AI the four that land hardest on infrastructure are resources for AI systems, the AI system lifecycle, data for AI systems, and third-party relationships. The other objectives cover AI policy, internal organization, impact assessment, information for interested parties and responsible use.

• Resources for AI systems. A documented inventory of compute, GPUs, storage, tooling, data and people, down to the cloud account, region and cluster.
• AI system lifecycle. Design, development, verification and validation, deployment, operation and monitoring, with a record per release, not a policy PDF.
• Data for AI systems. Provenance of training and fine-tuning data, quality and preparation, and where inference data physically lives and for how long.
• Impact assessment. Consequences for individuals and groups, reviewed on a defined cadence and after material changes such as a new model version.
• Third-party and customer relationships. Open-weight model licenses, GPU capacity providers, vector database vendors, model API fallbacks. You still own the risk.
• Statement of Applicability discipline. Every control is implemented or excluded with a written reason. Auditors spend a lot of Stage 1 probing exclusions.

What infrastructure evidence do auditors and enterprise buyers actually ask for?

Auditors and enterprise security reviewers converge on five infrastructure questions: where does it run, who can touch it, how did this exact version get there, what is logged and for how long, and how do you prove today's running state matches the approved state. If your platform cannot answer those from its own records, you are not audit-ready.

• Where it runs. Cloud account, region, VPC, cluster, whether prompts or inference traffic ever leave your boundary, and whether any vendor can read them.
• Who can touch it. Per-environment RBAC, production and staging separation, who can deploy to the GPU inference environment, and a logged break-glass procedure.
• How the version got there. Every deployment tied to a commit SHA, an approver and a timestamp, with environments reproducible from code.
• What is logged. Endpoint availability, your prompt and output logging decision, drift and abuse monitoring, retention periods, and incident records feeding Clause 10.
• Supplier evidence. Subprocessor list, weights provenance and license, GPU provider agreements, third-party assessment records.

The demand is real. Stanford's AI Index 2026 reports that ISO/IEC 42001 was already cited by 36% of respondents in its responsible AI survey, ahead of the NIST AI RMF at 33% (Stanford HAI AI Index 2026). And compliance already eats time: Vanta's State of Trust research found respondents spend 7.5 hours a week staying compliant (Vanta).

The classic pitfall is screenshot evidence. Screenshots gathered the week before Stage 2 pass once and collapse at the first surveillance audit, because the auditor samples a period when nobody was taking them.

How long does ISO 42001 certification take, who issues it, and what does it cost?

An accredited certification body issues the ISO 42001 certificate after a two-stage audit, and the certificate is valid for three years, maintained through annual surveillance audits (Schellman). Plan in months, and expect internal effort to cost far more than the audit fee.

• Sequence. Gap analysis, implementation, at least one internal audit, management review, Stage 1 (documentation and design), Stage 2 (operational effectiveness), certificate, surveillance, recertification. DNV explicitly expects internal audits and a management review before the certification audit (DNV).
• Stage 1 failures are rarely technical. A weak Statement of Applicability or a missing impact assessment stops you long before anyone looks at a cluster.
• Accreditation matters. Buyers check the accreditation mark (UKAS, ANAB and equivalents). Schellman was the first body ANAB accredited for ISO 42001 (Schellman) and BSI the first accredited by UKAS (BSI).
• Cost and duration drivers. Scope breadth, number of AI systems and sites, headcount, and whether you hold ISO 27001 already.
• ISO 27001 shortens the path. Both standards share the harmonized structure, and risk management, internal audit and continual improvement processes carry over from an existing ISMS (Schellman; DNV).
• Evidence never stops. Surveillance audits sample the months you were not preparing.

I have not found a reliable published count of ISO 42001 certificates worldwide, so I won't quote one. What is clear is that the big AI vendors already hold it, which raises the bar buyers apply to everyone else.

Can you be ISO 42001 audit-ready if your AI runs on someone else's infrastructure?

Yes, you can certify while using third-party infrastructure, but once your AI workloads execute in a vendor's account you inherit their boundary, their logs and their region choices, and you evidence that dependency through supplier controls and their certifications instead of your own records. Microsoft makes this explicit: you can use its certificate in your assessment, but you still engage an assessor for your own controls (Microsoft Learn).

• Managed AI APIs (Amazon Bedrock, Google Vertex AI, Azure AI Foundry, OpenAI). Fastest to ship. Residency, retention, model version changes and subprocessor lists become supplier controls you collect and review. Most enterprises are here: Menlo Ventures measured open-source model share in the enterprise falling from 19% to 11% in 2025 (Menlo Ventures).
• Vendor-hosted PaaS (Heroku, Render, Vercel). The workload runs in the vendor's account, so your Statement of Applicability leans on their attestations and your evidence stops at their boundary.
• Self-hosted in your own cloud account. You keep the boundary, the logs, the region and the export rights. You also own Kubernetes, GPU scheduling and lifecycle operations.
• Fully DIY Kubernetes (or Red Hat OpenShift AI run by your team). Maximum control and maximum evidence burden. This is where deployment audit trails most often break, because someone deploys from a laptop.

Where Qovery fits. Qovery deploys and operates applications inside your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster. Models, data, GPUs and logs stay inside your boundary, and the infrastructure evidence stays exportable from your own account. You get Kubernetes without managing it directly, and teams without a dedicated DevOps engineer still get an audit trail generated by the platform rather than by a person.

• Git-push deployments tied to a commit support change traceability and per-release lifecycle records.
• Per-environment RBAC supports access control and segregation of duties.
• Preview environments per pull request give you separated non-production testing.
• Environment auto-stop supports resource management for expensive GPU environments.
• Managed cluster upgrades support operational control.
• Databases backed by your cloud's managed services keep data handling inside your account.

To be fair and explicit: Qovery is not an ISO 42001 compliance product and not a certification body. It does not write your AI policy, risk assessment, impact assessment or Statement of Applicability. Tools like Vanta and Drata help manage that documentation and collect evidence. Qovery produces the infrastructure-side evidence and the control boundary underneath it.

What should you fix first if you are starting from zero?

Start with the scope statement and the two AI-specific artifacts auditors ask for first, the AI risk assessment and the AI system impact assessment, then make your infrastructure generate the rest of the evidence automatically. Collecting infrastructure evidence by hand is the most expensive way to stay certified.

• Weeks 1-2. Write the scope statement, declare your roles, and inventory every AI system, model, dataset, inference endpoint and GPU environment with its cloud account and region.
• Weeks 3-6. AI policy signed by top management, AI risk assessment and treatment plan, AI system impact assessment, Statement of Applicability with justified exclusions.
• Weeks 6-12. Close infrastructure gaps: per-environment RBAC, deployment audit trail tied to commits, infrastructure as code for every environment, log retention, backup and restore evidence.
• Ongoing. Internal audit, management review minutes, corrective actions. These prove the system runs.
• Reuse ISO 27001. Keep the controls you already hold and ask your certification body about an integrated audit.

Anti-patterns I see repeatedly:

• A scope so narrow that buyers reject it.
• An impact assessment copy-pasted from a GDPR DPIA, which covers personal data but not broader consequences for groups and society.
• Manual screenshot evidence.
• Policies describing a deployment process nobody follows.

How do I set up audit-ready, self-hosted AI infrastructure with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills once, then ask your coding agent in plain language to deploy the workload into your own cloud account. Every action asks for your approval, and the resulting deployments carry the same commit-level history an auditor samples.

curl -fsSL https://skill.qovery.com/install.sh | bash

# Or scoped to the current project only
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# Qovery MCP Server in Claude Code (OAuth, read-only by default)
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# Write access, only when you want it (also enable it in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills are qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform. The MCP Server operates what already exists.

Then ask, for example: "deploy this inference service to my own AWS account with Qovery, with production and preview environments separated and RBAC restricted to the ML team". See the AI agent quickstart and the Claude Code integration.

For the audit, this gives you a defensible story on agent access: read-only by default, write access as an explicit opt-in, per-action approval, and every agent-triggered deployment lands in the same commit-linked deployment history as a human one.