Stage 1 is a documentation and readiness review, and it's the part of ISO 42001 you can actually prepare for in advance. Here's what an auditor expects to see on the table before they'll pass you through to Stage 2.
Most ISO 42001 advice aimed at teams running AI jumps to the hard part—proving the system works in production. That matters, and it's a genuinely different problem (more on that at the end). But there's an earlier stage you can prepare for on paper, and getting it right is what keeps your timeline from slipping.
Stage 1 of an ISO 42001 audit is a documentation and readiness review: the auditor checks that your AI management system (AIMS) exists on paper, that its scope is defined, and that the required artifacts are actually written down. Major non-conformities found here have to be remediated before you can move to Stage 2—so a thin package doesn't just cost you a meeting, it resets your schedule. This is a practical checklist for the compliance lead or CISO kicking off certification.
What does ISO 42001 Stage 1 actually check?
TL;DR: This ISO 42001 Stage 1 checklist covers the documentation review: scope, AI policy, the Statement of Applicability, and your risk and impact-assessment methodology. It confirms your AIMS is defined on paper and ready for the Stage 2 operational audit—it doesn't yet test whether the system runs as written.
ISO/IEC 42001:2023 is the first international standard for an AI management system, published in December 2023 and still current. Certification checks your organization against management-system clauses 4 through 10, plus every Annex A control you declare applicable. The audit runs in two stages, and Stage 1 is the documentation and readiness review—it can wrap in a couple of days. Stage 2 is the on-site verification that the system operates in practice.
The point of Stage 1 is to confirm you're ready before anyone audits operations. So the deliverables below aren't box-checking—each is something the auditor reads closely, and each is something a team early in its journey can produce well ahead of time.
How do you define the scope of your AIMS?
Scope is the first thing an auditor looks at because everything else inherits from it. You're defining which AI systems, business units, and processes fall inside the management system, and being explicit about what sits outside.
A smaller, well-argued scope is not cutting corners—it's how mature teams land at the short end of the typical three-to-nine-month timeline. Define the boundary around the AI systems that actually carry risk, document why the boundary sits where it does, and you've saved yourself work in every later step. An over-broad scope pulls in systems you then have to assess, control, and produce evidence for.
What goes in your AI policy and governance structure?
Two of Annex A's nine control objectives are AI policy and internal organization, and Stage 1 is where you show both. The AI policy is a top-level document: your organization's stated commitments and principles for developing and using AI responsibly, endorsed by leadership.
Governance is the other half. The auditor wants to see roles and responsibilities defined—who owns AI risk, who authorizes a system to go into use, who reviews it over time. This doesn't require a new org chart; it requires that accountability for AI decisions is written down and assigned to named roles, not left implicit.
How do you build a Statement of Applicability that survives review?
TL;DR: Annex A holds 38 controls under 9 objectives. Your Statement of Applicability must evaluate all 38 and justify every exclusion in writing. Auditors challenge weak justifications, so "not applicable" needs a reason that survives a follow-up question.
The Statement of Applicability (SoA) is the document Stage 1 leans on hardest, and the one teams most often underbuild. Annex A contains 38 controls grouped under 9 objectives—AI policy, internal organization, resources, impact assessment, AI system life cycle, data, information for interested parties, responsible use, and third-party relationships.
The discipline is simple to state and easy to shortcut: you have to evaluate all 38 controls and justify every exclusion in writing. "Not applicable" is a legitimate answer for some controls, but only with a reason that holds up. Auditors challenge thin justifications, and a control marked out of scope without a defensible rationale is exactly the kind of gap that turns into a Stage 1 finding.
One head start worth naming: Annex A is a smaller control set than ISO 27001's—38 against 93—and many controls overlap. If you already run a mature information-security program, a good number of your SoA entries can lean on that work. The AI-specific controls, with no ISMS analog, are where your SoA needs original thinking.
What does your risk and impact-assessment methodology need to show?
Impact assessment is one of the nine Annex A objectives, and Stage 1 is where its methodology gets reviewed. The distinction that trips teams up: at this stage the auditor is checking your method, not the individual results. They want a documented, repeatable approach to identifying how your AI systems could affect individuals and the organization, and how you rate and treat that risk.
Build the methodology so it's genuinely repeatable, because Stage 2 will test whether you followed it. A method that looks good on paper but was clearly reverse-engineered from a single assessment is easy to spot.
How do you run a gap analysis before Stage 1?
A gap analysis is where the three-to-nine-month timeline gets set. You take the requirements—management-system clauses 4 through 10, plus the Annex A controls you've marked applicable—and check each one against what you actually have documented. Wherever there's a gap, you build the missing artifact before the audit.
Treat it as a dress rehearsal for the Stage 1 review itself. It's far cheaper to find your own missing risk methodology or an under-justified SoA entry than to have the auditor find it and hand it back as a non-conformity you have to remediate before Stage 2 can even begin.
The takeaway
Stage 1 rewards preparation because it's a documentation review—scope, AI policy and governance, a Statement of Applicability that evaluates all 38 controls, and a sound risk methodology, pressure-tested with your own gap analysis. Build those well and Stage 1 becomes the straightforward gate it's meant to be. (Once you pass it, the certificate itself is valid for three years, with annual surveillance audits in between.)
Then comes the harder question: can you show what your AI systems—and the agents operating your infrastructure—actually did in production? That's what Stage 2 verifies, and no document can answer it. The runtime controls behind it are the subject of a companion piece on Stage 2. Alpacon supplies that runtime slice—operation-and-monitoring records, event logs, and a record of the human-oversight decisions taken at execution time that a policy binder can't produce. It isn't an AIMS and it won't make you certified, and it's only one input to a Stage 2 package, not the whole of it—but it's the input a document can't stand in for.
If you're putting AI agents on production infrastructure, that's worth designing in before your first Stage 2, not after.
