If you run an ISMS under ISO 27001, you have already built the larger part of your AI governance. The word AI simply appears nowhere in the documents.
The question that keeps coming up in ISMS projects sounds different. Do we now need a second management system? Project teams then plan a separate undertaking with its own policy, its own risk register, its own audit. In our experience that is the most expensive route to a result that a handful of entries in existing documents will also deliver.
What integrating AI governance into your ISMS actually means
Integrating AI governance into your ISMS means adding AI services to the procedures your management system already runs: scope, risk assessment, supplier register, access rights, training. No second system appears, and no second set of policies. What is new is a named responsibility that decides whether an AI tool gets approved.
That sounds small. It is small. It only becomes expensive when a company treats the integration as new construction.
The five places where AI touches your ISMS
1. The scope
Most SMEs did not procure their first AI. The vendor switched it on inside a running subscription. Formally your scope statement often covers that use already, because it names the business processes and the IT services the feature now sits in.
The gap is elsewhere. Hardly any company has written down which data flows into which service, and the risk decision later hangs on exactly that detail. If you are revising the scope of your ISMS anyway, that is the moment to add the AI-supported services. The groundwork for it is an AI inventory, and you fill that from the subscription list, the admin consoles and the expense reports, not from a questionnaire.
Separate the tool from the account in the entry. The same service on a company account and on a private account is contractually not the same service, and only the first variant sits inside your scope.
2. The risk assessment
An AI tool rarely brings a new risk chapter. It changes three risks that already sit in your register.
The first is the unintended disclosure of confidential information, in two directions: what employees type in, and what the assistant is allowed to read on its own. The second is excessive permissions. The third is a wrong output that nobody checks before it ends up in a quote or a customer reply.
The third point is often missing entirely from the ISMS risk registers we see. Formally it falls under integrity, so on paper it is covered. Operationally it rarely has an owner, because the question of whether a generated answer is correct appears in no classical security process. One line about it in the register is worth more than a new policy.
One boundary belongs here. If AI-supported processing can create a high risk to the personality or the fundamental rights of the data subject, Article 22 of the Swiss Data Protection Act requires a data protection impact assessment beforehand. That does not apply to the assistant summarising meeting notes. It applies to processing that judges people, in recruitment for example. What such an assessment looks like in an SME is described in our article on the data protection impact assessment.
3. The supplier register
The legal position here is pleasantly clear. Article 9 paragraph 2 of the Data Protection Act states that the controller must in particular satisfy itself that the processor is able to guarantee data security. Satisfy itself, not agree contractually. A signed contract on its own does not meet that.
Paragraph 3 adds that the processor may only pass the processing on to a third party with the prior authorisation of the controller. With AI services that is no theoretical clause, because behind the vendor there is often a model provider and a hosting platform. For your ISMS that means the AI service belongs in the same supplier list as the hoster and the ERP, with the same entry for subprocessors. What to check contractually is covered in our article on the data processing agreement for AI tools.
4. The permissions
An assistant sees what the account it runs under sees. That is the sentence that saves the most work when you read it before approval rather than after.
Access control is an established process in every ISMS. You need nothing new for this, only an occasion to review the rights once. Reviewing means concretely: which file shares, which shared mailboxes and which drives the account running the assistant can reach. That list surprises someone in the room in almost every engagement. Which details carry the approval decision is covered in our article on how deep the review of an AI tool has to go.
5. Training and awareness
An AI course does not solve this. One page is enough, holding three things: which data categories are allowed, which account people work with, and who decides about a new tool. Why that single page beats a twenty-page document is covered in our article on whether you need an AI policy.
One point belongs in a process rather than in training. In its communication of 8 May 2025 the Swiss Federal Data Protection and Information Commissioner states that the Data Protection Act is formulated in a technology-neutral way and is therefore directly applicable to the use of AI-supported data processing. Users have to be transparent about the purpose, the functioning and the data sources of the processing, and data subjects have a statutory right to know whether they are speaking or corresponding with a machine. If a reply assistant is involved in customer service, that disclosure belongs at the point of contact.
Anyone making automated decisions that carry a legal consequence for the person affected must additionally name a natural person who reviews the decision on request (Art. 21 Swiss DPA). What is already binding in Switzerland today and what is still waiting for a consultation draft is covered in our article on AI law in Switzerland.
Where ISO 42001 comes in, and where it does not
ISO/IEC 42001 carries the title "Information technology. Artificial intelligence. Management system" and has been published since the end of 2023. The British Standards Institution describes the standard as aligned to the well-established structure of the other international management system standards, "so users can build on their existing MSS compliance structure". In plain terms: 42001 is built as an extension. Your ISMS supplies exactly the structure the standard sits on.
It does not follow that you need it. The dividing line runs between developing and buying. A company that builds AI features into its own products or sells AI-supported services to customers has a topic that justifies a management system of its own, including its own responsibility for the result at the customer. For buying and using, five extensions in the existing ISMS deliver the same benefit.
We have covered the substantive difference between the two standards in our article on ISO 42001 vs ISO 27001, and the cost blocks in the article on ISO 42001 costs. For most Swiss SMEs the certificate is the smallest item and the one that can wait longest.
The responsibility no document replaces
You can write the five extensions in a few working days. They still come to nothing as long as nobody is named who decides about a new AI tool.
Without that person, one of two things happens in our experience. Either a silent yes: somebody pays for a subscription with their own card and claims it back on expenses, so the tool is in the house and in no register. Or a silent no: the request fizzles out, and the same person then uses the service on a private account, which means on the weaker contractual footing.
A workable ISMS entry therefore holds three details: who decides, on what basis, and when the approval gets reviewed. Tying the review to the contract renewal costs nothing and stops approvals without an expiry date from piling up. Two lines of reasoning in the minutes also give you the evidence an auditor wants to see.
The question is coming your way regardless. An internal audit under ISO 27001 examines processes and not intentions, and AI services appeared regularly in the sampling plans we saw this year. If you settle the responsibility beforehand, you answer the question in two sentences. This is exactly where we start in mandates for AI governance and safe AI adoption, inside the existing management system and not next to it.
The items your ISMS does not need
Vendors like to offer four items in this context, and in our experience none of them carries weight:
- An AI governance platform. The tool manages policies that fit on one page and answers none of the five entries.
- A second risk register for AI. Two registers mean two truths, and when they diverge both lose their credibility.
- The certificate as a first step. It audits a system you have to extend first.
- A vendor questionnaire with forty items. It produces paper and does not answer your own question, namely what access you grant the tool.
What works usually costs no licence. The side effect tends to please the CFO as well: going through the subscription list, we often find in ISMS mandates that AI features included in an existing contract are being paid for a second time separately.
The sentence missing from your scope
Take your scope document and search it for the letters AI. In most companies it is not in there, even though at least one service is in use that falls under it.
That is rarely dangerous. It is a gap between what gets operated and what the management system describes. The gap closes with writing, not with a project.
If you want to know how big it is in your company, talk to us. A first conversation is non-binding.
And one question remains, the one we ask in every ISMS conversation: who in your company would say no if somebody turned up with a new AI tool next week?
Frequently asked questions
Do we need a second management system for AI?
In most Swiss SMEs, no. If you buy and use AI, you extend the existing ISMS in five places: scope, risk assessment, supplier register, access rights and training. A system of its own only pays off once a company builds AI into its own products or sells AI-supported services.
What changes in the ISMS when we use AI?
Five entries. The scope names the AI-supported services and the data flows, the risk assessment adds disclosure, excessive permissions and unchecked output, the supplier register carries the vendor including subprocessors, access rights get reviewed before approval, and one page governs day to day use.
Do we need ISO 42001 if we have ISO 27001?
Not necessarily. ISO/IEC 42001 follows the well-established structure of the other management system standards and is built as an extension rather than a parallel system. For companies that only use AI, the certificate is the smallest item and the one that can wait longest.
