Since December 2023 there has been a certifiable management standard for artificial intelligence: ISO/IEC 42001. Since then, the question of ISO 42001 vs ISO 27001 has been coming up in certification cycles and sales conversations, usually in the form: "Do we need this now as well?" The short answer for most Swiss SMEs: the content of the standard concerns you, the certificate hardly does for now. The rest of this article explains why.
What ISO/IEC 42001 is
The standard was published in December 2023 and is the first management standard for artificial intelligence that an organization can be certified against by an accredited body. The construct behind it is called an AI Management System, AIMS for short. It addresses any organization that develops, provides or uses AI. So it also addresses the SME that will never train a model and has long been working with Copilot and ChatGPT anyway.
Just as important is what the standard is not: no technical checklist for secure AI models and no seal of approval for individual tools. It describes how an organization governs its use of AI. Roles, policies, the risk process, the lifecycle of systems, the handling of suppliers and purchased models.
Anyone who knows ISO 27001 will recognize the layout immediately. ISO 42001 uses the same harmonized structure as all newer ISO management standards: context, leadership, planning, support, operation, evaluation, improvement. The mechanics behind it are the same too. An annex of concrete controls from which you select, with justification, what applies to your organization, and an auditor who checks whether you do what you have documented. That is intentional. The standards are built to be combined, and exactly this property decides the cost question further down.
So an ISO 42001 auditor does not look at your model or your prompts. He looks at whether a policy exists, who is responsible for AI decisions, how risks and impacts are assessed, how you keep purchased models and providers under control, and whether the lifecycle of your systems is managed. Leadership work, documented and traceable. Anyone who has been through a 27001 audit knows the feeling.
The difference lies in the direction you look
ISO 27001 asks the question: what can happen to our information? Confidentiality, integrity, availability. The risk comes from outside or from inside, and it hits your data.
ISO 42001 turns the direction of view around. The question is: what can our AI system cause? The risk originates from the system itself, and it hits customers, employees or decisions. That is why the standard demands things that do not exist in an ISMS: an impact assessment for the people a system affects, requirements for transparency and human oversight, and control over the whole lifecycle, from the procurement decision to decommissioning.
An example makes this tangible. Whether company data flows to a provider through an AI tool is a 27001 question: data flows, processing agreements, access control. Whether your AI-supported pre-sorting of job applications disadvantages certain groups is a 42001 question. The first risk hits your information. The second originates from your system and hits people. An ISMS does not see the second risk at all, because it was never built for it.
The same pattern shows up in a Copilot rollout. Which documents the assistant is allowed to read is decided by your permission model; that is clean 27001 territory, and that is also where most rollouts fail. Whether a clerk copies a hallucinated number into a customer quote unchecked is a question of human oversight and process design. An ISMS has no category for that, an AIMS does.
In practice this does not mean you have to manage two separate risk worlds. It means your existing risk analysis gains a column: the question of what originates from a system, next to the familiar question of what can happen to it.
ISO 42001 and ISO 27001: the overlap is bigger than the difference
If an ISMS is running in your company, a large part of the 42001 apparatus is already in operation: the risk process, document control, the management review, the internal audits. The standard does not require you to build all of that twice. It docks on.
What gets added is manageable and makes sense on its own, with or without a certificate. An inventory of the AI systems in use, including the tools individual teams use without approval. An AI policy that regulates who may use which tools with which data. And the impact assessment for the systems that make or prepare decisions about people.
The most uncomfortable part of this is the inventory, for a simple reason: it is practically never complete. AI features sit in tools nobody procured as AI, in the CRM just as much as in the translation service, and individual employees have long been using private accounts for company work. In our experience this shadow usage is the normal case, and it is also the reason an AI policy without an inventory achieves little. You end up regulating the visible part and overlooking the rest.
This is exactly how we implement AI governance in our mandates: as an extension of the existing security management. Nobody needs a second management system next to it, and the substance carries later, should a certificate become necessary after all.
When the second certificate pays off
Honestly: for most Swiss SMEs, not yet. There are three situations in which the calculation tips.
First: you sell AI. If your product is an AI system or contains one and your customers are large corporations, ISO 42001 will sooner or later appear in procurement's security questionnaire. Then the certificate becomes a sales document. Suppliers know this mechanic from ISO 27001, where the questionnaire often pushes harder than any law.
Second: the EU AI Act affects you. Since 2 August 2026 the obligations for high-risk systems under Annex III apply, and the Act also applies to Swiss companies whose systems are used in the EU. A 42001 certificate is no proof of AI Act compliance; the assessment criteria differ. But the governance structure the standard demands overlaps to a large extent with what you have to document for the Act anyway. What the Act means for Swiss companies in concrete terms is something we have written up in a separate article.
Third: a key customer or a tender demands the proof contractually. Today we rarely see this. But we expect the same development as with ISO 27001, where scattered customer requirements turned into a standard procurement criterion within a few years.
And Switzerland itself? It does not force you. The Federal Council decided on 12 February 2025 that Switzerland will not get its own AI law modelled on the EU. Instead it is ratifying the Council of Europe's AI Convention and adjusting existing laws sector by sector; a consultation draft is due by the end of 2026. For the handling of personal data, the Swiss data protection act applies anyway, with or without AI. If you process personal data in AI tools, the homework remains the same as with any cloud service: processing agreement, data categories, transfers abroad. You do not need a new standard for that, only the discipline your ISMS demands anyway.
Where the money is better spent
A certificate costs audit days, every year again, plus the internal time nobody shows on the quote. For the costs of ISO 27001 we have done the maths: the certificate itself is the cheapest part, and operating the system costs a multiple of it. The same logic applies to ISO 42001.
And the customer questions arriving today rarely demand a certificate. They sound more like this: which AI tools do you use? Does our data flow through them? Who checks the results before they reach us? A maintained inventory with a policy answers these questions better than any certificate on the wall, and both cost a fraction.
Hence our sober sequence for an SME that uses AI and does not sell AI: first the inventory, then the policy, then the impact assessment for the sensitive use cases. All anchored in the existing ISMS, checked in the existing audit rhythm. That covers the real risks and answers the customer questions above along the way. You add the certificate when a deal depends on it. The path is short then, because the substance is already in place.
Three questions for your decision
Do you sell AI or do you only use it? Is a customer or a tender demanding the proof, today or foreseeably? Is an ISMS running that you can dock onto?
Answer these three questions honestly and the certificate question is usually already settled. With three times no, an AI policy within the existing framework is the right next step, not a standards project. With one yes, it is worth looking at the time horizon: a certification audit requires a lived system, and lived means months, not weeks. If you only start when the customer's questionnaire is on the table, you negotiate under pressure.
Docking on looks unspectacular. The AI inventory becomes part of your asset register, the AI policy a directive next to the existing ones, the impact assessment a step in your risk process, and the management review gets one more item on the agenda. No new committee, no second auditor. If you are unsure where this should start in your company, an initial conversation clears that up faster than buying the standard.
One question interests us more than all the others, because almost every AI governance discussion hinges on it: do you know today which AI tools are actually in use in your company?
