ISO 42001 is a management system standard. On paper, that makes implementing it a job for a management systems specialist, the kind of person who has stood up ISO 27001 or ISO 9001 before. That is half right, and the half that is right genuinely matters. But governing AI well also takes something a pure compliance background does not provide on its own: someone who understands how AI systems are actually built. You cannot write a real control for a system you do not understand from the inside.
This is not a knock on management systems consultants. It is an argument about what the discipline needs, and why the best ISO 42001 work usually has two kinds of expertise in the room rather than one.
What a great management systems consultant brings
Start with credit where it is due, because it is substantial. A strong ISO 27001 or ISO 9001 consultant has spent years getting good at something genuinely hard: turning a standard into a working system an organisation will actually run.
They know how to scope a management system so it is proportionate. They know how to write a policy that leadership will sign and mean. They know the rhythm of risk assessment, documented information, internal audit and management review, and how to get an organisation through a certification audit without drama. None of that is busywork, and none of it is easy.
Because ISO 42001 shares the same underlying structure as ISO 27001, all of that machinery carries across. If you already run ISO 27001, a good consultant will move through the leadership, risk and audit scaffolding quickly, and that is a real head start. We have written before about how much of an existing system you can reuse.
Where AI makes it different
Here is the part that a management systems background does not, by itself, cover. ISO 42001 is not a standard about information security or quality. It is a standard about AI, and its controls are about how AI systems behave.
Look at what an AI Management System actually contains: an inventory of your models and tools, an AI risk and impact assessment, controls for data quality and human oversight, and monitoring of how systems behave once they are live. These are not generic governance topics. They are questions about model behaviour, data pipelines, evaluation, drift, and the specific ways an AI system or an agent can fail.
You cannot write a meaningful control for human oversight in practice if you have never seen where an AI system actually needs a human to intervene. You cannot scope a sensible AI system register if you are not sure what counts as a model, a tool, or an agent. The standard tells you a control is required; it does not tell you what a good one looks like for your systems. That judgement comes from having built the things.
The failure mode nobody intends
When an AIMS is written only from the text of the standard, without that building experience, a predictable thing happens. It reads beautifully and does not match reality.
The controls describe a system nobody quite operates. The oversight step assumes an intervention point that is not where the model really fails. The monitoring plan tracks something that is easy to write down rather than the behaviour that actually drifts. Nobody did anything wrong; the document just floats slightly above how the AI genuinely works.
That gap is exactly what an experienced certification auditor is trained to find, and it is what a serious customer’s security team probes in an assurance questionnaire. It also does something quieter and worse: it gives you false confidence. You believe a risk is controlled when the control does not fit the way the system behaves.
What a builder adds
Someone who has built and shipped AI brings the missing half. They know where these systems actually break, because they have watched them break: the eval that looked fine offline and failed on real inputs, the agent that took a plausible but wrong action, the data pipeline that quietly went stale.
That knowledge is what turns a control from theatre into something real. Human oversight gets placed where intervention genuinely matters. Monitoring watches the behaviour that actually moves. Risk assessment reflects the failure modes that actually occur. The result is an AIMS that describes what you really do, which is the only kind worth certifying. It is the same instinct behind governing AI on Databricks: the strongest governance is designed by people who understand the system it governs.
We come at ISO 42001 from that side. We build AI agents and automation and the software around them, so when we write a control, it is grounded in how the system behaves rather than how a template says it should.
A word on who actually certifies you
It is worth clearing up a common confusion, because it changes the question.
A consultant does not certify you. Whoever helps you implement ISO 42001, whether a management systems specialist, a builder, or both, is helping you build and prepare. Certification is a separate step, carried out by an accredited certification body through an independent audit. That independence is the whole point of the certificate.
So the choice in front of you is not who certifies you. It is who is equipped to help you build a management system that will hold up when that independent auditor arrives, and when a customer looks closely afterwards.
The honest answer: you want both
None of this means an ISO 27001 consultant cannot help with ISO 42001. It means the work needs two things at once: the management system craft that turns a standard into a running system, and the building experience that makes the AI-specific controls real. Sometimes those live in one person. More often they live in a small team, and the trap is assuming the first skill set covers the second.
That combination is exactly what we set out to bring: the management system discipline that turns a standard into a running system, and the hands-on experience of building the AI it governs. We work alongside your internal owner, quality team or existing ISO 27001 system, so the engagement is genuinely yours to run afterwards. The one thing worth avoiding is assuming a compliance-only approach will cover the AI-specific half, because that is the whole gap this piece is about.
The short version
ISO 42001 looks like a pure management systems job and is not quite one. The scaffolding carries over from ISO 27001, and a good consultant handles it well. But the controls are about how AI behaves, and you cannot write a real one for a system you have never built. Pair the management system craft with genuine building experience, remember that certification is an independent step on top, and you get an AIMS that describes what you actually do.
That is how we work: implementation led by people who build AI, so your ISO 42001 system is grounded in reality and ready for the audit. If you want to talk it through, get in touch.
Frequently asked questions
Can our existing ISO 27001 consultant just add ISO 42001?
They can add a great deal of it. ISO 42001 shares its management system structure with ISO 27001, so the leadership, risk process, documentation and audit machinery carry over almost wholesale, and a good ISO 27001 consultant will move through that quickly. What that background does not, on its own, provide is the AI-specific substance: controls for model behaviour, data, oversight and monitoring that match how your systems actually work. The strongest outcome usually pairs management system rigour with someone who has built AI.
Does an ISO 42001 consultant certify us?
No, and this is worth being precise about. A consultant helps you implement the management system and get certification-ready. Certification itself is carried out by an accredited certification body through an independent audit, separate from whoever helped you build the system. So the real question is not who certifies you, it is who is equipped to help you build something that will stand up when the auditor arrives.
Do we need someone technical to implement ISO 42001?
It helps a great deal. Many of the standard's controls touch how an AI system behaves in practice: data quality, human oversight, monitoring, and the ways models drift or fail. Someone who has built and run AI can write controls that are real and proportionate to how the system actually works, rather than generic text that reads well but does not fit. You do not need to turn the whole engagement over to engineers, but you do want building experience in the room.
How much of our ISO 27001 work transfers to ISO 42001?
A lot of the machinery does. ISO 42001 uses the same high-level structure as ISO 27001 and ISO 9001, so leadership, risk management, documented information, internal audit and management review largely carry across and get extended to cover AI. What is new is AI-specific: the AI system inventory, the AI risk and impact assessment, and the Annex A controls aimed at how AI is developed and used. If you already run ISO 27001, implementation is meaningfully faster, but it is not just a copy.
What is the risk of a paperwork-only AIMS?
It reads well and does not match reality. Controls written without understanding how the AI actually behaves tend to describe a system nobody quite operates, which is exactly what an experienced auditor, or a serious customer's security team, is trained to notice. Worse, it gives you false confidence: you think a risk is controlled when the control does not fit the way the model or agent really works. A management system is only useful if it describes what you genuinely do.
Building something you need to govern?
Start with a fixed-scope AI Opportunity & Risk Audit.
Meet an Expert