Does ISO 27001 cover AI, or do you need ISO 42001?

ISO 42001 is the international standard for AI management systems. It gives organizations that develop, provide, or use artificial intelligence a structured set of governance controls, and it was written to sit alongside existing management systems such as ISO 27001.

That design choice matters, because the question already-certified teams ask most often is not "what is ISO 42001". It is "do we need it yet?" AI is just another technology that needs proper guardrails, governance and a proper way of implementing it, especially when it touches sensitive data. Most of those guardrails already live inside your ISMS.

This guide draws the line between internal AI use, where existing ISO 27001 controls usually do the job, and AI inside the product you sell, where ISO 42001 starts to earn its keep. Along the way: what auditors are asking right now, how shadow AI turns into a finding, and where the EU AI Act timeline actually bites.

How far do existing ISO 27001 controls stretch over AI?

Far enough for most companies. If your teams use AI for drafting, summarizing, coding assistance, and support triage, the controls you already operate cover the ground: supplier management, risk assessment, usage policy, data classification, access control, and logging. You are rarely missing a framework. You are usually missing entries in registers you already maintain.

The adoption numbers explain why this surfaced so quickly. Microsoft and LinkedIn reported that 75% of knowledge workers were using AI at work in 2024, and 46% of those users had started within the previous six months (Microsoft and LinkedIn). On the company side, Eurostat recorded that 20.0% of EU enterprises with 10 or more employees used AI technologies in 2025, up from 13.5% in 2024 (Eurostat). In many organizations, AI usage ran ahead of governance.

How AI tools fit into your vendor register

An AI provider is a supplier. Treat it exactly as you treat your cloud host or your HR system: due diligence before onboarding, a signed data processing agreement, a documented owner, and a review cadence.

The first question to answer is architectural. Are you consuming a third-party model through an API, running an open-weight model yourself, or building something new? Each answer changes the control set. For API consumption, the due diligence questions that carry weight at audit are narrow and practical:

• Does the provider train on your inputs by default, and have you switched that off in writing?

• Where is the processing region, and which subprocessors sit behind the endpoint?

• How long are prompts and outputs retained, and can retention be shortened?

• What security attestations does the provider hold, and are they current?

• Who inside your company owns the relationship and the renewal?

Self-hosted models remove the data-transfer question and add infrastructure, patching, and model-integrity questions instead. Neither path is lighter. They are just different rows in the same register.

Risk assessment for AI: what changes, what stays the same

The methodology does not change. You identify the asset, the threat, the vulnerability, the impact, and the treatment, exactly as you do for everything else. What changes is the nature of two variables: data exposure and output reliability.

Data exposure is familiar territory. Confidential information leaving your boundary into a third-party service is a scenario your register already models. Output reliability is newer. A model that produces plausible but wrong results, and that can change its answer between two runs on the same input, introduces an integrity risk your legacy entries never had to describe. The article on how ISO 27001 protects against faulty AI goes deeper on that failure mode.

Auditors have noticed the gap. Auditors increasingly expect AI to appear in the risk register. The absence itself is now a signal that the risk assessment has not kept pace with how the business runs.

Data classification when employees use AI

Your classification scheme already defines what counts as confidential, internal, and public. The work is extending it to prompts and outputs, which most policies never anticipated.

Write the mapping explicitly: which classification levels may enter which tools. Public and internal content into the licensed general-purpose assistant. Customer data only into tools covered by a DPA with training disabled. Special category personal data and production credentials into nothing, ever. That last line is the one employees remember.

Outputs deserve a sentence too. If a model summarizes a confidential document, the summary inherits the classification of the source. Teams forget this constantly, then paste the summary into a shared channel. Since an ISMS already supports GDPR compliance through ISO 27001, extending classification to AI inputs and outputs also closes a privacy gap at the same time.

What do ISO 27001 auditors check about AI right now?

Four things, consistently: which AI tools are actually in use, whether those tools appear in the vendor register and risk assessment, what data flows into them, and whether a usage policy exists that employees can describe without reading it off a screen.

None of that is new control territory. It is the same evidence trail auditors have always followed, applied to a technology category that arrived faster than the annual review cycle.

Supplier register and risk assessment evidence

A policy statement saying "AI tools are assessed before use" satisfies nobody. Auditors want the artifacts behind it: the completed assessment for each tool, dated, with an owner's name on it, and a link to the corresponding risk entry and treatment decision.

The common finding in Stage 2 is not a missing assessment. It is a mismatch. The register lists three AI vendors, the SSO logs show seven, and nobody can explain the other four. That inconsistency between documented reality and operational reality is what generates the nonconformity, not the AI itself.

Practical fix before your next surveillance audit: pull the list of OAuth-connected applications from your identity provider, cross-check it against the vendor register, and close the delta. It takes an afternoon and removes one of the easiest findings an auditor can write.

AI usage policy: what auditors expect to see

A usable usage policy is short and specific. Auditors look for licensed tools only, a named list of what is approved, an explicit ban on pasting customer data into services that train on inputs or publish them, and a clear escalation path when someone wants to use something new.

It does not need to be a standalone document. Folding the rules into the acceptable use policy that employees already sign is often the cleaner route, because it inherits the distribution and acknowledgment workflow you already have evidence for.

Governance maturity is still catching up. KPMG's Board Leadership Center found that 70% of surveyed board members said their companies were developing responsible-use policies for employee AI use, while only 40% said their companies were implementing a recognized AI risk governance framework (KPMG Board Leadership Center). Policy first, structure second, is the pattern across the market.

Shadow AI: how auditors spot untracked tools

Shadow AI is any AI tool employees use without approval or registration. Auditors find it the same way they find any unsanctioned software: SSO and OAuth grant logs, expense reports, browser extension inventories, and interviews where someone mentions a tool that appears in no register.

The scale of the problem is well documented. Research from KPMG International and the University of Melbourne found that 44% of U.S. workers reported using AI tools without proper authorization or in inappropriate ways at work, and 46% said they had uploaded sensitive company information or intellectual property to public AI platforms (KPMG International and the University of Melbourne).

The financial tail is measurable too. IBM and the Ponemon Institute reported that 13% of organizations had breaches involving AI models or applications, with a further 8% unsure whether they had been compromised that way, and that organizations with high levels of shadow AI saw average breach costs USD 670,000 higher than those with low or no shadow AI (IBM and Ponemon Institute). Banning tools outright tends to push usage further underground. Approving a decent set quickly, and making the request path easy, works better.

When does ISO 42001 become relevant?

When AI is part of what you sell, or when a customer asks for the certificate. If your team uses a licensed assistant to draft emails and review code, your ISO 27001 controls already cover the exposure, and adding a second management system buys you very little.

Three categories of AI posture

Sorting yourself into one of three categories is the fastest way to decide what applies:

1. Using AI for productivity. Internal tools, no AI in the product. Almost every company sits here. ISO 27001 controls cover it.

2. Integrating AI into products or services. You ship features built on third-party or fine-tuned models. Secfix sits in this category, as does most B2B SaaS shipping AI features today. Secure development, data handling, and customer transparency obligations tighten here, and ISO 42001 becomes a credible next step.

3. Developing AI technology. You train foundation models or build core AI systems that others deploy. The heaviest control set applies, and regulatory attention arrives first.

The split between internal use and in-product use is the one that decides your roadmap. Everything else follows from it.

Commercial demand versus regulatory mandate

ISO 42001 certification is voluntary. In practice, adoption is commercially driven: a large prospect asks for evidence of AI governance because your product has AI in it, procurement will not move without it, and the certificate becomes the cleanest answer.

That makes timing a go-to-market question rather than a legal one. If nobody in your pipeline has asked, and the EU AI Act does not reach your use case, you are not behind. If two enterprise deals have stalled on an AI governance questionnaire, you have your answer, and the ISO/IEC 42001 framework gives you a recognized vessel for the controls rather than another bespoke questionnaire response.

Building on ISO 27001: shared structure and gap analysis

Both standards follow the Annex SL high-level structure. Context, leadership, planning, support, operation, performance evaluation, and improvement are shared clauses, which means your scope statement, management review cadence, internal audit program, corrective action process, and competence records transfer with light editing.

Companies already certified to ISO 27001 therefore cut the ISO 42001 implementation effort substantially. The genuinely new work concentrates in the AI-specific annex controls: impact assessment on individuals and society, data provenance for training, transparency to users, and defined points where a human in the loop is mandatory.

How do ISO 27001 and ISO 42001 work together?

They integrate rather than stack. ISO 27001 remains the backbone, with 83,016 valid certifications worldwide in 2023 across 165 countries according to the International Organization for Standardization (International Organization for Standardization). ISO 42001 attaches to that backbone and extends it to AI-specific obligations.

Overlapping controls and where they diverge

The overlap is substantial and mostly procedural:

• Risk management methodology, scoring, and treatment workflow

• Supplier assessment and the vendor register

• Internal audit, management review, and nonconformity handling

• Documented information control, competence, and awareness

The divergence is where ISO 42001 pays for itself. It requires an AI system inventory with intended purpose recorded per system, assessment of impacts on individuals and groups, bias and fairness considerations, data provenance for training and fine-tuning, transparency about what the system does, and documented human oversight. None of those have a direct ISO 27001 equivalent, because ISO 27001 protects information rather than governing decisions made about people.

Running an integrated management system

One management system, two scopes. Keep a single risk register with AI risks tagged, one internal audit program covering both standards in the same cycle, one management review agenda with an AI section, and one set of policies where the AI rules live inside the documents employees already acknowledge.

Running parallel systems is the expensive mistake. It doubles the review burden, splits ownership, and produces contradictory documentation that auditors find immediately. Integration also keeps the evidence base shared, which is where most of the time saving sits.

What does the EU AI Act mean for ISO 27001 and ISO 42001 adoption?

The regulation targets high-risk use cases and general-purpose model providers first. Most companies using AI internally for productivity are not in the high-risk categories. One obligation already applies to them, though: since February 2025, the EU AI Act requires companies to ensure sufficient AI literacy among staff who use AI (Article 4). The Act is still reshaping the market, because customers and investors started asking governance questions well ahead of the compliance deadlines.

Privacy programs absorbed the shock first. Cisco reported that 90% of organizations said AI had expanded the scope of their privacy programs, while 23% still lacked a dedicated AI governance committee and only 12% described their governance committees as mature and proactive (Cisco).

Risk classification and which companies are affected first

Work through the Act's risk tiers against your actual use cases before assuming you need anything new. Prohibited practices are narrow. High-risk categories cluster around employment decisions, credit scoring, education, essential services, critical infrastructure, law enforcement, and safety components in regulated products.

A SaaS company using AI to summarize support tickets is not high-risk. A SaaS company whose AI screens job applicants very likely is, and that distinction changes your obligations more than your headcount or revenue does. Transparency obligations for systems interacting with people apply much more broadly, so if users talk to your AI, say so.

How ISO 42001 maps to EU AI Act requirements

ISO 42001 is not a conformity assessment under the Act, and no certificate makes you automatically compliant. It is a structured way to produce much of what the Act expects: a risk management process for AI systems, documented data governance, technical documentation, logging, human oversight arrangements, and transparency toward users.

For companies in or near a high-risk category, implementing the standard now means the governance artifacts exist before the regulatory deadline rather than during a scramble. For everyone else, it is a reasonable way to stay a few steps ahead of the market without over-investing.

What changes when AI is in the product?

Your ISO 27001 Annex A secure development controls tighten, and a set of AI-specific questions appears that pure software development never had to answer. This is the point where the internal-use playbook stops being sufficient.

Secure development lifecycle for AI features

Extend the controls you already operate rather than inventing a parallel process. The additions that auditors and enterprise security reviewers probe most are:

• Training data provenance. Where the data came from, what rights you hold, and whether personal data is present.

• Model and prompt version control. Prompts and model versions are production configuration, so changes need review and a rollback path.

• Adversarial testing. Prompt injection, data exfiltration through outputs, and jailbreak attempts belong in your test plan alongside conventional application security testing.

• Environment separation. Production customer data should not reach development or evaluation environments by default.

Each maps cleanly to existing secure development and change management controls. The evidence is just AI-shaped.

Data handling, retention, and customer transparency

Three questions decide most enterprise security reviews. Does customer data train or fine-tune your models? How long are inputs and outputs retained, and where? What are customers told, and where is it written down?

Answer them in your documentation before a prospect asks. The default answer buyers want is that customer data does not train shared models, retention is bounded and configurable, and processing regions are disclosed. If any of that is not true, say so plainly and explain the controls that compensate.

Public sentiment sets the backdrop. The Information Commissioner's Office found that 52% of people surveyed in the United Kingdom said caution was their dominant feeling about the privacy of their personal information, and 56% reported having experienced a data breach (Information Commissioner's Office). Transparency is cheaper than recovering trust afterward.

Human in the loop and output validation

Define where automated output can act on its own and where a person must approve. Write it down, then show the mechanism that enforces it. A policy sentence with no technical backing does not survive a competent audit.

Auditors have become pointed about this. One recurring example: companies using AI for code review as the decision maker, without a human in the loop. Auditors now ask for a human in the loop wherever AI makes or prepares decisions, and they ask for it every time. The concern is not that the model is unhelpful. It is that it can change its opinion from one run to the next, so a merge gate with no human approval has no stable control behind it.

Good evidence looks like approval records in your pipeline, review queues with named reviewers, confidence thresholds that route edge cases to people, and logs showing overrides actually happen.

Which route to ISO 42001 costs the least if you already hold ISO 27001?

The cheapest route is almost always extending the management system you already run, with the same certification body, on an integrated audit schedule. An existing ISO 27001 certification covers a large part of the management-system work. The remaining cost concentrates in gap analysis, AI-specific policy development, and auditor days.

Gap analysis and implementation scope

Start by mapping ISO 42001 requirements against the artifacts you already hold. Scope, leadership commitment, risk methodology, internal audit, management review, supplier assessment, and competence records usually transfer with edits rather than rewrites.

Then scope narrowly. ISO 42001 applies to the AI systems in your scope statement, not to every tool anyone uses. A single customer-facing AI feature is a defensible first scope, and it is far cheaper than certifying an aspiration. The same budgeting logic that applies to planning an ISO 27001 budget across tools, consultants, and team time carries over: the controllable variables are scope, internal time, and how much documentation you write yourself.

Choosing a certification body and audit structure

Ask three things of any body you approach: whether they are accredited for ISO 42001 and not only ISO 27001, whether they will run a combined or integrated audit alongside your existing surveillance cycle, and how many additional auditor days the AI scope adds.

Integrated audits reduce total days because shared clauses are assessed once. Aligning the ISO 42001 initial certification with an existing surveillance or recertification visit is usually the single biggest lever on cost. Timing matters more than negotiation here.

Where this leaves your compliance roadmap

For most European startups and mid-size companies, the honest answer is that ISO 27001 already covers AI, provided the registers reflect reality. Put every AI tool in the vendor register, add AI risks with real treatments, publish a usage policy people can quote, and define where a human has to approve. That closes the findings auditors are writing today.

ISO 42001 is the next step, not a parallel one, and it belongs on the roadmap when AI is inside your product and the market starts asking. Treat both standards as working tools: one protects information, the other governs decisions, and together they answer the questions your customers are already sending.

Die wichtigsten Erkenntnisse

• Audit your identity provider logs against the vendor register this quarter and register every AI tool you find, before an auditor finds it for you.

• Add at least one AI risk with a documented treatment to your risk register now, because its absence is itself becoming a finding.

• Fold AI rules into the acceptable use policy employees already sign rather than publishing a separate document nobody acknowledges.

• Delay ISO 42001 until AI sits inside your product or a customer asks for the certificate, and let commercial demand set the timing.

• When you do pursue ISO 42001, scope it to your customer-facing AI systems and schedule it as an integrated audit with your existing certification body.

Häufig gestellte Fragen

Is ISO 42001 mandatory?

No. ISO 42001 certification is voluntary everywhere. It is becoming a practical expectation for companies that embed AI in products sold to regulated or enterprise buyers, and the EU AI Act is accelerating that expectation for high-risk use cases and model providers. No law currently requires the certificate itself.

Do I need an AI usage policy for ISO 27001?

In practice, yes. Auditors expect documented rules covering which AI tools are approved, which data classifications may enter them, what is prohibited, and how employees request a new tool. It can live inside your existing acceptable use policy, as long as it is communicated and acknowledged like any other mandatory policy.

What is shadow AI, and why do auditors care?

Shadow AI is employee use of AI tools that are not approved or registered. Auditors care because untracked tools sit outside your risk assessment, your vendor register, and your data classification controls. When logs or expense reports reveal tools your documentation never mentioned, that inconsistency typically becomes a nonconformity.

How does ISO 27001 scope definition change when AI is involved?

AI tools processing in-scope information, and the data flowing into them, belong inside the ISMS scope. Excluding them while employees clearly use them for in-scope work is the gap auditors flag fastest. Scope the tools honestly and manage them, rather than carving them out on paper.

How long does ISO 42001 certification take if you already hold ISO 27001?

Timelines vary with scope and resourcing, but an existing ISMS removes most of the clause-level groundwork. The pacing factors are the gap analysis, writing AI-specific policies and system documentation, running an internal audit and management review covering the new scope, and your certification body's availability.

Does ISO 27001 still matter if we get ISO 42001?

Yes, and ISO 42001 assumes it. The AI standard governs how AI systems are developed and used responsibly; it does not replace information security management. Customers asking for AI governance evidence almost always expect ISO 27001 underneath it, not instead of it.

Which compliance platform covers both ISO 27001 and ISO 42001 in Europe?

Secfix, the compliance automation platform, supports both ISO 27001 and ISO 42001, so shared building blocks such as risk management, supplier management and policies are reused across both standards instead of being duplicated.