Key takeaways
- ISO 42001 is about governing AI risk and use, while ISO 27001 remains the foundation for information security.
- Most ISO 27001 processes can be reused for AI, but they need updating for model behaviour, supplier dependence, and ongoing oversight.
- Start with an inventory of AI tools, clear ownership, and a simple risk review before trying to formalise everything.
- Customer-facing tools, sensitive data use, and decision-support systems should be prioritised first.
- Certification frameworks help structure control, but they do not replace practical judgement and regular review.
What ISO 42001 is, in plain English
For organisations already working to ISO 27001, the simplest way to think about ISO 42001 is this: it is a management system for AI. It helps you decide how AI should be used, who is responsible for it, what risks need attention, and how to keep oversight as the technology changes.
That matters because AI can create business risk in ways that are different from ordinary software. A system may produce incorrect answers, expose sensitive information, behave unpredictably when given unusual inputs, or rely on a supplier you do not fully control. Those issues can affect customer trust, staff productivity, data protection, and in some cases commercial decisions.
ISO 27001 is still valuable, but it was not written specifically for AI. If you are already using AI tools or considering them, ISO 42001 gives you a structured way to govern that use without starting from scratch.
How it differs from ISO 27001
ISO 27001 is about protecting information. It focuses on keeping data confidential, accurate, and available, and on managing security risks across the business. ISO 42001 is about managing AI systems responsibly. It looks at the full lifecycle of AI use, from deciding whether to adopt a system through to monitoring it in use and retiring it safely.
In practice, ISO 27001 asks, “How do we protect our information and systems?” ISO 42001 asks, “How do we make sure AI is used in a controlled, accountable, and safe way?”
Why it matters for organisations using AI
Many SMEs are already using AI in some form, even if they have not formally approved it. Staff may be using public chat tools to draft emails, summarise documents, or analyse data. Teams may also be using AI features built into existing business software. That can create hidden risk if the business has not set clear rules.
If you already have ISO 27001, you are in a better position than most. You already have a management system, a risk process, and a habit of keeping evidence. ISO 42001 builds on that discipline and helps you apply it to AI specifically.
Why ISO 27001 does not fully cover AI risk
ISO 27001 gives you a strong foundation, but AI introduces issues that are not always covered well by standard information security controls. The problem is not that ISO 27001 is weak. The problem is that AI behaves differently from the systems many organisations are used to.
Where an information security management system helps
Your information security management system, often called an ISMS, already gives you useful structure. It should help you define scope, assign ownership, assess risk, approve suppliers, manage incidents, and review controls regularly. Those habits are directly useful for AI governance.
For example, if you already have a process for approving new software, reviewing suppliers, and recording risks, you can reuse that process for AI tools. You do not need to invent a new way of working for every new system.
Where AI-specific governance is still needed
AI risk is not just about whether a system is secure in the usual sense. It is also about whether the output is reliable, whether the model is being used for the right purpose, whether staff understand its limits, and whether the business can explain and challenge its decisions.
That is especially important where AI influences customer interactions, internal decisions, or the handling of sensitive information. A chatbot that gives a poor answer may not be a security incident in the traditional sense, but it can still damage reputation, create complaints, or lead to bad decisions. A model that uses the wrong data may also create confidentiality or compliance concerns.
For a broader view of how AI security fits into day-to-day business decisions, it can help to read our secure AI development explained for business leaders article alongside this one.
What an ISO 27001 organisation already has in place
If you already hold ISO 27001, you are not starting from zero. In many cases, you already have most of the management habits needed to support ISO 42001. The main task is to adapt them for AI rather than build everything again.
Policies, risk management, and controls you can reuse
Most organisations can reuse existing policies on risk, supplier management, access control, incident handling, change management, and record keeping. These are not AI-specific, but they are still essential. They give you a place to define how AI tools are approved, monitored, and reviewed.
Your existing risk register is also a good starting point. You can add AI-related risks to it, such as inaccurate outputs, data leakage, over-reliance on automated decisions, supplier lock-in, and poor staff use of public tools.
Evidence and governance habits that carry over
One of the biggest advantages of ISO 27001 is that it encourages evidence-based management. That habit transfers well to AI. If you already document decisions, review actions, and track exceptions, you can use the same approach for AI approvals and reviews.
This is also where your internal audit and review routines help. They create a regular rhythm for checking whether the controls you intended to use are actually in place. If you need a refresher on that discipline, our internal audits under ISO 27001 article is a useful companion.
What ISO 42001 adds on top of ISO 27001
ISO 42001 adds structure around AI-specific governance. It does not replace your security management system. Instead, it makes sure AI is managed as a distinct business risk rather than as a generic technology purchase.
AI-specific risk assessment and oversight
With AI, the risk assessment needs to go beyond the usual questions about access, patching, and backups. You also need to ask what the system is meant to do, how reliable it is, what data it uses, where the answers come from, and what happens when it gets things wrong.
That means looking at the business use case, not just the technology. A customer service assistant, an internal document summariser, and a tool that helps with recruitment all carry different risks. They should not be treated as the same thing.
Good oversight also means reviewing AI use after it goes live. A system that looked acceptable during procurement may behave differently once staff start using it heavily or feeding it new types of information.
Roles, responsibilities, and lifecycle controls for AI systems
ISO 42001 places more emphasis on clear ownership. Someone needs to be accountable for each AI use case, even if the tool is provided by a third party. That person should understand the business purpose, the risks, the data involved, and the limits of the system.
Lifecycle controls matter too. You need to know when an AI tool is approved, when it is reviewed, when it is changed, and when it should be withdrawn. That is especially important because AI tools can change quickly, sometimes without much warning from the supplier.
If your organisation develops or customises AI systems, then secure development practices become even more important. Our secure development practices for AI systems article covers that area in more detail.
How to assess whether ISO 42001 is relevant to your business
Not every organisation needs to rush into a formal ISO 42001 programme. For some SMEs, a lighter governance approach may be enough for now. The right answer depends on how much AI you use, how sensitive the data is, and how much business impact the system could have if it fails.
Common triggers such as customer-facing chatbots and internal assistants
ISO 42001 becomes more relevant when AI is doing more than a low-risk productivity task. Common triggers include:
- Customer-facing chatbots that answer product, service, or support questions.
- Internal assistants that can access business documents, emails, or knowledge bases.
- AI tools used to draft customer communications, proposals, or contracts.
- Systems that help make decisions about people, money, or access.
- AI features built into supplier products that your staff use every day.
If the tool can influence what a customer sees, what an employee does, or what data is exposed, it deserves closer attention.
Questions to ask before starting a formal programme
Before you decide how far to go, ask a few practical questions:
- What business problem is the AI solving?
- What data does it use, and is any of it sensitive?
- Who approved the tool, and who owns it day to day?
- What would happen if it gave a wrong answer or exposed information?
- Can we explain how the tool is used and who is responsible for it?
If those questions are hard to answer, that is usually a sign that the organisation needs better governance before it needs more technology.
A practical gap check for ISO 27001 holders
A useful way to approach ISO 42001 is to compare what you already do under ISO 27001 with what AI now requires. That gives you a gap check without creating unnecessary work.
Governance gaps to look for
Start by checking whether you have clear approval for AI use. Many organisations discover that staff are using tools informally, with no written decision about whether that use is acceptable. That is a governance gap, not just a technology issue.
Next, look at ownership. If nobody is responsible for an AI tool, then nobody is checking whether it still meets business needs or whether the supplier has changed something important.
You should also check whether your policies mention AI at all. If they do not, staff may assume that existing rules are enough, even when they are not.
Data, supplier, and model risk gaps to look for
Three areas often need extra attention:
- Data risk, especially where staff may paste confidential information into public tools.
- Supplier risk, especially where the model or service is hosted outside your direct control.
- Model risk, especially where outputs are inaccurate, biased, or difficult to explain.
Supplier assurance is particularly important if the AI service is part of a wider platform. Our secure software procurement requirements for suppliers article is a good reference point for building stronger buying decisions.
How to build on existing ISO 27001 processes
The good news is that you probably do not need a separate bureaucracy for AI. In most SMEs, the best approach is to extend existing processes so they cover AI in a sensible way.
Using your current risk register and policy set
Add AI use cases to the same risk register you already use for other business risks. Record the purpose of the tool, the owner, the data involved, the supplier, and the main concerns. That keeps AI visible alongside other priorities rather than hidden in a separate spreadsheet.
Then update your policies so they say when AI can be used, what must not be entered into public tools, and who can approve new use cases. Keep the language simple. Staff are more likely to follow a short, clear rule than a long policy document.
Adapting change management, incident handling, and supplier review
Your change management process should include AI changes, such as new model versions, new data sources, or new integrations. Those changes can affect output quality and risk, even if the supplier describes them as minor.
Your incident handling process should also include AI-specific events. For example, a model might expose confidential information, give harmful advice, or behave in a way that creates complaints. Those events should be logged, reviewed, and learned from just like any other incident.
Supplier review should ask whether the vendor explains how the system is trained, what data it uses, how updates are managed, and what controls exist for access and logging. If the supplier cannot answer those questions clearly, that is useful information in itself.
Common mistakes organisations make when approaching ISO 42001
Most problems come from treating AI as if it were just another software tool. It is not. It can behave unpredictably, it can be difficult to explain, and it can change over time in ways that are not always obvious to the business.
Treating AI as just another software tool
When organisations treat AI like ordinary software, they often miss the need for ongoing review. A normal application usually behaves in a more predictable way. AI systems may not. They can produce different outputs for similar prompts, and they may be affected by the data they are given in ways that are hard to spot.
That means the control approach needs to include monitoring, review, and clear ownership, not just installation and access control.
Assuming certification is the same as being safe
Another common mistake is assuming that certification, or even a well-written framework, means the organisation is automatically safe. It does not. Standards help you manage risk more consistently, but they do not remove the need for judgement, testing, and regular oversight.
For SMEs, the goal should be practical control, not paperwork for its own sake. If a process does not help you make better decisions about AI use, it probably needs simplifying.
A sensible first-step plan for UK SMEs
If you are already ISO 27001 certified or aligned, the best first step is usually a short, focused review rather than a full programme. Start with the AI tools you already use, then decide how much control each one needs.
Start with inventory, ownership, and use cases
Make a simple list of AI tools and use cases. Include tools used by staff, tools built into existing software, and any systems developed in-house. For each one, note the business purpose, the owner, the data involved, and whether the tool is customer-facing or internal.
That inventory is often the most valuable thing you can create at the start. You cannot govern what you cannot see.
Prioritise the highest-risk AI uses first
Do not try to fix everything at once. Start with the uses that could cause the most business harm if they went wrong. That usually means customer-facing tools, tools that handle sensitive data, and tools that influence decisions.
Once those are under control, you can move on to lower-risk uses such as drafting, summarising, or internal productivity support.
How ISO 42001 fits alongside other AI and security work
ISO 42001 should sit alongside, not above, the rest of your security and supplier work. It is most useful when it helps you connect AI governance to the controls you already run well.
Linking it to supplier assurance and secure development
If your organisation buys AI services, supplier assurance is central. If you build AI features, secure development matters just as much. In both cases, the same basic questions apply: who owns the risk, what data is involved, how is the system tested, and how is it monitored after launch?
That is why many organisations find it helpful to link AI governance with their existing procurement, development, and review processes rather than creating a separate AI-only track.
Keeping it proportionate for smaller organisations
For UK SMEs, proportion is everything. You do not need a large team or a complex framework to make progress. You need clear ownership, a sensible inventory, simple rules, and regular review.
If you already have ISO 27001, you have a strong base to build from. ISO 42001 simply helps you apply that discipline to AI in a more structured way.
When to seek external support
Some organisations can handle the first steps internally. Others benefit from outside support, especially when AI use is growing quickly or when the business is unsure how much control is enough.
If you need help scoping AI governance
External support can be useful if you are not sure which AI tools should be in scope, how to classify the risks, or how to write practical rules that staff will actually follow. That is often the case when AI use has grown informally and the business now needs to bring it under control.
If you want to align AI controls with your existing ISMS
Support can also help if you want to extend your existing ISMS in a way that feels joined up rather than bolted on. The aim should be to reuse what already works, identify the gaps, and keep the effort proportionate to the size of the business.
If you would like a practical conversation about where ISO 42001 fits with your current ISO 27001 work, speak to a consultant.
Frequently asked questions
Do we need ISO 42001 if we already have ISO 27001?
Not always, but ISO 42001 becomes useful if you are using AI in a way that creates meaningful business, data, or reputation risk. ISO 27001 gives you a strong base, but ISO 42001 adds AI-specific governance and oversight.
Can we reuse our ISO 27001 policies and processes for ISO 42001?
Yes, in many cases you can reuse a lot of them. Risk management, supplier review, incident handling, change control, and evidence keeping are all useful starting points, but they need to be adapted for AI-specific risks and responsibilities.


Comments are closed