Can You Get ISO 42001 Certified If You Use OpenAI, Anthropic, or Other Third-Party AI Models?
ISO 42001 with OpenAI or Anthropic in your stack is possible. What auditors ask about third-party AI models, evidence to prepare, and where founders trip up.
COMPLIANCE
TL;DR
Yes, you can be ISO 42001 certified while using third-party AI models. The standard was designed for this reality.
Auditors treat OpenAI, Anthropic, and similar providers as suppliers within your AI Management System (AIMS), not as blockers.
What auditors actually want: evidence of how you selected the provider, how you monitor its behaviour in production, and how you would respond if the provider's model or terms changed.
The two clauses that matter most: 6.1.4 (AI system impact assessment) and A.10 (third-party and customer relationships).
Where most founders trip up: treating the model provider as invisible plumbing instead of a documented supplier.
Yes. You can be ISO 42001 certified while using OpenAI, Anthropic, Google Gemini, Mistral, Cohere, or any other third-party foundation model. The standard was built for the world in which most AI-native SaaS products consume a model rather than build one, and the certification path assumes exactly this setup.
Why the question comes up at all
The misconception usually traces to how ISO 42001 is described in the earliest guidance. When the standard was published in December 2023, most of the practitioner writing focused on organisations building AI systems from scratch: model developers, research labs, large platforms training their own foundation models. Founders reading that early material could reasonably conclude that ISO 42001 was not built for a SaaS product that wraps someone else's API.
That reading is wrong. ISO 42001 certifies your AI Management System, which is the set of processes, roles, controls, and evidence by which your organisation governs the AI systems it operates. It does not certify the model itself. Whether you built the model, licensed it, or accessed it through an API, the AIMS is what gets certified. Our ISO 42001 for SaaS post covers the wider standard in more depth.
How ISO 42001 treats a third-party model provider
Within your AIMS, OpenAI or Anthropic is treated as a supplier. This is explicit in Annex A.10 (third-party and customer relationships), which is one of the nine control objectives in the standard's Annex A catalogue of 38 controls. A.10 covers the allocation of responsibilities across the AI system lifecycle when third parties are involved, and specifically addresses suppliers whose data, models, or services your AI system depends on.
The mental model that helps founders here: you do not own the model, but you own the decision to use it, how you use it, what data you send to it, how you handle its outputs, and what happens when something changes. Every one of those is inside your AIMS boundary. The model provider sits just outside that boundary, connected to you through contractual and technical controls that you are responsible for evidencing.
The second clause that matters is 6.1.4, the AI system impact assessment. This is the requirement that has no equivalent in ISO 27001 and is where auditors most often start their evidence review. It asks you to evaluate the potential effects of your AI system on individuals, groups, and society, grounded in the specific context where the system operates. When your AI system depends on a third-party model, the impact assessment must reflect that dependency, not gloss over it.
Who ISO 42001 applies to
The standard is deliberately broad. It applies to organisations that:
Develop AI systems, including foundation models, fine-tuned models, agents, and ML pipelines
Deploy AI systems built by third parties (which covers most SaaS companies using LLM APIs)
Provide services powered by AI, such as automated support, underwriting, or screening
For a typical SaaS company building on top of an LLM API, ISO 42001 covers how you govern those integrations. That means what data flows to the model, how outputs are validated, how you decide when a human reviews the output, and what happens when the model gets something wrong.
What auditors actually ask about your third-party model use
Six concrete questions come up in audits of AI-native SaaS products building on third-party models. Each one has a good answer that is simpler than founders expect, provided the work has been done.
How did you select this model provider? What alternatives did you evaluate?
A good answer names the alternatives you considered, the criteria you used to evaluate them (capability, cost, data handling terms, latency, geographic processing, roadmap), and the reasoning behind your choice. "We use GPT-4 because everyone uses GPT-4" is not an answer. A short supplier evaluation record from the time you made the decision is.
What contractual and technical controls does the provider offer around data handling?
A good answer references the provider's enterprise privacy terms, your signed Data Processing Agreement, the retention position you have negotiated or accepted, and whether you use Zero Data Retention for eligible workloads. Auditors are looking for evidence you understood what you signed up for.
What data are you sending to the model, and what is your legal basis for that under GDPR, DPDP, or PDPL?
A good answer includes a data flow diagram showing exactly what leaves your infrastructure per LLM call, whether that data includes personal data, and the lawful basis for the processing under the applicable privacy regimes. This is where our OpenAI and Anthropic data governance checklist becomes directly relevant.
How do you monitor the model's outputs in production? What triggers a review?
A good answer describes what you log, what quality signals you track, how user complaints tied to model behaviour are captured and investigated, and what specific patterns would trigger a controls review or a model change. Continuous monitoring is a first-class expectation under ISO 42001, not an afterthought.
What is your contingency if the provider's terms change, the model is deprecated, or output quality drifts?
A good answer describes your process for reviewing provider term changes, your position on model version pinning, and your fallback plan if you needed to switch providers. Both major providers have changed their retention terms multiple times in the last eighteen months, which auditors know.
How is the AI system's impact on affected individuals assessed and documented?
A good answer references your AI system impact assessment (the artefact required by clause 6.1.4), including foreseeable misuse, effects on individuals whose data the system processes or whose outcomes the system influences, and the mitigations you have in place. This document is often the first evidence an auditor asks for.
The evidence you should prepare before an audit
Working backwards from the questions above, the artefacts that make an audit smoother:
A supplier evaluation record for each model provider, dated and reasoned. A data flow diagram showing what enters and leaves each AI feature. An AI system impact assessment covering intended use, foreseeable misuse, and effects on affected individuals. Monitoring evidence in the form of logs, dashboards, or a review cadence that shows you actually watch model behaviour in production. An incident response playbook that includes model-related failure modes such as term changes, deprecations, and quality drift. The signed Data Processing Agreement with each provider and a note on where personal data processing sits under it.
None of this needs to be elaborate. What it needs to be is real. Auditors can tell the difference between evidence that reflects a functioning process and evidence that was assembled the week before the audit.
Where founders most often trip up
Four patterns come up often enough to be worth naming.
Treating the provider as invisible infrastructure. The AIMS boundary includes every AI system you operate, and every operated system has a documented supplier where you did not build the model yourself. A blank in the supplier register for "the OpenAI dependency" is the single most common failure at first audit.
Skipping the AI impact assessment because "we're just using the API." The impact assessment under 6.1.4 is about the effect of the AI system on affected individuals and society, not about who wrote the model. A summarisation feature that surfaces AI-generated content to end users has an impact regardless of which provider generates the summary.
Not documenting why the specific model was chosen. Auditors do not need you to justify OpenAI over Anthropic. They need to see that you made an actual choice, with actual criteria, and can defend it. Retrospective justification is much harder than contemporaneous documentation.
Missing monitoring. No logging of prompts and outputs, no quality signal tracking, no channel for user complaints about model behaviour to reach the team that could act on them. This is where AIMS controls most often fail in operation rather than in design.
How this fits alongside SOC 2 and ISO 27001
ISO 42001 does not replace SOC 2 or ISO 27001. It sits alongside them. SOC 2 attests to your controls against the AICPA Trust Services Criteria. ISO 27001 certifies your Information Security Management System. ISO 42001 certifies your AI Management System specifically, addressing questions the other two do not: impact on affected individuals, AI-specific supplier governance, transparency about AI use, and the lifecycle of the AI system itself.
Enterprise buyers increasingly ask for two or three of these together. A SaaS with an AI feature selling into a regulated enterprise buyer in 2026 is often being asked for SOC 2 as the baseline, ISO 27001 for international recognition, and ISO 42001 for the AI-specific governance question. Our compliance audits page covers the full set.
Frequently asked questions
Do I need to disclose which model provider I use in the certification?
Yes, at least to the auditor. The supplier register is part of the evidence. Your certificate itself does not name providers, but the audit that produces the certificate does.
Can I switch model providers after being certified?
Yes. A provider switch is a change to the AIMS and needs to be handled through your change management process, including an updated supplier evaluation and a review of the impact assessment. It does not invalidate the certification if handled properly.
Does the provider need to be ISO 42001 certified for me to be certified?
No. Whether your provider holds ISO 42001 is one input to your supplier evaluation, but it is not a prerequisite for your own certification. As of late 2026, few foundation model providers hold ISO 42001 themselves, and this is not blocking their customers from certifying.
What if I use multiple models (for example, OpenAI for chat, Anthropic for analysis)?
Each provider is a separate supplier within your AIMS, with its own evaluation, contract, and data flow. This is common in practice and does not complicate the certification path, but it does increase the evidence you need to maintain.
How is this different from getting SOC 2 or ISO 27001?
ISO 42001 addresses AI-specific governance concerns that SOC 2 and ISO 27001 do not: the AI system impact assessment, AI-specific supplier controls, and the AI system lifecycle. The frameworks overlap on general information security controls but diverge on what the AIMS uniquely governs.
Roughly how long does ISO 42001 certification take for a SaaS building on third-party models?
For a SaaS that already holds SOC 2 or ISO 27001, ISO 42001 typically takes three to six months of preparation before the certification audit. Companies starting from no compliance baseline should expect longer, since the AIMS depends on foundational management system practices that also underpin the other standards.
Where to start
If you are weighing ISO 42001 certification and building on OpenAI, Anthropic, or another foundation model, we have helped teams like yours map the exact scope.
For related cybersecurity and compliance insights, our blog covers the wider landscape for SaaS and FinTech founders building across India and the GCC.
Secure your business with expert help
Company
Services
© 2026 Auro Security. All rights reserved.
Connect
insights