← All posts

The ISO 42001 Requirement Most Companies Fail — And It's the First One

The ISO 42001 Requirement Most Companies Fail — And It's the First One
TL;DR

ISO 42001 requires AI risk assessment, but most organisations fail at it by treating AI risk like IT risk, assessing the vendor instead of the model, self-assessing without independence, treating it as a one-time activity, and ignoring cumulative risk across multiple AI systems. A proper assessment examines the model's training data, bias testing, explainability, and adapts as the system and regulations change.

Most organisations that start down the ISO 42001 path focus on the parts that feel familiar. Policy documents. Governance committees. Roles and responsibilities. These are comfortable. They look like things the organisation already knows how to do.

Then they hit Clause 6: Planning. Specifically, the requirement to conduct an AI risk assessment. And most of them get it wrong in exactly the same way: they treat it as a documentation exercise rather than an actual risk identification process.

The result is a risk register that looks complete but misses the risks that matter most. An AI system gets deployed with a signed-off assessment that didn't identify the training data bias. A vendor gets approved with a risk rating of "low" because the assessor only looked at the vendor's marketing materials. A model goes into production with a risk assessment that was written by the same team that built the model — and surprise, they didn't find any problems.

This is not a theoretical concern. When we audit AI deployments, the risk assessment is consistently the weakest link. Here is where most organisations go wrong, and how to fix it.

Mistake One: Treating AI Risk Like IT Risk

The most common failure pattern is assessing AI risk through an IT risk framework. The organisation's existing risk matrix has categories like confidentiality, integrity, and availability. The assessor maps AI into those categories and produces a rating. The assessment looks professional. It is also wrong.

IT risk frameworks were designed for systems that behave predictably. An AI model that produces biased outputs is not a confidentiality problem. It is not an integrity problem in the traditional sense — the model is functioning exactly as designed, producing outputs consistent with its training. The problem is that the training data embedded patterns of discrimination, and now the model is reproducing them at scale. An IT risk framework does not catch this because it was not designed to.

ISO 42001 requires AI-specific risk thinking. The standard asks you to consider risks that do not exist in traditional IT: biased outcomes from training data, model drift over time, adversarial inputs that cause unexpected behaviour, and harm caused by decisions the model influences rather than makes directly. If your risk assessment isn't asking these questions, it isn't an AI risk assessment. It's an IT risk assessment with the word "AI" pasted over the top.

Mistake Two: Assessing the Vendor Instead of the Model

Organisations that use third-party AI tools often assess the vendor's business — their financial stability, their reputation, their security certifications — and call that an AI risk assessment. The vendor is solvent and ISO 27001 certified, so the risk must be low.

This misses the point. The vendor's financial stability tells you nothing about whether their model produces biased outcomes. The vendor's security certification tells you nothing about whether their training data was ethically sourced. The vendor's reputation tells you nothing about whether their model's decisions can be explained to a customer or a regulator.

An AI risk assessment under ISO 42001 needs to examine the model itself: what data was it trained on? Has it been tested for bias? Across which demographic dimensions? With what results? How does the model handle edge cases? What happens when the input data changes? Can the model's outputs be explained? These are questions about the AI system, not about the company that built it. A vendor assessment that doesn't answer them is incomplete.

Mistake Three: Self-Assessment Without Independence

The team that builds or procures an AI system should not be the only team that assesses its risk. This is not a criticism of their competence. It is a recognition of a universal human tendency: people who have invested effort in selecting or building a system are poorly positioned to objectively evaluate its risks.

We see this constantly. A procurement team spends six months evaluating AI vendors, selects one, and then writes the risk assessment. They are invested in the decision. They want it to work. The assessment reflects that — risks are minimised, mitigations are assumed to be effective, and the overall rating is lower than an independent assessor would assign.

ISO 42001 does not explicitly require independent risk assessment. But the standard's emphasis on objectivity and competence implies it. If your AI risk assessment was written by the same people who chose the AI, you should assume it understates the risk. Get a second set of eyes. Ideally, get eyes that were not involved in the procurement decision and have no stake in the outcome.

Mistake Four: Treating the Assessment as a One-Time Activity

AI systems change. Models are updated. Training data is refreshed. Deployment contexts evolve. New regulations come into force. A risk assessment conducted at deployment in 2024 is not adequate for the same system running in 2026, after two model updates, a change in training data sources, and the introduction of the Privacy Act amendments.

ISO 42001 requires ongoing risk management, not point-in-time assessment. The standard expects you to monitor, review, and reassess as the system and its context change. Most organisations write the assessment at deployment and never revisit it. This creates a dangerous gap: the assessment says the risk is managed, but the system has changed enough that the original assessment no longer applies.

The practical fix is to tie reassessment to triggers: model updates, training data changes, significant shifts in deployment context, regulatory changes, and incident responses. When any of these occur, the risk assessment is revisited. Not as a project. As a process.

Mistake Five: Ignoring Cumulative Risk

Most organisations assess AI risk one system at a time. The chatbot gets its own assessment. The transcription tool gets its own. The resume screener gets its own. Each assessment concludes the risk is manageable. And individually, they might be right.

The problem is cumulative. An organisation running five AI tools, each assessed as low risk in isolation, may have a cumulative risk profile that is significantly higher than any single assessment suggests. The transcription tool captures meeting content. The document analyser processes that content. The customer sentiment tool analyses the resulting interactions. Individually, each tool's data handling is manageable. Combined, they create a data pipeline that crosses jurisdictional boundaries, involves multiple vendors, and processes personal information in ways no single assessment captured.

ISO 42001 expects organisations to consider the broader AI management system, not just individual AI systems. The standard asks: how do these systems interact? What risks emerge from the combination that don't emerge from any single system? If your risk assessment framework can't answer these questions, it has a gap.

What a Proper AI Risk Assessment Looks Like

A proper assessment under ISO 42001 starts with the AI-specific risks: bias, fairness, explainability, data provenance, model drift, adversarial robustness. It examines the model, not just the vendor. It involves assessors who were not involved in the procurement or development decision. It is revisited when the system or its context changes. It considers cumulative risk across the AI portfolio. And it documents not just the conclusions but the reasoning — so that when a regulator or an auditor asks why a risk was rated low, the answer exists.

The organisations that get this right treat AI risk assessment as a discipline, not a document. They invest in the expertise to do it properly, or they bring in independent assessors who already have it. They understand that a bad risk assessment is worse than no risk assessment, because a signed-off bad assessment creates a false sense of security that lasts until something goes wrong.

The organisations that get it wrong are the ones whose AI incident makes the news, followed by the revelation that their risk register rated the system as low risk. The gap between "low risk" and "front page" is usually an inadequate assessment. Don't let it be yours.

Book a scoping call to discuss independent AI risk assessment against ISO 42001.

Frequently asked questions

What is an AI risk assessment under ISO 42001?

An AI risk assessment under ISO 42001 identifies and evaluates risks specific to AI systems, including biased outcomes, model drift, unexplainable decisions, adversarial inputs, and data provenance issues. It goes beyond traditional IT risk assessment by examining the model's training data, fairness testing, and decision logic.

Why do most companies fail ISO 42001 risk assessment?

The five most common failures are: treating AI risk like IT risk, assessing the vendor instead of the model, self-assessing without independent review, treating the assessment as a one-time activity, and ignoring cumulative risk across multiple AI systems deployed in the same organisation.

Should the same team that buys AI also assess its risk?

No. The team that procured or built the AI system has an inherent conflict of interest. ISO 42001 expects objective risk assessment. An independent assessor who was not involved in the procurement decision will identify risks that the procurement team unconsciously minimised.

How often should an AI risk assessment be updated?

Not just at deployment. Risk assessments should be revisited when the model is updated, training data changes, deployment context shifts, new regulations come into force, or an incident occurs. ISO 42001 requires ongoing risk management, not point-in-time assessment.