How to run an ISO/IEC 42001 gap assessment
A gap assessment is the first serious step towards ISO/IEC 42001 and determines the cost of everything after it. This walkthrough covers scoping the assessment, working through the clauses and Annex A controls, scoring gaps honestly, and turning the result into a sequenced implementation plan.
By Parminder Kumar Sharma · · 8 min read
At the end of this you will have a completed ISO/IEC 42001 gap assessment: every clause and every Annex A objective recorded in one of three states, each gap carrying an owner and a target date, and the whole thing sequenced into what to do first. It is the document a certification timeline and a budget are built from.
Time. Two to four days of your own work, spread across two or three weeks because you will be waiting on other people. Do not believe an afternoon.
Prerequisites. A copy of the standard, which is not free and cannot be worked around. An AI system inventory, or the willingness to build one as step one. And access to the people who own the systems, because the assessment is mostly interviews.
The shape of it
Four passes, in this order
- What is coveredScope
- The management systemClauses 4 to 10
- Applicability, then implementationAnnex A
- What to do firstSequence
The three states, and why two is not enough
Before starting, decide how you will record findings, because this single choice decides whether the assessment is useful or flattering.
Record every requirement in one of three states
Most gap assessments use two states, present and absent, and most of them overstate readiness as a result. A written procedure that nobody has run is not a control. An auditor does not ask whether a document exists. They ask when it last ran and to see what it produced.
Doing it
Build the AI system inventory
List what the organisation develops, what it buys, and what staff use informally. For each: an owner, what it decides, what data it touches, and whether a person is in the loop.
This step almost always runs long, because a great deal of AI arrives switched on inside software licensed for something else. Ask the finance team for the software spend list and go through it line by line. If your inventory is shorter than that list, it is incomplete rather than clean.
You should see: Somebody outside the project can read the list and cannot name a system that is missing from it.
Fix the scope, in writing
Draw it wider than feels comfortable. Narrowing later is cheap. Widening later reopens work you had marked finished, including clause work that has to be redone against systems you had excluded.
The test for an exclusion is not whether it is convenient. It is whether the excluded system could affect the interested parties you have identified. If it could, excluding it will be challenged.
You should see: You have one paragraph naming what is inside the management system and what is outside, and a reason for each exclusion that you would be willing to say to an auditor.
Work clauses 4 to 10
This is the management system itself: context, leadership, planning, support, operation, performance evaluation and improvement. If you hold ISO 27001, much of this transfers and you are checking that it extends to AI rather than starting from nothing.
Do this as interviews, not as a document review. Ask the owner to show you the thing. The gap between what a policy says and what somebody does is the assessment.
You should see: Every requirement in those clauses has a state, a named owner, and a pointer to where the evidence lives or a note saying there is none.
Assess Annex A applicability before implementation
Nine control objectives, A.2 to A.10. Decide applicability first, because a control assessed for implementation before anybody asked whether it applies wastes the effort either way.
A control that is not applicable still needs a justification an auditor will accept. "We do not do that" is not one. "We do not develop models, we only deploy third-party models, therefore the training data controls do not apply to us" is.
You should see: Every Annex A objective is marked applicable or not, and each exclusion has a written justification.
Assess implementation on the applicable controls
The two that consistently produce the most work are A.5, assessing impacts of AI systems on individuals and society, and A.7, data provenance. A.5 is commonly answered with a relabelled data protection impact assessment, which satisfies neither requirement. A.7 is commonly answered with "we do not know", which is at least honest and is a finding.
You should see: Every applicable control sits in one of the three states, with evidence named for anything marked as operating.
Score against audit outcome, not against percentages
Resist percentage scores. A number like 68% ready is not actionable and it flatters, because it averages a missing impact assessment against a well-written policy.
Ask instead: if a stage 2 audit happened next week, would this raise a nonconformity, and would it be major or minor. That framing translates directly into a readiness view and it forces a judgement rather than a weighting.
You should see: Every gap is marked as would-raise-a-major, would-raise-a-minor, or an observation, and you could defend each of those calls.
Sequence the output
The deliverable is a sequenced plan, not a spreadsheet of red cells. Three groups:
Quick wins, closable inside a month with people you already have. Structural work, meaning the AI policy, the impact assessment process and supplier controls, all of which need design effort. And dependencies, the things that must exist before anything else can operate, which usually means the inventory and the ownership model.
Date the document. A gap assessment loses accuracy within months, and one used to commit to a certification timeline after it has gone stale is worse than none.
You should see: The plan is ordered by dependency and effort rather than by clause number, and the first item can be started on Monday.
What counts as evidence
The word evidence does a lot of work in this exercise, and disagreement about it is the most common reason an assessment turns out to have been optimistic.
Evidence is an artefact produced by the thing happening, not a description of the thing. A policy stating that AI systems are reviewed annually is not evidence that any were. The review record, dated, naming the system and the person, is.
Three tests that settle most arguments. Was it produced as a by-product of the work, rather than written for the assessment. Does it carry a date and a name. And would it exist if nobody had asked. An artefact that fails all three is a description, and it belongs in the middle column.
The awkward consequence is that a young management system cannot have much evidence yet, because evidence accumulates by operating. That is a real finding rather than a failure of the assessment, and it is the single most useful output for planning: it tells you that some gaps close with a document and others close only with time, and no amount of budget compresses the second kind.
This is also why an assessment run immediately before a stage 2 audit is too late to act on. The gaps it finds in the operating history are the ones that needed six months of notice.
Where it goes wrong
The inventory is treated as a formality. It is the foundation, and an incomplete one invalidates everything downstream. If nobody outside the project has reviewed it, it is not finished.
Annex A is assessed before applicability. Work is spent evaluating controls that were never going to apply, and exclusions get written retrospectively to match what was found, which an auditor notices.
The impact assessment gap is recorded as closed because a data protection impact assessment exists. It examines privacy. The AI system impact assessment examines fairness, contestability and what happens to a person when the system is wrong. A relabelled DPIA satisfies neither.
Everything is scored present or absent. See the diagram above. This single choice is the difference between an assessment that predicts an audit and one that surprises you during it.
The assessment is done by the person who built the thing. They know how it is meant to work, which is the wrong knowledge for this exercise. Where an independent assessor is not available, at minimum have somebody else conduct the interviews.
What to do next
The free ISO 42001 readiness assessment on this site scores your position clause by clause with what an assessor expects to see, and orders the gaps by what to fix first rather than by clause number. It is a faster first pass than the exercise above, and nothing you enter leaves your browser.
The ISO 42001 guide covers what the standard requires and where it differs from ISO 27001, including the impact assessment trap in more detail. The EU AI Act guide covers the law this evidence will also serve, and is clear that the certificate discharges no legal obligation.
