What an ISO 42001 gap analysis tells you before the audit
A buyer whose customer or contract now asks for ISO 42001 needs to know where they stand before anyone books a certification audit. An ISO 42001 gap analysis compares current AI governance with the requirements in clauses 4 to 10 and the 38 Annex A controls of ISO/IEC 42001:2023. The organization owns the result and decides what to fix, while only an accredited certification body issues the certificate. A gap analysis is a diagnostic, not a certification, and it does not replace the independent audit.
The answer depends on how much AI governance already exists. An organization with a written AI policy, a register of AI systems, named owners and documented impact assessments will find a short list of gaps. One that uses AI tools informally across teams may find that clauses 4 and 5, covering context, leadership and scope, have no foundation yet. Confirm early which AI systems are in scope, who builds, buys or deploys them, and which existing records can be reused. Where ISO/IEC 27001 or the NIST AI RMF work already exists, the analysis should test whether that evidence actually meets the AI-specific wording rather than assuming it does.
The statement of applicability under clause 6.1.3 is where the gap becomes a documented decision. For each Annex A control, the organization must state whether it is necessary and justify including or excluding it. A useful gap analysis produces a draft of this document with three columns: controls already operating with evidence, controls partly in place, and controls with no basis yet. The reader should expect the justification for each exclusion to be examined closely, because an unexplained exclusion is one of the first things an auditor questions. Ask any consultant to show how the draft statement of applicability will be built from the findings.
Which existing work you can reuse: NIST AI RMF, ISO 27001 and impact assessments
Most organizations already hold some AI governance material before they start an ISO 42001 gap analysis. The cards below cover the inputs that usually carry the most weight, what each one can credibly cover, and the gaps that tend to remain open. Treat every reused document as a starting point to test against the clauses and Annex A controls, not as proof of conformity.
NIST AI RMF mapping work
Existing NIST AI RMF records can feed clause 6 risk planning and several Annex A controls. The Microsoft-contributed crosswalk maps AI RMF subcategories to ISO/IEC FDIS 42001 clauses and Annex B guidance, but NIST states that inclusion implies neither endorsement nor full coverage. Check each mapped line against the actual ISO requirement, and confirm which Annex A controls your own statement of applicability needs. Expect gaps in management system elements such as internal audit and management review.
ISO 27001 management system records
ISO/IEC 27001 uses the harmonized structure that ISO/IEC 42001 also applies, so clause numbers and common terms line up. Existing context, leadership, document control, internal audit, management review and corrective action records can often be extended to AI scope rather than rebuilt. What usually stays open is AI-specific content: AI objectives, AI roles, and the AI policy. Confirm that the ISMS scope definition is expanded to include AI systems, not just the general IT estate.
ISO/IEC 23894 risk records
Risk registers, risk criteria and treatment plans built under ISO/IEC 23894:2023 guidance on AI risk management can support the AI risk assessment and risk treatment that clause 6 requires. Check whether the register covers AI-specific risk sources such as model drift, training data issues, and misuse, and whether risk owners are named. The ISO 42001 statement of applicability must still justify each Annex A control, so a risk register alone does not settle which controls apply.
ISO/IEC 42005 impact assessments
Impact assessments prepared under ISO/IEC 42005:2025, published 28 May 2025, can serve as input to the Annex A impact assessment controls. Verify that they consider impacts on individuals, groups and society as separate matters, and that they record the system's intended purpose and foreseeable misuse. Assessments written for a privacy review or a data protection impact assessment often omit societal impacts and the review triggers that ISO 42001 expects.
Existing model and data documentation
Model cards, dataset datasheets, data lineage notes and evaluation reports can support the AI life cycle and data controls in Annex A. Check whether they record versions, approvals, verification and validation results, and the intended use. Documentation written for data scientists often lacks deployment approvals, monitoring plans and event logging, which auditors look for. Ask who maintains each document and whether it is updated when a model changes.
Who can perform the gap analysis, and what each choice gives you
An in-house gap analysis is performed by your own staff, usually a combination of governance, security, privacy, legal and engineering people who already run AI projects. Because the organization owns its controls, this option keeps the knowledge of how AI systems are built and used inside the company, and it produces a working gap register that the owners of each control can maintain afterward. The independence boundary is simple: the team is part of the system it reviews, so its findings need to be challenged by someone outside the team before they are treated as objective.
- Output: a clause-by-clause comparison of clauses 4 to 10 and the Annex A controls, with current state, gaps and owners.
- Strength: staff learn the management system directly and can keep the gap register current.
- Limit: blind spots are common when the same people design and assess the controls.
- Cost driver: staff time pulled from delivery work, which is a recurring cost to plan for.
- Check: whether a named person outside the analysis team reviews the findings before the statement of applicability is drafted.",
An independent consultant or implementation partner performs the analysis as an outside party, typically under a written, fixed scope that defines the systems, business units, AI use cases and Annex A controls covered. The partner prepares the evidence and gap findings, but the organization still owns its controls, its AI policy and its statement of applicability. This option brings experience with the harmonized structure shared with ISO/IEC 27001 and with how assessors read evidence, and it can reuse existing NIST AI RMF or ISO 27001 work where that work is relevant.
- Output: a gap report, a prioritized remediation plan and a draft statement of applicability for the organization to review and adopt.
- Independence: the partner must not later act as the certification body, and it should not sign off that the organization is conformant.
- Scope control: a written scope is the main protection against open-ended effort.
- Cost components: the partner's fee for the agreed scope, plus internal staff time for interviews and sign-off. Ask for both in any quote.
- Check: whether the partner's report separates its recommendations from the organization's own decisions.",
Some certification bodies offer a pre-audit, sometimes called a preliminary audit, before the stage 1 audit. European Accreditation FAQ 48.11 records IAF Technical Committee consensus that a pre-audit before stage 1 is acceptable if impartiality is not compromised, but that a pre-audit between stage 1 and stage 2 is not acceptable, and that a pre-audit cannot be used as the stage 1 audit. A pre-audit gives an early view of readiness, but it is not a conformity finding and it does not replace the formal two-stage process.
- Output: an indication of likely gaps, not a certification decision or a stage 1 report.
- Repeat risk: European Accreditation FAQ 49.2 says repeated preliminary audits to check whether earlier problems were fixed amount to helping develop the system, which threatens impartiality.
- Boundary: the body that later certifies you should not design or fix your system for you.
- Cost and timing: ask the body for its written pre-audit terms, scope and any separate fees before committing.
- Check: whether the body's pre-audit is clearly separated from the stage 1 audit in its contract and reports.
Why a certification body's pre-audit has limits
A certification body's pre-audit cannot replace your gap analysis, because the two answer different questions. A gap analysis is an internal exercise that compares your current AI governance with the clauses 4 to 10 requirements and the controls in your statement of applicability. A pre-audit is run by the body that will later certify you, and the European Accreditation FAQ 48.11 position is that a pre-audit cannot be used as a stage 1 audit. Expect the body to tell you what it observed, not to hand you a remediation plan. Your gap analysis is owned by your organization, and the findings, owners and dates in it should be yours to defend.
Impartiality rules limit what the body can do before your audit. European Accreditation FAQ 49.2 says that repeated preliminary audits, used to check whether earlier problems were fixed, amount to helping develop the management system and threaten impartiality. European Accreditation FAQ 48.11 also records that pre-audits are acceptable between the body and the client only if impartiality is not compromised, and that a pre-audit does not fit between stage 1 and stage 2. A body that designs your AI risk method, writes your impact assessment or fixes your controls would later be auditing its own work. Only the certification body reports on conformity, and it will not certify work it helped build.
Before engaging a certification body, ask it in writing what it will and will not do. Confirm whether it offers a pre-audit, how many are allowed, whether they can be used to check fixes, and whether consulting staff are kept separate from audit staff. Ask whether it will review your gap analysis but not write it, and whether its advice is limited to explaining requirements. Then plan the preparation work separately, with an internal owner or an independent implementation partner, so the certification body remains free to test your system at stage 1 and stage 2.
How the gap analysis moves from scope to remediation plan
The sequence starts by fixing what the management system covers and ends with a prioritized plan that names an owner for every gap. Each step produces a written record that the next step relies on, so the output can be handed to the organization's governance owner and, later, to an independent certification body.
Confirm scope and the AI systems in it
The organization's management sponsor and AI governance lead define which products, internal AI systems, business units, locations and third-party AI services fall inside the AI management system. The output is a written scope statement and a list of in-scope AI systems, each with an accountable owner. The step is done when the sponsor signs off the boundary, because every later judgment depends on it.
Inventory existing AI governance records
The assessor collects what already exists: AI policies, model or system registers, risk assessments, data documentation, approval records, incident logs, supplier contracts, and any work done for ISO/IEC 27001, NIST AI RMF or the EU AI Act. Each record is logged with its owner, version, date and the in-scope system it supports. The output is an evidence register that shows what exists, what is outdated, and what was never written down.
Assess each clause 4 to 10 requirement
The assessor checks the management system requirements in clauses 4 to 10, covering context, leadership, planning, support, operation, performance evaluation and improvement. For each requirement, the assessor compares the evidence register with the wording of the requirement and rates it as met, partly met or not met, with a note on why. The output is a clause-by-clause gap table. Because the standard follows the harmonized structure, existing ISO 27001 clause work often maps directly and should be checked rather than assumed.
Assess each Annex A control with Annex B guidance
For each of the 38 Annex A controls in nine objective areas, the assessor reads the control and the Annex B implementation guidance, then tests whether the organization's practice matches both. The check focuses on whether a control operates for the in-scope AI systems and leaves a record, not only whether a document exists. The output is a control-level gap sheet with the current state, the evidence found, and the shortfall for each control.
Draft the statement of applicability
Under clause 6.1.3, the organization must produce a statement of applicability that lists the Annex A controls it needs and justifies including or excluding each one. The assessor drafts it from the control-level gap sheet, with a written reason for every inclusion and every exclusion tied to the AI systems in scope. The output is a draft statement of applicability that the owner approves. An exclusion without a defensible reason is a common point of challenge at audit, so this document should be reviewed by someone outside the drafting team.
Produce a prioritized remediation plan with owners
Each gap from the clause and control assessments becomes an action with a named owner, a description of the evidence that will close it, and a priority based on risk to the in-scope AI systems and the size of the shortfall. The management sponsor reviews the plan and confirms owners and sequence. The output is a remediation plan that the organization owns and can track. Remediation work, such as writing procedures, running impact assessments or setting up logging, is then carried out by the organization, with any outside partner working to the written scope.
What must be in place before the gap analysis can close
A gap analysis compares what the organization does today against clauses 4 to 10 and the Annex A controls it has chosen to apply. The checks below are the foundations that gap analysis depends on, and a missing foundation usually shows up as a gap in several clauses at once.
A defined AI management system scope
Clause 4 requires the organization to determine the boundaries and applicability of its AI management system. Check that a written scope names the business units, products, AI systems and external services it covers, and that the scope statement matches what staff actually build or use. A gap looks like a scope that names a product line while engineering teams run AI features outside it, or a scope so broad that no one can say which systems it includes.
An AI policy with leadership ownership
The AI policy sets management direction, and it should be approved and signed by someone with authority over the business, not only drafted by the compliance team. Check that the policy is documented, communicated to relevant staff, and linked to the organization's other policies such as security and data protection. A gap looks like a policy that is undated, unapproved, or that no team can point to when making a decision about an AI system.
A named owner for AI governance
Auditors ask who is accountable for the AI management system and who can stop an AI deployment. Check for a named individual, with a documented mandate, time allocated and authority to escalate, and confirm that responsibilities for development, operation and use are assigned separately. A gap looks like shared ownership across product, legal and security with no one responsible for the overall system, or a role that exists only on an org chart.
A complete AI system inventory
Gap analysis cannot judge controls for systems the organization does not know about. Check that the inventory lists every AI system the organization provides or uses, including third-party tools and features embedded in SaaS products, with its owner, purpose, data sources and deployment status. A gap looks like an inventory built from procurement records alone, which misses internally built models and AI features that arrived through vendor updates.
Documented impact assessment and risk records
The risk and impact assessment clauses require the organization to identify AI risks and assess effects on individuals, groups and society, and to record the results. Check that each inventoried system has a dated assessment, that risk treatment decisions are recorded, and that the statement of applicability justifies each Annex A control included or excluded. A gap looks like a generic risk register that is not tied to specific systems, or a statement of applicability with no justifications.
At least one management review or internal audit cycle
Clauses 9 and 10 require performance evaluation, internal audit, management review and improvement. Check for records showing that an internal audit was planned and carried out, that findings were assigned to owners, and that top management reviewed the results and recorded decisions. A gap looks like an internal audit planned but never performed, or minutes that list attendees without any decisions or actions.
What drives the cost and effort of a gap analysis
This table compares the main cost components of an ISO 42001 gap analysis: who is paid, whether the cost is one-time or recurring, and what pushes it up or down. Use it to shape a request for a quote, since costs follow from a written scope rather than a standard price. The main takeaway is that internal staff time is often the largest hidden cost, and the number of AI systems in scope usually matters more than the size of the organization.
| Cost component | Who is paid and for what | One-time or recurring, and what drives it |
|---|---|---|
| Internal staff time | Your own employees: AI owners, legal, privacy, security and engineering staff who supply records and answer questions | One-time for the gap analysis, but recurring as reviews repeat. Grows with the number of AI systems, teams involved and how scattered the records are |
| Consultant or implementation partner fees | The firm paid under a written, fixed scope to review clauses 4 to 10 and Annex A, map gaps and prepare a remediation plan | One-time per engagement. Rises with the number of AI systems, business units, locations and third-party AI suppliers in scope, and falls when existing policies and risk records are mature |
| Tooling and document systems | Software licenses or self-hosted open-source tools used to hold the AI inventory, risk register and evidence trail | Often recurring for hosting and licenses. Lower where existing GRC or ISO 27001 tooling can be reused, higher when a new system is needed |
| Certification body pre-audit fees | The certification body, if you buy a pre-audit before stage 1, paid for an assessment that does not replace stage 1 | One-time per purchase. Depends on the pre-audit scope and the number of sites. Confirm in writing what it covers and what it cannot certify |
| Remediation effort after the gap analysis | Internal teams and any outside help that build missing policies, impact assessments, life cycle records and monitoring | One-time per gap closed. Grows with evidence maturity: organizations with few records usually face more remediation than those with documented AI life cycle processes |
| Third-party AI supplier review | Internal procurement, legal and security staff, plus any consultant time to assess supplier contracts and A.10 obligations | Recurring as suppliers change. Grows with the number of external AI services and models in use |
Questions buyers ask about ISO 42001 gap analysis
Can we do the ISO 42001 gap analysis ourselves?
Yes, in most organizations the first gap analysis is run by the organization's own staff, because they hold the knowledge of how AI systems are built, bought and used. ISO/IEC 42001 is a management system standard, so the work is to compare current AI governance practice against clauses 4 to 10 and the Annex A controls, then record what exists, what is partial and what is missing. Internal staff need a clear method, people who can speak for engineering, data, legal and procurement, and enough time to gather evidence. Outside help is useful when no one internally has run a management system assessment before, or when the team wants an independent view of its own readiness. Either way, the organization owns the conclusions and the decisions that follow from them.
Does a gap analysis guarantee ISO 42001 certification?
No. A gap analysis shows where current practice differs from the requirements, but it cannot promise how an accredited certification body will judge the management system. Certification depends on an independent audit of the operating system, including evidence that the controls have run over time, the statement of applicability is justified and internal audit and management review have actually happened. A gap analysis is a planning input that reduces surprises, and its value depends on how honestly it is scored and how completely the follow-up actions are closed. Ask any provider to show how findings are rated and tracked, not to promise an outcome.
Can we reuse our ISO 27001 work for ISO 42001?
Partly. ISO/IEC 42001 uses the harmonized structure shared with ISO/IEC 27001, so clause numbers, clause titles and common terms line up, which makes policy, document control, internal audit, management review and corrective action processes easier to reuse. The AI-specific parts still need new work, including AI impact assessment, AI system life cycle controls, data provenance for AI, and the third-party and customer responsibilities in Annex A. Your existing risk register and ISO 27001 statement of applicability are useful starting points, but they do not replace an AI-specific statement of applicability under clause 6.1.3. Map the overlap explicitly so reviewers can see which evidence serves both standards.
Is a certification body pre-audit enough to prepare?
A pre-audit can be useful, but it has limits that buyers should understand before paying for one. European Accreditation guidance records that a pre-audit before stage 1 can be acceptable if impartiality is not compromised, but a pre-audit cannot replace stage 1, and a certification body should not repeatedly check whether earlier problems were fixed, because that can count as helping to build the system. A certification body also cannot tell you how to fix a gap without creating a conflict of interest. A readiness assessment by someone independent of the certifier can cover design, consultation and remediation support, while the certification body keeps its audit role. Confirm in writing what the certifier will and will not do before engaging.
What does the gap analysis need from our team?
The work needs people who can describe real practice, not only policy. Typically you need an accountable executive sponsor, a lead who can coordinate the review, and named contributors from engineering or data science, product, procurement, legal or privacy, security and HR or the business unit that uses AI. Each contributor should be able to show how an AI system is approved, monitored and retired, and where records are kept. Plan time for interviews, sampling of real records such as impact assessments and deployment approvals, and a review meeting where findings are agreed. Ask any provider which roles they expect from your side and how many hours they assume, and make those assumptions part of the written scope.
How do we decide the scope of the gap analysis?
Scope starts with the organization's AI footprint: which products or services use AI, which AI systems the organization builds, provides or only uses, and which third parties supply AI components. ISO/IEC 42001 applies to any organization that provides or uses AI-based products or services, so the boundary should follow the business, not the org chart. Decide which business units, product lines, geographies and suppliers are in, and record the exclusions with reasons, because the same logic feeds the later statement of applicability. Cost and effort rise with the number of AI systems, the number of teams involved and how much evidence is missing, so ask a provider to price each in-scope system and unit separately.
How DeployOpen scopes the gap analysis and prepares evidence
DeployOpen is a Chainscore Labs company that plans and implements self-hosted open-source platforms inside the client's own infrastructure. For ISO 42001 gap analysis and readiness assessment, we work from a written scope, prepare the systems and records the management system needs, and hand over documentation your team owns. We do not issue audit reports or certificates.
How we scope
- We agree a written scope that names the AI systems, business units and clauses 4 to 10 under review.
- The scope lists which Annex A controls we will assess, and which records the statement of applicability will need.
- Engagements are fixed-scope, so deliverables and timelines are confirmed in writing before any work starts.
How we build
- We compare current AI governance records against each clause and Annex A control, recording gaps by severity.
- Where NIST AI RMF or ISO/IEC 27001 work already exists, we map reusable records and show what remains uncovered.
- We prepare missing governance artifacts, such as AI policy, impact assessment templates and risk registers, for your review.
How we hand over
- You receive a gap register, remediation plan and draft statement of applicability for your internal sign-off.
- Documentation is delivered in your own repositories and tooling, so your team can maintain it after the engagement.
- We walk your staff through the evidence set and state which items a certification body will still need to test.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the readiness work ends.
- A retainer can cover updating evidence as AI systems change, ahead of the certification body's own audits.
- Ask any provider, including us, to confirm in writing that a certification body's pre-audit is not used as the stage 1 audit.
