A customer security questionnaire used to stop at ISO 27001. Now it often adds a section on artificial intelligence: which AI systems the product uses, where the models come from, how outputs are checked and who is accountable when something goes wrong. ISO/IEC 42001, published in December 2023, is the international standard written to answer those questions as a management system that an accredited body can certify.
For a company that already holds ISO 27001, the good news is structural. Both standards follow the same management system architecture, so much of what you built for your ISMS carries over. The work that remains is specific to AI, and it is easier to plan once you know exactly where it sits.
What ISO 42001 is and how it relates to ISO 27001
ISO/IEC 42001:2023 specifies requirements for an artificial intelligence management system (AIMS): the policies, roles, processes and controls an organisation uses to develop, provide or use AI systems responsibly. Like ISO 27001, it is voluntary. No law requires it, but customers, investors and procurement teams increasingly ask for evidence of AI governance, and a certificate from an accredited body is a recognised way to provide it.
The clauses both standards share
Both standards use ISO's harmonised structure for management systems. Clauses 4 to 10 cover the same ground in both: context of the organisation, leadership, planning, support, operation, performance evaluation and improvement. If your ISMS works, you already run a risk methodology, internal audits, management reviews and a corrective action process. Those mechanisms extend to the AIMS rather than being rebuilt. We explain why those clauses, rather than a set of policies, are the real management system in ISMS vs security policies.
The difference inside the clauses is the subject matter. Where ISO 27001 asks about information security risks, ISO 42001 asks about the risks that arise from AI systems and about their impact on people. Clause 6.1.4 adds a requirement that ISO 27001 does not have at all: the AI system impact assessment, which is then carried out under clause 8.4.
Annex A: 38 controls in nine objectives
ISO 27001:2022 lists 93 controls in its Annex A. ISO 42001 has its own Annex A, with 38 controls grouped under nine objectives numbered A.2 to A.10. They cover AI policy, internal organisation, resources, impact assessment, the AI system lifecycle, data, information for interested parties, responsible use, and relationships with third parties and customers. Annex B gives implementation guidance for each one.
As with ISO 27001, the controls are not applied wholesale. You select them on the basis of your AI risk assessment and impact assessment, and justify each inclusion and exclusion in a Statement of Applicability. That justification matters more than it does in ISO 27001, as the next sections show.
First step: classify your role under ISO 42001 and the EU AI Act
Before any document is written, you need to know what role your organisation plays with respect to each AI system. Both ISO 42001 and the EU AI Act depend on it, and they use different vocabulary for related ideas.
Roles in ISO 42001
ISO 42001 draws its roles from ISO/IEC 22989, the standard for AI concepts and terminology. The ones most companies need are the AI provider, which makes an AI product or service available to others; the AI producer, which designs, develops or adapts AI systems; and the AI customer, which uses an AI system, including one built by someone else. Other roles exist, such as AI partner and AI subject, but these three cover most situations.
Roles in the EU AI Act
Regulation (EU) 2024/1689, the EU AI Act, concentrates obligations on two operators. The provider develops an AI system, or has one developed, and places it on the market under its own name. The deployer uses an AI system under its own authority in a professional context. Importers and distributors have obligations too, but most companies reading this will be one or both of the first two.
Why most companies hold more than one role
The roles are not exclusive. Take a software company that adds an assistant to its product using a model from a third party through an API. It writes the prompts, the retrieval layer and the integration, so it develops and adapts the system: a producer under ISO 42001. It offers the feature to its customers: a provider in both frameworks. It also consumes a model and an embedding service built by someone else, and probably uses AI tools internally: a customer under ISO 42001 and a deployer under the AI Act.
Settling this at the start shapes everything that follows. A company that only consumes third party AI has a lighter set of obligations than one that builds and sells it. Where your suppliers already publish their own ISO 42001 certificates, AI Act statements or impact assessments, you can rely on that evidence and record the responsibility as theirs, which is what the third party controls in Annex A expect.
The AI system impact assessment: the requirement ISO 27001 does not have
The impact assessment is where ISO 42001 departs most from information security. A risk assessment asks what could go wrong for the organisation. An impact assessment asks who could be affected by the AI system, and how: individuals, groups and society. It sits closer to ethics than to security, and auditors treat it as the foundation for the rest of the AIMS. Do it early, once you have documented what each AI system does, because the policy, the procedures, the risk register and the Statement of Applicability all draw on it.
Intended use and reasonably foreseeable misuse
For each system, describe what it was built for and how it should be used. Then describe the misuse that is most likely in practice. A compliance assistant built to answer questions about security controls can also be asked for a cake recipe. The impact of that misuse is close to zero: a few wasted tokens and a little more energy. A system that screens job applicants, misused or simply wrong, could harm someone's livelihood. The assessment is not measured in pages. It is measured in whether you have thought through intended use, likely misuse and the consequences of each.
Recording the AI Act risk tier in the same document
The AI Act sorts systems into four broad tiers, and the impact assessment is the natural place to record which one each system falls into.
- Prohibited practices, under Article 5, have been banned since 2 February 2025. They include social scoring, manipulative techniques that cause harm, untargeted scraping of facial images, and emotion recognition in workplaces and schools.
- High risk systems include those listed in Annex III: biometrics, critical infrastructure, education, employment, access to essential services such as credit, and law enforcement, among others. Following the Digital Omnibus on AI, Regulation (EU) 2026/1744, their obligations apply from 2 December 2027, and from 2 August 2028 for AI embedded in products regulated under Annex I.
- Systems with transparency obligations under Article 50, often described as limited risk, such as chatbots, which must tell people they are interacting with AI. These obligations have applied since 2 August 2026.
- Minimal risk systems, which carry no specific AI Act obligations.
Most AI features in software sold to other businesses sit in the last two tiers: their users are other companies, or individuals who have accepted terms of service, and they do not make decisions about people in the areas Annex III lists. Recording that reasoning in the impact assessment does two jobs. It gives the ISO 42001 auditor a justified basis for applying controls at a proportionate depth, and it gives you the material for a statement of AI Act compliance when a customer asks for one. For a first view of where a system sits, our EU AI Act Checker walks through the questions.
Feeding impact scenarios into the risk register
The impact assessment produces scenarios. The most likely and most severe ones belong in the risk register, with threats, vulnerabilities and assets specific to AI alongside your existing information security risks. Scenarios that are both improbable and low impact can stay documented in the assessment without becoming risks.
Some risks cannot be removed, only reduced with a safeguard. A team that writes much of its code with an AI assistant cannot eliminate the chance of a flawed output, but it can have a second, different model review the first, and keep a human approval step before anything is merged or deployed. Human oversight is the safeguard auditors look for most often, because removing it raises both the potential impact and the likelihood of harm.
Data: provenance, quality and avoiding a black box
ISO 42001 is demanding about data, through the controls under objective A.7. You need to be able to describe the whole lifecycle of the data your AI systems use.
Where the data comes from
Start with provenance and acquisition. Is the data collected from your own users, licensed, or gathered from public websites? Are the sources legitimate and reliable, and was the data obtained in a way you could defend? Scraping content you have no right to use is a legal problem and an ethical one, and the auditor will ask.
Whether the data is fit for purpose
Legitimate data is not necessarily usable data. Consider a system that drafts compliance documents from transcripts of interviews with customers. The transcripts are genuine, but where a customer answered "I don't know" or "we don't do that" to most questions, the model has little it can use. Quality means fit for the purpose you are giving the system, which includes how current the data is and whether the transformations you apply to it make sense.
Quality gates on output and human review
The same discipline applies to what comes out. A practical pattern is to have the system score its own confidence and hold anything below a set threshold for review, so that a draft only reaches a customer after a person has checked it. Whatever the mechanism, measure it: inputs, transformations and outputs should all produce metrics you can show. One of the hardest parts of ISO 42001 in practice is putting that monitoring in place, so that the system is not a black box where something goes in, something comes out and nobody can explain what happened in between.
Transparency: what you tell customers and users
Transparency in ISO 42001 has two layers, and both are simpler than they sound.
The first concerns customers and other interested parties. They should know your policy on AI and where your product uses it. The practical place for this is your terms and conditions and your contracts, which inform customers without publishing every detail of how the product works.
The second concerns the people who use the system. They should be told when they are interacting with AI or receiving output generated by it. The familiar notice at the interface, saying that the user is talking to an AI that can make mistakes and that outputs should be checked, covers it. For chatbots and similar systems, Article 50 of the AI Act now makes this a legal obligation as well.
AI incidents inside your existing incident process
Incident management under ISO 42001 looks much like it does under ISO 27001, with one addition: the auditor will expect scenarios specific to AI. Your playbooks for ransomware, phishing and data breaches are not enough on their own. You also need to show how you would respond to data poisoning, where someone feeds bad data into the sources your system learns or retrieves from, and to prompt injection, where a user crafts input designed to bypass the system's guardrails.
You do not need a separate process. Extend the documents you already have: the incident management policy, the response plan and the information security policy should state that AI incidents are reported through the same channel, such as your security reporting address. Make that channel available to third parties too, so that a customer or researcher who notices unusual behaviour from your AI knows where to report it.
Implementation order for a company that already holds ISO 27001
A sequence that works in practice:
- Discovery. Collect what already exists about your AI systems: what they do, which models they use, and whether those models are consumed through a third party API or hosted on your own infrastructure.
- Role classification. Decide your ISO 42001 and AI Act roles for each system.
- Inventory. Record every AI system with its models, tools, programming languages, suppliers and the infrastructure it runs on.
- Impact assessment. Assess each system, including its AI Act risk tier.
- AI risks. Add the resulting scenarios to the risk register and decide their treatment.
- Lifecycle procedures. Document how data is acquired and prepared, how systems are designed and developed, and how they are used. For a small system this can be one document; for a larger one, separate procedures are clearer.
- Statement of Applicability. Justify each Annex A control, especially exclusions and the depth at which you apply each control. Without a clear justification, an auditor may ask for more than a small system warrants.
- User guides. Write guidance for technical users, drawing on the development procedures, and for people without a technical background, such as sales and customer teams, plus external users through your help centre or terms.
- One integrated management system. Integrate the AIMS with the ISMS rather than running them side by side. Incident management, secure development, risk, communication and internal audit can then rest on what ISO 27001 already established. The same logic lets ISO 27001 and ENS run as a single programme.
Can you certify ISO 42001 without ISO 27001?
Yes. ISO 42001 is a standalone standard and does not require ISO 27001 as a prerequisite. In practice, though, the absence of an ISMS shows up quickly. ISO 42001 does not ask for antivirus on laptops or a specific cloud configuration, but you will still tell the auditor that your AI data is protected, and the auditor will ask how. If access to your cloud infrastructure is not restricted, privileges are not segmented by role and disks are not encrypted, that claim is hard to support.
A company without ISO 27001 can certify ISO 42001, but it will end up doing a meaningful part of the security work anyway to justify its answers. ISO 42001 concentrates on ethics, transparency, governance and impact; it leaves information security largely to the controls an ISMS would provide.
How Qalea supports ISO 42001
Qalea's platform manages ISO 42001 alongside ISO 27001, ENS, SOC 2, NIS2 and DORA in one system, reusing controls and evidence across frameworks, so the AIMS builds on the ISMS you already run instead of starting a second project. The AI inventory, impact assessments, risk register, Statement of Applicability and lifecycle procedures live in the same place as your existing documentation, and evidence is collected automatically from the tools you already use.
Qalea's team provides guided support throughout, and a vCISO brings senior judgement to the decisions that most affect the audit: classifying roles, setting the depth of each control and writing the justifications in the Statement of Applicability. Underneath, Qalea operates the security layer that supports what ISO 42001 assumes about your data and infrastructure, including monitoring, endpoint protection and vulnerability management. For the difference between documenting controls and operating them, see what a compliance platform does not do.
Qalea gets organisations ready for the audit and keeps the management system running between audits. The certificate itself is issued by an accredited certification body.
