ISO 42001 Stage 1: what happens on the day, and what to have ready

The first ISO 42001 audits are landing in Europe. Where certification bodies have accredited schemes, and where organisations have been working through the standard since its December 2023 publication, Stage 1 audits are now happening at a steady pace. The event is structurally similar to ISO 27001 Stage 1 but the content is different, and the areas most organisations under-prepare for are the areas the auditor spends most of the day on.

This piece walks through what an ISO 42001 Stage 1 auditor is actually looking for, what documentation matters most, and where organisations who translated their 27001 discipline directly into 42001 tend to trip. It is the third piece in the Audit Day series.

Key takeaways

• Stage 1 for ISO 42001 is a readiness evaluation of the AI Management System (AIMS), not a rehearsal for Stage 2. The audit body confirms the AIMS is designed, documented, and coherent enough to be audited against.
• The pivotal artefact is the AI system inventory. Auditors spend disproportionate time here because most other 42001 findings ultimately trace back to a weak or incomplete inventory.
• AI Impact Assessment methodology is not a rebadged DPIA. Auditors will ask specifically how the two differ in your process and where they overlap.
• Provider and deployer roles under the EU AI Act are usually referenced in 42001 audits even though not required by the standard. Organisations that cannot articulate their role classification will be asked to.
• Common Stage 1 finding: the ISMS is mature, 42001 documentation is templated from 27001, and the AI-specific elements (impact assessment, human oversight design, data governance for AI) are thin.

What the Stage 1 auditor is actually doing

ISO/IEC 42001:2023 certification, like 27001, follows a two-stage process required by ISO/IEC 17021-1. Stage 1’s formal objectives are the same in shape but different in content:

• Review the documented information required by 42001, including the AIMS scope, the AI policy, the AI risk methodology, the AI Impact Assessment methodology, the AI system inventory, and the Statement of Applicability against 42001 Annex A.
• Evaluate the organisation’s understanding of the AI-specific requirements and the operational context of the AIMS, including provider and deployer role definitions.
• Confirm that internal audit and management review are established and running.
• Identify Areas of Concern that would prevent Stage 2 from proceeding, and agree an action plan.
• Establish the Stage 2 audit plan, including AI system sampling and any specific areas of focus based on the AIMS scope.

The auditor is not testing operational AI risk mitigation at Stage 1. That is Stage 2’s job. What Stage 1 tests is whether the AIMS, as designed, is coherent enough to be audited effectively.

What is specifically different from ISO 27001 Stage 1

Organisations that come to 42001 with a mature 27001 ISMS often mistake the discipline for identical. The management-system shell is genuinely shared. The technical content is not.

AI system inventory replaces the asset register. Every AI system the organisation uses, buys, builds, embeds, or influences must appear, with classification against 42001 Annex A applicability. The inventory is often incomplete on first pass because organisations underestimate how much AI is embedded in tools they already run.

AI Impact Assessment is not DPIA. 42001 requires impact assessment across a broader dimension set than personal data. Where personal data is involved, the AIIA and DPIA integrate. They do not substitute.

Human oversight design is a distinct topic. 42001 Annex A includes controls specifically for human oversight of AI systems. The auditor tests design at Stage 1 (is the oversight defined, allocated, and proportionate to the risk) and effectiveness at Stage 2 (is it actually happening).

Data governance for AI is scoped separately. 27001 covers information security. 42001 adds controls specifically for data used in AI training, tuning, or inference, including provenance, bias assessment, and appropriate use.

Provider versus deployer classification. Not a formal 42001 requirement, but the auditor will almost always ask, particularly for organisations that both build and use AI. The classification aligns with the EU AI Act’s terminology and drives which controls in Annex A are most relevant.

Documentation to have ready

Stage 1 auditors ask for the following, roughly in this order:

• AIMS scope statement (Clause 4.3). Names the AI systems, use cases, and organisational units in and out of scope, with justification. Where the scope is deliberately narrow (for example, only customer-facing AI), the justification matters.
• AI policy (Clause 5.2). Approved by top management, describes the organisation’s position on AI use, development, and risk.
• AI roles and responsibilities (Clause 5.3). Including AI system owner, AI risk owner, and the accountable executive.
• AI system inventory. The pivotal artefact. Complete list of AI systems in scope, with provider or deployer classification, risk categorisation, and applicable Annex A controls.
• AI risk methodology (Clause 6.1). How AI risks are identified, analysed, and evaluated. Distinct from information security risk methodology, though the two can share a common risk framework.
• AI Impact Assessment methodology and at least one worked example (Clause 6.1). The methodology is required. A worked example on a real AI system in scope is what convinces the auditor the methodology is operable.
• Statement of Applicability against 42001 Annex A (Clause 6.1.4). Every Annex A control either applicable (with justification and implementation status) or excluded (with justification).
• AI system lifecycle documentation where the organisation builds AI. Design, data management, testing, deployment, monitoring.
• Human oversight design for higher-risk AI systems. Who reviews, when, on what basis, with what escalation.
• Internal audit programme and reports (Clause 9.2). Referencing 42001 specifically, not only 27001.
• Management review inputs and outputs (Clause 9.3) including AIMS performance.
• Nonconformity and corrective action records (Clause 10.2).

Missing AI system inventory or a thin AIIA methodology at Stage 1 will almost always trigger an Area of Concern. Both are the load-bearing pieces of the AIMS.

The AI system inventory: the pivotal artefact

More Stage 1 findings under 42001 trace back to inventory gaps than to any other single cause.

The reason is that most organisations underestimate what counts as an AI system. Copilot in Microsoft 365. AI features in the CRM. The vendor whose fraud detection uses machine learning. The support tool that summarises tickets. The security tool that uses ML for anomaly detection. Any procured service where the vendor’s marketing mentions AI. Any internally built tool that uses embeddings, classifiers, or LLM APIs.

A defensible AI system inventory captures all of these, with:

• System name and purpose
• Provider (vendor) or deployer classification, or both if the organisation both builds and uses AI
• Risk classification against the EU AI Act’s categories where in scope, or the organisation’s own scheme
• Data types processed (personal, sensitive, none)
• Applicable Annex A controls
• Owner (a named person)
• Last review date

An inventory that has ten entries when the organisation obviously uses more is a signal that the AIMS is not yet in touch with operational reality. The auditor will probe.

AI Impact Assessment methodology

The AIIA is often the second area where organisations who transferred 27001 discipline directly into 42001 come up short. A DPIA template does not satisfy AIIA requirements. A generic risk assessment does not satisfy AIIA requirements.

A defensible AIIA methodology covers, at minimum:

• Which AI systems require an AIIA (usually all systems above a stated threshold of risk or impact)
• When an AIIA is triggered (deployment, material change, periodic review)
• The dimensions assessed: fairness, transparency, accountability, safety, human oversight, environmental impact
• Stakeholder engagement, including affected persons where feasible
• Documented output that names risks, mitigations, and residual risk
• Approval authority for AIIAs
• Integration with DPIA where personal data is involved

The auditor will not usually read every AIIA at Stage 1. They will read the methodology, and they will read one or two worked examples to test whether the methodology has been applied.

Provider versus deployer

The EU AI Act distinguishes providers (who develop or place an AI system on the market) from deployers (who use an AI system). ISO 42001 does not formally require the distinction, but it comes up in almost every 42001 audit because it drives which Annex A controls the auditor considers most relevant.

Organisations that build AI systems for sale carry provider obligations. Organisations that only use third-party AI systems carry deployer obligations. Many organisations do both.

Stage 1 auditors will ask which role the organisation plays, for which systems, and how that classification drives control selection in the Statement of Applicability. Organisations that cannot answer this clearly will be asked to develop the position before Stage 2. Our EU AI Act Article 4 piece covers the related literacy obligations that attach to both roles.

A practical pre-Stage 1 checklist

Two weeks before Stage 1:

• Every mandatory documented information item above exists, is current, and is accessible.
• The AI system inventory has been reviewed with each business function to catch AI systems that central IT does not know about.
• The AIIA methodology exists and has been applied to at least one system in scope, with a documented output.
• Provider and deployer roles are classified for each AI system, and the SoA reflects the classification.
• Human oversight is designed for every AI system where the risk profile warrants it, with named reviewers and defined trigger events.
• At least one internal audit cycle has been completed across the AIMS scope.
• At least one management review has taken place with AIMS performance as an agenda item.
• A named person owns the AIMS as a whole. Not the DPO on the side. Not the CISO by default. A specific senior owner.

If any of the above is not true, address it before Stage 1. Some of it (owner appointment, methodology writing) is fast. Some of it (running the inventory across every function, completing an AIIA worked example) takes weeks.

The Axlio Method at 42001 Stage 1

Stage 1 sits inside the Assure step of the Axlio Method. By this point, Understand (which AI the organisation actually uses and builds), Assess (against 42001 requirements), Prioritise (which AI systems and controls matter most), and Implement (the AIMS itself) should already have happened. Stage 1 is the first independent test of that work.

Where Stage 1 raises significant issues, the response is usually to loop back to Understand or Assess. Organisations that build a compliant-looking AIMS without first understanding the AI systems they actually use tend to fail Stage 1 on inventory grounds.

Closing

ISO 42001 Stage 1 is the audit event where the AIMS gets its first honest external evaluation. Organisations that treated 42001 as an extension of 27001 discover which parts genuinely extend and which parts required fresh thinking. Organisations that did the fresh thinking pass Stage 1 cleanly and move to Stage 2 on schedule.

For support preparing for an ISO 42001 audit, or for a wider ISO 42001, AI Governance, or audit preparation engagement, get in touch. We have run the pre-audit checklist above with a growing number of Irish and UK organisations moving toward 42001 certification, and the pattern of surprises is now familiar enough that most of them are avoidable.