You ship AI features on a sprint cycle. ISO/IEC 42001 asks whether you can show how they're governed: the models you call, the customer data they touch, and who signs off when a provider changes something underneath you. We help SaaS and AI product teams build that AI management system and get it ready for a certification audit.
For a SaaS company, ISO/IEC 42001 is less about a badge on the website and more about answering the AI questions that now turn up in enterprise deals, with evidence instead of assurances.
Look at a recent enterprise security review. Next to the usual encryption and access-control questions you'll often find a newer block: which models do you use, does our data train them, where are prompts processed, can AI be switched off for our tenant, how do you catch a bad output? Your SOC 2 report or ISO 27001 certificate answers the security half of that. It was never built to answer the AI half.
Your AI stack also moves faster than most control environments. A model provider retires a version. Someone edits a prompt template in a config file that never goes through code review. A new feature adds an embedding pipeline over customer documents. And because it's multi-tenant, one AI feature reaches every customer the day it ships, so a weak retrieval boundary is both a security problem and an AI governance problem.
ISO/IEC 42001:2023 is the international standard that sets requirements for an AI management system (AIMS): how an organisation that develops, provides or uses AI systems establishes, runs and keeps improving its governance of them. It's voluntary, it's certifiable by an accredited certification body, and it certifies your management system. It doesn't certify that any one model is accurate or safe.
Your customers don't need a promise that your AI is responsible. They need to see how a model change gets reviewed.
ISO 42001 is written for any organisation that develops, provides or uses AI systems. So the useful question isn't whether it applies to you. It's which parts of it will carry the weight.
That depends on your role. Developing AI means building, training or fine-tuning models. Providing AI means making AI functionality available to others, which is what most SaaS products with AI features do. Using AI means relying on AI systems in your own operations. Plenty of SaaS companies are all three at once, and each role shifts your scope, the Annex A controls that apply and what you owe customers and suppliers.
You're a developer and usually a provider too. This is where ISO 42001 goes deepest, because you control the data, the training and the release decision.
You don't control the model weights, but you control almost everything around them: prompts, retrieval, guardrails, what data goes in and how outputs reach users. To your customer, that's your AI system. Your model provider's own certifications cover their organisation, not your implementation.
You're a provider, and your customers are now deploying your AI inside their own processes. Their risk teams will want to know what they're taking on.
Once an AI system can act (close a ticket, call an API, update a record, send an email), oversight stops being a policy statement and becomes a design decision.
Prompts, embeddings, fine-tuning sets and evaluation data all count. Your data processing agreements already make promises here. The AIMS has to show those promises hold inside AI features.
You're a user of AI: coding assistants, internal copilots, AI features inside the SaaS tools you buy. The scope can be narrower, and certification may not be the right first step.
Not sure where you stand? Fifteen questions will show you the likely gaps before you talk to anyone.
Check Your ISO 42001 ReadinessYour security team knows where the attack surface is. AI risk sits in slightly different places. These are the eight we'd look at first in an AI-enabled SaaS stack, and the question each one has to answer.
Prompts carrying customer records. Tenant documents embedded in a vector database. A fine-tuning set exported from production.
Question to answer: can you trace where a dataset came from, what it may be used for, and when it leaves the index?
A support copilot that invents a refund policy. Summaries that drop the one clause that mattered. Rankings that drift after a retrain.
Question to answer: what did you test before release, against which acceptance criteria, and what triggers a rollback?
A foundation-model API, a hosted embedding model, open-weights models pulled from a public hub.
Question to answer: what does the provider do with your inputs, where are they processed, and how much notice do you get before behaviour changes?
AI replies sent to end customers automatically. Agents that change configuration. AI-scored leads routed without anyone looking.
Question to answer: where can a person step in, and was that point designed or just assumed?
Customers who can't tell which features use AI, which provider sits underneath, or that outputs can be wrong.
Question to answer: what do you tell customers about intended use and limitations, and how do they report a problem?
Prompt injection through retrieved documents. Data leaving through tool calls. One tenant's content showing up in another tenant's answer.
Question to answer: are AI-specific attacks in your threat model and your AI/LLM penetration testing scope, or only the application around them?
A provider deprecates the model version you tested. Finance asks you to switch providers to cut cost. A prompt template changes outside code review.
Question to answer: which of these trigger a fresh assessment, and who makes that call?
Quality dashboards nobody owns. Thumbs-down feedback that's collected and never read. No agreed definition of an AI incident.
Question to answer: what's monitored in production, who reviews it, and what counts as an incident?
ISO 42001 isn't a GRC project engineering hears about a week before the audit. The work lands across the company, and each team ends up producing evidence it didn't produce before.
| Team | What changes | Evidence it produces |
|---|---|---|
| Leadership & governance | Approve an AI policy that says what you will and won't build. Set AI objectives. Name owners who have real authority, including the authority to hold a release. | Approved AI policy, documented roles and authorities, management review records |
| Engineering & ML | Governance gates inside the delivery pipeline: requirements, verification and validation, release approval. Prompts, model configs and retrieval settings go under version control and change review. | Test and evaluation records, release approvals, AI system documentation, logs |
| Product | Define intended use and limitations for each AI feature. Decide where human oversight sits. Trigger an impact assessment when a new AI feature is specced, not after launch. | Impact assessments, feature-level AI documentation, customer-facing disclosures |
| Security | Extend threat modelling and testing to prompt injection, data leakage through tools and cross-tenant retrieval. Bring AI incidents into incident response. | AI threat models, test scope and results, incident runbooks and records |
| GRC & compliance | Run the AI risk assessment and the Statement of Applicability. Maintain the AI system inventory. Map the AIMS to customer commitments and to regulation such as the EU AI Act where it applies, or to the NIST AI RMF Generative AI Profile if US customers ask for it. | AI risk register, Statement of Applicability, inventory, internal audit reports |
| Procurement & vendor management | AI-specific due diligence for model providers and AI-enabled tools. Contract terms on training use, retention, processing regions and change notice. Re-review when a supplier materially changes its model. | AI supplier assessments, contract clauses, periodic review records |
If you hold ISO/IEC 27001 or a SOC 2 report, you already have habits auditors recognise: risk processes, supplier reviews, change control, internal audit. ISO 42001 reuses a lot of that. It doesn't reuse the questions.
ISO 42001 follows the same management-system clause structure as ISO 27001, so the two integrate cleanly. SOC 2 is different: it's a CPA attestation on controls against the AICPA Trust Services Criteria, not a management system, so the reuse happens at control level. Neither one asks for AI impact assessment, model lifecycle governance or AI-specific transparency.
An integrated programme works well: one scoping exercise, shared evidence where controls genuinely overlap, one internal audit cycle. Relabelling ISMS documents as AIMS documents doesn't. Auditors read the content.
93 checks across 12 readiness domains, with clause and Annex A references and a Yes / Partial / No scoring method. Built for teams that want to see the full picture before a gap assessment.
Twelve steps, four phases. The order matters less than one rule: every step should end up inside a workflow your teams already use, not in a document they have to remember.
Decide what you're governing.
Products, AI features, teams and locations. Draw it around how AI is really built and sold, not around what looks easiest to certify.
Include API-based features, internal copilots and AI switched on inside tools you already pay for.
Developer, provider, user, or a mix. It drives controls and contract responsibilities.
Measure before you build.
Against the management-system clauses and Annex A, crediting what your ISO 27001 or SOC 2 programme already covers.
A policy that reflects what you actually build, objectives you can measure, and owners with authority.
Make it part of delivery.
Defined criteria, repeatable method, treatment decisions with owners.
Effects on users and affected people. Put the trigger in your feature-spec template, or it won't fire.
Annex A is a reference set, not a checklist. Your Statement of Applicability justifies what's in and what's out.
In the places people work: PR templates, CI checks, release tickets, vendor intake forms.
Show the system runs.
Completed assessments, supplier reviews, monitoring records. Auditors test operation, not intent.
Independent enough to find real issues, with corrective actions tracked to closure.
Run by an accredited certification body, typically in two stages: a documentation and readiness review, then an audit of how well the AIMS works in practice.
Want a view on which phase you're actually in, and what it would take to reach an audit?
Discuss Your ISO 42001 ReadinessReadiness gaps worth checking in a SaaS environment include the eight below. Each one comes with a test you can run this week without a consultant.
It lists the flagship AI feature and misses the embedding job, the classification model in onboarding and the AI inside bought tools.
Quick check: compare the inventory with the model-provider line items on your cloud bills and the AI API keys in your secrets manager.
An engineer signed up for a model API on a company card to prototype, and the prototype shipped.
Quick check: search expense reports and vendor lists for AI providers, then ask whether each one went through supplier review.
Risks get discussed in launch meetings and Slack threads, then nobody records criteria or decisions.
Quick check: for the last AI feature you shipped, can you produce the risk criteria used and the completed assessment?
A threat model or DPIA gets relabelled as the AI system impact assessment.
Quick check: does it consider what happens to the people on the other end, such as a user misled by an answer or a candidate wrongly ranked, and not only data exposure?
You have the model provider's SOC 2 report on file, and nothing about training use, retention or model changes.
Quick check: open the contract with your main model provider and find what it says about using your data for training and warning you of model changes.
A model version bump merges as a one-line config change, with the same review as a typo fix.
Quick check: find your last model or provider change. Is there any record of re-testing or sign-off?
The policy is approved and published. The PR template, feature spec and vendor intake form don't mention it.
Quick check: name one place in your engineering workflow where the AI policy changes what someone actually does.
Procedures describe monitoring and reviews on a cadence that hasn't started yet.
Quick check: produce last month's production monitoring records for your most-used AI feature, with evidence someone reviewed them.
Two free ways to see where you stand before you commit budget or an audit date.
Need more depth? The full 93-point readiness checklist covers 12 domains with clause and Annex A references.
We've done audit and compliance work since 2004. For ISO 42001, that means working with auditors who can tell a management system that runs from one that only exists on paper.
We prepare you for certification and support you through the audit. The certificate itself is issued by an accredited certification body, which is how it should be.
ISO/IEC 42001 is the international standard for an AI management system. For a SaaS company, it means having a governed, evidenced process for how AI features are scoped, risk-assessed, built, sourced from suppliers, monitored and changed, which an accredited certification body can audit. It certifies the management system, not the accuracy or safety of a particular model.
You don't legally need it, but not training your own model doesn't put you outside it. The standard covers organisations that provide or use AI systems, not only those that build models. If you ship features built on a third-party model, you're providing an AI system to your customers. The provider's own certifications cover their organisation, not your prompts, retrieval, data handling or how outputs reach users.
No. ISO 42001 is voluntary. The pressure usually comes from enterprise procurement asking for evidence of AI governance, and from regulations where a structured AI management system makes it easier to show how you meet your obligations.
ISO 27001 governs information security. ISO 42001 governs how you develop, provide and use AI systems, including impacts on people, data quality, transparency, human oversight and your AI supply chain. They share the same management-system structure, so they integrate well, but they're separate certifications with separate scopes. Holding one doesn't give you the other.
Not by design. SOC 2 is an attestation on controls against the AICPA Trust Services Criteria for security, availability, processing integrity, confidentiality and privacy. Your AI features can sit inside a SOC 2 system description, and relevant security controls apply to them, but the criteria don't call for AI impact assessment, model lifecycle governance or AI-specific transparency. Many SaaS companies end up with both.
No. The EU AI Act is law and ISO 42001 is a voluntary standard. ISO/IEC 42001 isn't a harmonised standard cited in the Official Journal of the EU, so certification doesn't give you a presumption of conformity. A working AIMS does organise much of the evidence the Act expects, such as risk management, documentation, oversight and monitoring, but your actual obligations depend on your role and on how each AI system is classified.
Timing matters too. The Act's transparency obligations under Article 50 have applied since 2 August 2026, and the Digital Omnibus on AI, Regulation (EU) 2026/1744, moved high-risk obligations to 2 December 2027 for stand-alone Annex III systems and 2 August 2028 for AI embedded in Annex I products. See EU AI Act vs ISO 42001 for the full comparison.
It depends on how many AI systems are in scope, how mature your governance already is and whether you run ISO 27001. The part you can't compress is operating time: the certification audit looks for evidence that the AIMS has actually run, including assessments, monitoring, internal audit and management review. We give you a written timeline after scoping. For typical ranges, read our ISO 42001 certification timeline guide.
Yes. You define the AIMS scope, and it can cover one product or a group of AI features, as long as the boundary is clear and justified. Remember that the scope statement is what customers see on your certificate. A scope drawn around the easiest feature, rather than the ones customers worry about, won't answer their questions.
Walk us through your AI features, your model providers and your existing ISO 27001 or SOC 2 controls. You'll leave with a clear view of the gap and a written plan to close it.
Looking for the wider picture? See our ISO 42001 certification services or our compliance work for cloud and SaaS providers.
Expert Auditors. Faster Certification.
VISTA InfoSec LLC,347 Fifth Ave,
Suite 1402-526, New York, NY 10016
© Copyright 2026. VISTA InfoSec. All Rights Reserved. | Disclosure Policy | Privacy Policy | Sitemap
Enquire Now