ISO 42001 Gap Analysis: Method, Scoring and the Report a Lead Implementer Delivers

An ISO 42001 gap analysis is a structured comparison of how an organization governs AI today against every ISO/IEC 42001 requirement and the controls in its Annex A. The output is a scored register of gaps, each backed by an evidence note, and a report that sets the order of the implementation work. A Lead Implementer usually runs it once the AIMS scope is agreed and before anyone builds a control.

No certificate comes out of a gap analysis. Only a certification body can certify an AIMS (AI management system), normally one accredited for ISO/IEC 42001, and only after a two-stage initial audit. The gap analysis is the organization’s own baseline. For an outside Lead Implementer it is usually the opening deliverable of an engagement, because every later phase depends on what it finds.

Gap analysis, gap assessment and readiness assessment

Gap analysis, gap assessment, readiness assessment and current-state assessment are four names practitioners use for overlapping ISO 42001 work. Consultants, certification bodies and forum posters swap them freely, so ask what the deliverable is before you compare quotes. ISO/IEC 42001 defines none of the four, so the usage notes in the table are GAICC editorial analysis.

Term	How it is usually used	Typical output
Gap analysis	A requirement-by-requirement comparison against ISO/IEC 42001	Scored gap register, report, input to the plan
Gap assessment	The same exercise, under the label some US consultancies and certification bodies use	Same as a gap analysis
Readiness assessment	A later check that audit evidence exists, or a certification body’s pre-audit look at scope and readiness	A go or no-go view of Stage 1
Current-state assessment	A descriptive baseline of AI governance, sometimes run before the organization has chosen a standard	A narrative baseline, often unscored

The general idea is older than any management system standard. Wikipedia’s gap analysis article describes the management-literature sense: comparing actual performance with potential or desired performance. Its sections cover usage gaps and product gaps and say nothing about compliance. In ISO work the “desired performance” is the standard’s text, which makes the comparison testable line by line.

How a gap analysis differs from an audit

A gap analysis differs from an internal audit and a certification audit in purpose, in who may run it and in what it produces. The gap analyst is expected to recommend fixes, while an auditor is not.

Activity	Purpose	Who may run it	Output
Gap analysis	Find and size the gaps, then recommend fixes	Your own team or a consultant	Scored register, report, roadmap input
Internal audit (9.2)	Test at planned intervals whether the AIMS conforms and is effectively implemented	Your staff or an external party acting for you; never your certification body	Audit report and nonconformities
Certification body readiness review	Confirm audit scope and readiness for audit, nothing more	The certification body	Scope confirmation
Stage 1 audit	Review the documented system and readiness for Stage 2	The certification body	Areas of concern
Stage 2 audit	Evaluate implementation, including effectiveness	The certification body	Graded findings, certification recommendation

The certification body row has firm limits. ISO/IEC 42006:2025, the standard for bodies that certify an AIMS, lets a certification body run pre-audit activity only to settle audit scope and readiness (clause 5.2.2). The same clause forbids activity that takes the form of an audit or leads to recommendations. Internal audits renamed as assessments are banned too. A certification body manager put the rule plainly in a March 2026 forum thread: “Obviously if I consult for you you wouldn’t be able to certify with this CB.”

In July 2026 a practitioner in an ISO 27001 forum put one client at “just a gap assessment” stage, too early for an internal audit. The gap analysis comes first, the internal audit tests the built system, and the certification audit follows. Each step needs different people and produces a different record.

Setting the scope of the assessment

The scope of an ISO 42001 gap analysis states which part of the organization, which AI systems and which requirements the assessment will test. Tie it to the AIMS scope under clause 4.3. If top management has not approved that scope yet, assess against a draft and label every result provisional.

A scope can cover part of a company. The standard’s definitions say that “organization” then means only the part inside the scope, and “top management” means the people who direct that part. So a gap analysis of one product line interviews the people who direct that line.

Write the assessment scope down before the first interview. A usable scope record holds these fields:

• Organizational boundary: business units, sites and shared services included, and any left out.
• AI systems: an ID for each system in the sample, with the role the organization plays for it (provider, producer, customer and so on).
• Criteria: ISO/IEC 42001:2023, meaning clauses 4 to 10 plus all of Annex A. Customer or contract requirements can sit in extra columns.
• Evidence period: the months of records the team will sample.
• Limits: systems, teams or records the assessors could not reach.
• People and dates: interviewees, assessors and fieldwork dates.

The criteria line should name the edition. ISO’s catalogue data showed no amendment or new edition of ISO/IEC 42001:2023 on 30 September 2026. CEN approved it as EN ISO/IEC 42001:2026 on 13 March 2026 without modification, so a European customer citing the EN version means the same text.

Roles change the test. Clause 4.1 asks the organization to determine its roles for the AI systems it develops, provides or uses, and those roles shape how far requirements and controls apply. A company that only buys AI tools will score the life cycle controls differently from one that trains its own models. Setting the AIMS boundary is its own task, and the gap analysis should not redraw it on the quiet.

Who should run it

Anyone competent in ISO/IEC 42001 and in the organization’s AI systems can run a gap analysis, because ISO/IEC 42001 never mandates one. Most organizations choose between the internal AIMS lead and an external Lead Implementer. An outside assessor brings fresh eyes and pattern knowledge. An insider knows where the records live.

Two constraints apply either way. Your certification body cannot do the work, because of the ISO/IEC 42006 limits. And the person who designs the fixes should not later audit them, because clause 9.2 expects objective and impartial internal audits. Staff who will run the assessment in-house can prepare through Lead Implementer training for readiness and gap work. The course covers clauses 4 to 10, evidence-based auditing principles and a Stage 1 readiness check.

How long it takes

The standard says nothing about how long a gap analysis should last, and GAICC found no primary source that does. At least one guide that ranks for the query gives a week range with no cited basis (checked 5 October 2026). Four drivers set the real length. They are how many AI systems sit in the sample, interviewee availability, how scattered the records are, and whether other management systems already run.

Collecting evidence from four sources

An ISO 42001 gap analysis draws on four evidence sources: interviews, document review, system walkthroughs and record sampling. Certification auditors use the same kinds. IAS training slides on ISO/IEC 17021-1, from the accreditation body International Accreditation Service, list three audit methods. They are interviews, observation of processes and activities, and review of documentation and records. The same slides call for appropriate sampling. A gap analysis that gathers the same kinds of proof predicts what an auditor will find.

Source	What it shows	AI-specific examples	Limit
Interviews	How people say the work is done, and who decides	System owner on release approval; data lead on training data sources	Claims only; confirm each one elsewhere
Document review	What is written and approved	AI policy, risk method, impact assessment procedure, model documentation	Proves design; operation needs records
System walkthrough	How a process actually runs, observed live	Watching a model release pass its evaluation gate; tracing an AI tool request through procurement	One observation is one instance
Record sampling	Whether the process ran over time	Evaluation logs for recent releases; signed impact assessments; supplier reviews	Small samples can miss patterns

ISO’s guidance on auditing technique, ISO 19011:2026, covers audit principles and how to conduct management system audits. Gap analysts borrow from it even though a gap analysis is not an audit.

An AI document request list

A document request list is the first thing a gap analyst sends, and an AI version needs items an ISMS request never asks for. GAICC built this illustrative list from the standard’s structure; it comes from no client file.

• Draft AIMS scope and any statement of the organization’s AI roles.
• Lists of AI tools from procurement, single sign-on and expense data.
• AI policy, acceptable-use rules and any responsible AI principles.
• Risk methodology, risk criteria and the current risk register.
• Any impact assessments, privacy assessments or algorithmic reviews already done.
• Design records, model cards or system cards for systems the organization builds.
• Evaluation and test results, with the acceptance thresholds used.
• Records of training data sources, lineage and preparation steps.
• Monitoring dashboards, event logs and AI incident records.
• Supplier contracts and the AI terms inside them.
• Training and competence records for people in AI roles.
• Audit reports and review minutes from any management system you already run.

The required records themselves are listed on GAICC’s page of ISO 42001 mandatory documents, which helps you check the request list for missing items.

How much sampling is enough

Sample enough records to tell a habit from a one-off. ISO/IEC 42001 sets no sample size, so treat any number as a team choice and record it in the method. As a working rule, take at least one record per in-scope system for each control you plan to score above “documented”, and take more for high-impact systems. Spread the sample across the whole evidence period, including its older months.

A scoring scale that holds up

A scoring scale for an ISO 42001 gap analysis should separate whether something is written down from whether it runs and leaves records. Many published scales stop at met, partial and absent. That three-step scale hides the difference an auditor cares about most. Stage 2 evaluates implementation, including effectiveness, so a written procedure that never ran is still a gap.

GAICC suggests a five-level conformity scale of its own design. ISO/IEC 42001 contains no such scale.

Score	Label	Test	Typical evidence
0	Absent	Nothing exists for this requirement in scope	None
1	Informal	Done by habit or only planned; nothing approved	Interview statements, drafts
2	Documented	Written and approved, with no proof it has run	Approved policy or procedure
3	Implemented	Ran at least once in scope	One or two dated records
4	Operating	Ran repeatedly over the evidence period, was reviewed, and issues led to action	A sample of records across the period, review minutes

For Annex A controls, add a sixth marker, “applicability provisional”. Use it when the control’s relevance depends on a risk assessment that has not happened yet. A provisional row still gets a score, but the report does not treat it as a required fix.

Why “partially meets” needs evidence notes

A “partially meets” score without an evidence note is a guess that nobody can check. Two assessors will score the same row differently, the owner cannot tell what to fix, and the next assessment cannot measure progress. Every score of 1 to 3 therefore carries a short note with five parts:

• Seen: the record, document or practice examined, with a reference.
• Sample: how many items were checked, from which period.
• Missing: the exact element that stops the next score.
• Source: the interview, walkthrough or file the finding rests on.
• Date: when the evidence was seen, since records change.

Take the note “Policy approved March 2026; no evidence of communication to the data team; 0 of 4 sampled staff aware”. It tells the owner what to do next, which a bare “partial” never does.

Severity is a separate column

Severity measures how much a gap matters at audit, while the maturity score measures how far a process has come. Keep them in separate columns, and treat the mapping in the table as GAICC guidance. A score of 2 on an AI policy may be minor, while a score of 2 on the impact assessment process may block certification.

Gap severity	Typical pattern	Likely audit consequence
High	A required process or record does not exist, or fails across systems	Probable major nonconformity
Medium	A working process has lapses, such as one missed review or an unsigned record	Probable minor nonconformity
Low	Conforms, but could be more efficient or better evidenced	Opportunity for improvement

The “likely” wording matters. Only the certification body grades findings. ISO/IEC 17021-1, as the IAS slides summarize it, requires major nonconformities to be closed before the certification decision. If the body cannot verify the corrections within six months of Stage 2 ending, it must run another Stage 2. High-severity gaps therefore drive the schedule.

Why one readiness percentage misleads

A single readiness percentage averages away the rows that matter most. An organization can score 80% overall with a zero on the impact assessment process, and that zero alone can stop certification. Report scores by clause and by Annex A area, as a heat map, and list every high-severity gap by name.

What to test in clauses 4 to 10

Clauses 4 to 10 of ISO/IEC 42001 have no Statement of Applicability route for leaving a requirement out, so a gap analysis scores every subclause. Your AI roles can change how far a requirement reaches, and every requirement is still assessed. The table gives one test question per clause, plus the trap that most often catches AI teams. Detailed outputs for each subclause sit on GAICC’s page of what the Lead Implementer produces at each clause.

Clause	Gap test question	AI-specific trap
4 Context	Are issues, interested parties, AI roles and the scope recorded and approved?	Roles recorded for the company as a whole, with none per AI system
5 Leadership	Has top management approved an AI policy and assigned AIMS conformity and reporting duties?	An AI principles page with no approval or owner
6 Planning	Do AI risk criteria, risk and impact assessments, treatment, objectives and a change process exist?	Risk criteria copied from security, with no harm-to-people scale
7 Support	Are resources, competence, awareness, communication and document control in place for AI roles?	Competence records that list security roles only
8 Operation	Do the clause 6 processes actually run in operation, including repeat impact assessments?	Impact assessments done once at launch and never revisited
9 Performance evaluation	Is AIMS performance measured, internally audited and reviewed by management?	Audit and review cycles that cover the ISMS and skip AI
10 Improvement	Are nonconformities recorded, causes found and corrections checked?	AI incidents handled as bugs, outside corrective action

Covering the 38 Annex A controls

Annex A of ISO/IEC 42001:2023 groups its 38 controls into nine areas (A.2 to A.10) under ten control objectives, since A.6 has two. Check each control’s wording in your licensed copy. Annex A is normative. Annex B, also normative, gives implementation guidance for each control, which makes it the best reference for what “operating” should look like.

Area	Controls	First question a gap analyst asks
A.2 Policies related to AI	3	Is there an approved AI policy that fits other policies and is reviewed?
A.3 Internal organization	2	Are AI roles defined, and can staff report concerns?
A.4 Resources for AI systems	5	Are data, tooling, compute and people documented for each system?
A.5 Assessing impacts of AI systems	4	Is there an impact assessment process, and are its results kept?
A.6 AI system life cycle	9	Are design, verification, deployment, monitoring and event logs controlled?
A.7 Data for AI systems	5	Are data acquisition, quality, provenance and preparation managed?
A.8 Information for interested parties	4	Do users and others get the information and incident notices they need?
A.9 Use of AI systems	3	Are responsible use processes and intended use defined?
A.10 Third-party and customer relationships	3	Are responsibilities split with suppliers and customers in writing?

Annex A is not a mandatory checklist. A note to the standard’s SoA definition (3.26) says an organization might not require all the listed controls, and might go beyond them. Clause 6.1.3 then decides inclusion from the risk results. So score all 38 rows, but mark relevance as provisional until the risk assessment exists. Treating all 38 as required loads the plan with fixes that the risk results may later cancel. The logic of selecting Annex A controls explains how that later decision works.

Role shapes the likely result. An organization that consumes AI only through suppliers often finds A.10 and A.9 its heaviest work, with narrower life cycle and data rows. One that trains models carries the full weight of the life cycle (A.6) and data (A.7) controls. In both cases a supplier’s own 42001 certificate counts as evidence about the supplier and covers nothing inside your AIMS. Microsoft’s statement on its 42001 offering says each customer must still bring in an assessor for its own organization.

The AI-specific items that need extra fieldwork

Several ISO 42001 requirements have no full equivalent in an information security management system, so a gap analysis should give them extra fieldwork time. These rows often score lowest, and the gaps take longest to close because they need new processes and new records.

Item	What a pass looks like	Usual finding
4.1 AI roles	A role stated for each AI system, used to decide applicability	One company-wide label, or none
6.1.1 AI risk criteria	Approved criteria that address AI risk sources and harm to people	Security criteria reused unchanged
6.1.2 consequences	Risk assessments that weigh consequences for the organization, individuals and societies	Only business impact scored
Impact assessment (6.1.4, repeated under 8.4)	A documented process, results used in 6.1.2, rerun at planned intervals or when significant changes are proposed	A privacy assessment treated as the impact assessment
A.5 impact controls	Process, documentation, individual and societal impact assessed	No assessment records at all
A.6 life cycle	Requirements, verification and validation, deployment and monitoring records per system	Testing exists but acceptance criteria are undocumented
A.7 data	Provenance, quality and preparation recorded for training and evaluation data	Data sources known only to engineers

A popular shortcut treats risk as internal and impact as external. That split does not fit ISO/IEC 42001, because clause 6.1.2 already weighs harm to individuals and societies. Clause 6.1.4 is its own documented process, and the organization must consider its findings in 6.1.2. A gap analyst who sees only a privacy assessment should score 6.1.4 low and say why in the evidence note. GAICC explains how to evidence the impact assessment in its own guide.

Reusing an existing ISO 27001 ISMS

An existing ISO 27001 ISMS (information security management system) shortens an ISO 42001 gap analysis, because several management-system processes can be stretched to cover AI. Both standards follow the harmonized structure ISO uses for management system standards, which is why clause numbers and much of the core text match. The AI-specific content does not.

Usually extendable from the ISMS	Usually new for the AIMS
Document control (7.5)	AI roles for each system (4.1)
Internal audit program (9.2)	AI policy and AI objectives (5.2, 6.2)
Management review routine (9.3)	AI risk criteria that address harm to individuals and societies (6.1.1)
Corrective action process (10.2)	An impact assessment process (6.1.4, repeated under 8.4)
Competence and awareness processes (7.2, 7.3)	Life cycle and data controls (A.6, A.7)
Risk method structure and register format	Responsible use and intended use controls (A.9)
Supplier management process	AI terms in supplier and customer contracts (A.10)
SoA template and sign-off path	Selection and justification against the AI control set

An extendable process still has to show AI records before it conforms. An ISMS internal audit program that has never sampled an AI system scores no higher than 2 for the AIMS row, however mature it is for security. Score each row on AI evidence only, and note the ISMS process as a head start in the effort column.

GAICC found no ISO or accreditation body document that publishes an overlap percentage between the two standards, so a figure quoted online is an estimate. And ISO/IEC 27001 gained its own climate question through a 2024 climate action amendment, so an updated ISMS may already answer the one in clause 4.1. The full integration picture, including one audit for both standards, is on GAICC’s page about what changes when you add ISO 42001 to ISO 27001.

The gap report a Lead Implementer delivers

The gap report turns scores into decisions, and a Lead Implementer usually structures it in eight parts. The order runs from what a sponsor reads first to what an auditor might later ask to see.

1. Executive summary. One page with a heat map by clause and Annex A area, the high-severity gaps by name, decisions the sponsor must make, and no single percentage.
2. Scope and method. The assessment scope record, criteria and edition, evidence period, sample sizes and limits.
3. Scales. The conformity scale and the severity scale, defined exactly as used.
4. Clause scoring table. Every subclause from 4.1 to 10.2 with score, evidence note and severity.
5. Annex A table. All 38 controls with score, evidence note, severity and the provisional applicability marker.
6. Top gaps with effort drivers. The gaps ranked by severity, each with its drivers, owner and dependencies.
7. Roadmap linkage. Each gap mapped to the implementation phase that closes it, with the dependencies between gaps.
8. Appendices. Evidence register, interview log, document list and sampling record.

Close the report with a sign-off line. The sponsor signs to accept the findings, and the fixes are approved later in the plan. That acceptance becomes the baseline the project measures against.

Effort expressed as drivers

Effort estimates in a gap report should name what drives the work and leave person-days until the solution is designed. A number guessed at this stage becomes a commitment the project cannot keep. Express effort as a relative size with its drivers stated, and convert to days only in the project plan.

Driver	Why it changes effort
Build, write or evidence	Designing a process takes longer than documenting a working one, and evidencing an existing process takes least
Systems affected	Each in-scope AI system may need its own assessment or record
Approvals needed	Each signature by top management or designated management adds waiting time
Dependencies	Some gaps cannot close until another closes, such as treatment before the SoA
Evidence period	Records cannot be backdated, so operating evidence needs elapsed time
Third parties	Supplier contract changes depend on the supplier’s response

Illustrative scoring extract

The extract is illustrative. It shows eight rows from a gap register for a fictional 200-person software company with one in-house language model feature and several third-party AI tools. The rows are built from the standard’s structure, and none comes from a client engagement.

Ref	Requirement (paraphrased)	Score	Evidence note	Severity	Effort drivers	Roadmap phase
4.1	Roles toward each AI system	1	Product team calls itself a provider for the support assistant; no role recorded for 3 tools in the SSO list	High	Write; 4 systems; one approval	1 Commit and scope
6.1.1	AI risk criteria	2	ISMS criteria reused; impact scale covers confidentiality, integrity and availability only	High	Build; one approval	4 Risk and impact assessment
6.1.4	Impact assessment process	0	No procedure; privacy assessment for one system seen, dated May 2026	High	Build; 4 systems; evidence period	4 Risk and impact assessment
7.2	Competence for AI roles	2	ISMS competence matrix approved; no AI roles listed; 0 of 3 sampled engineers have records	Medium	Write and evidence; training dependency	6 Operate and evidence
9.2	Internal audit	2	ISMS program operating; scope excludes AI systems; no AI-competent auditor named	Medium	Extend; auditor competence	7 Internal audit and management review
A.6.2.4	Verification and validation	3	Evaluation suite ran for 3 of 3 sampled releases; acceptance thresholds not documented	Medium	Write; one system	6 Operate and evidence
A.7.5	Data provenance (provisional)	1	Engineers can name sources; no provenance record kept	Medium	Build; one system; evidence period	6 Operate and evidence
A.10.3	Suppliers (provisional)	2	Vendor review procedure approved; no AI terms checked in 2 sampled contracts	Medium	Write; supplier response time	5 Controls and SoA

The phase numbers and names follow GAICC’s eight-phase implementation roadmap. The sponsor reads two facts from this extract at once. The impact assessment process does not exist, and all three high-severity gaps sit in context and planning, which must be settled before any control can be justified.

What the results feed next

An ISO 42001 gap analysis feeds three later artifacts: the implementation plan, the inventory of AI systems, and the SoA. Plan each handover as part of the method.

• The plan. Each gap becomes a work package placed in the phase that closes it, ordered by severity and dependency. In the ISO 42001 implementation roadmap, the gap analysis sits in Phase 2 alongside the inventory, and its register is a named exit condition.
• The inventory. Evidence collection usually finds AI tools nobody declared, from expense lines to browser extensions. Log each one, and score inventory completeness itself against clauses 4.1 and 4.3 and the A.4 resource controls. GAICC’s guide to building an AI system inventory covers discovery methods.
• The Statement of Applicability. The provisional Annex A rows become the starting list for clause 6.1.3, and inclusion or exclusion still rests on risk results. The gap scores never move into the record of which controls apply unchanged.

Run a shorter version again before booking the certification audit. That second pass checks the high-severity rows against the evidence Stage 1 will want, which is set out in what Stage 1 checks. The formal test under clause 9.2 is still the internal audit, which the re-run does not replace.

Common gap analysis mistakes

Weak ISO 42001 gap analyses tend to repeat the same few errors. Each one makes the report less useful to the people who have to act on it.

• Scoring Annex A as mandatory. Marking all 38 controls required before the risk assessment produces a plan full of work that may never be needed.
• Stopping at “documented”. A scale without an operating level rates an untested procedure as ready.
• Bare “partial” scores. Without evidence notes, nobody can retest the row or size the fix.
• Documents only. Skipping walkthroughs and samples leaves actual practice untested.
• Using the certification body. It may confirm scope and readiness, but advice from it rules it out as your certifier.
• Treating ISMS records as AI evidence. A security audit that never touched an AI system proves nothing for the AIMS.
• Ignoring bought AI. Third-party tools and AI features inside existing software count when they fall inside the scope.
• Inventing timelines. Week counts guessed before the fixes are designed turn into deadlines nobody can meet.
• Scoring the whole company. Results for units outside the AIMS scope blur the picture for those inside it.

Many of these mistakes trace back to unowned governance. The patterns behind them, and what an auditor writes up when they persist, are covered in GAICC’s guide to how companies fail at AI governance.

Choosing a starting point for your assessment

Where you start an ISO 42001 gap analysis depends on your AI role, your existing management systems and who will act on the report.

• Organizations that consume AI only through vendors: keep the sample to the tools inside the scope, and expect A.9, A.10 and the inventory rows to carry the weight.
• Teams that develop or fine-tune models: sample every in-house system, and plan extra fieldwork for A.6, A.7 and the impact assessment rows.
• ISO 27001 holders: score the shared processes on AI evidence only, then spend the time saved on the AI-specific items.
• SOC 2 holders with no ISO management system: use the SOC 2 control evidence for security-related rows, and expect clauses 4 to 10 to score as new work.
• Small teams: one assessor and a short sample can work, provided the method and limits are written into the report.
• Anyone wanting a quick first read before scoping: GAICC’s free AI Readiness Scorecard asks 20 questions across five pillars. Treat it as a conversation starter; it does not test against the standard.
• Lead Implementers preparing a first engagement: agree the scales and the report structure with the sponsor before fieldwork, so the scores are accepted when they arrive.

Frequently Asked Questions

Is a gap analysis mandatory under ISO 42001?

ISO/IEC 42001 contains no requirement for a gap analysis and never uses the term. Organizations run one to see how far current practice sits from clauses 4 to 10 and Annex A before they plan the work. Whether the standard itself applies to your organization is a separate question, covered in GAICC’s guide to who needs ISO 42001.

How much does an ISO 42001 gap analysis cost?

GAICC gives no price here, because the work grows with the drivers that set its length. Those are the number of AI systems in the sample, interviewee availability, how scattered the records are and whether other management systems already run. Estimates for an outsourced gap assessment sit with the rest of the organization’s budget in GAICC’s ISO 42001 cost breakdown.

Does a supplier’s ISO 42001 certificate close our gaps?

A supplier’s certificate covers the supplier’s own AIMS. It can serve as evidence in your A.10 supplier rows, yet every requirement in your own scope still needs your own evidence and score. Microsoft, for example, tells customers of its certified services that they remain responsible for engaging an assessor to evaluate their own organization.

Is there a free ISO 42001 gap analysis template?

ISO/IEC 42001 contains no gap analysis template, and its full text needs a licensed copy. ISO’s free preview shows the contents, introduction and clauses 1 to 4. A workable register gives every subclause and Annex A control a row with score, evidence note, severity, effort drivers and roadmap phase.

How long does it take to close the gaps a gap analysis finds?

GAICC found no primary source for a remediation period, and ISO/IEC 42001 sets none. Gaps that need a new process, touch many AI systems or wait on approvals and record history close slowest. The roadmap page answers how long ISO 42001 implementation takes as a whole.

How often should an ISO 42001 gap analysis be repeated?

The standard sets no frequency, since it does not require a gap analysis at all. GAICC suggests a short re-run on high-severity rows before the certification audit, and a fresh one after a scope change or new AI system. Between those points, the formal checks are internal audits at planned intervals (9.2) and management reviews (9.3).