You can pass Stage 1 on paperwork. Stage 2 asks what your AI agents actually did in production—and three Annex A controls decide whether you have the answer.
You can write an AI-use policy that satisfies your ISO 42001 Statement of Applicability and still fail Stage 2. The certificate doesn't turn on what your policy says your AI agents are allowed to do. It turns on whether you can show what they actually did in production, under whose approval, and inside what limits. That's not a documentation problem. It's an execution-control problem—and it's the part of an ISO 42001 audit that a binder can't answer for you.
This is a checklist, but not the usual one. Most ISO 42001 checklists walk you through writing the artifacts. This one flags the small set of Annex A controls where the artifact isn't enough—where the auditor wants operational evidence that your agents were monitored, logged, and kept inside their intended use while they ran.
What does an ISO 42001 audit actually check?
ISO/IEC 42001:2023 is the first international standard for an AI management system (AIMS), published in December 2023 and still current. Certification means an accredited body has checked your organization against management-system clauses 4 through 10, plus every control in Annex A that you declared applicable in your Statement of Applicability. Annex A holds 38 controls grouped under 9 control objectives: AI policy, internal organization, resources, impact assessment, AI system life cycle, data, information for interested parties, responsible use, and third-party relationships.
The audit itself runs in two stages, and the gap between them is where teams get surprised.
- Stage 1 is a documentation and readiness review—scope, AI policy, the Statement of Applicability, your risk and impact-assessment methodology. It can wrap in a couple of days. Major non-conformities found here have to be remediated before Stage 2.
- Stage 2 is on-site verification of how the AIMS operates in practice. The auditor stops reading your policy and starts asking for evidence that you did what it says.
The certificate is valid for three years, with annual surveillance audits in between. Annex A is a much smaller control set than ISO 27001's—38 controls against 93—and many of them overlap, so a mature information-security program is a real head start—but it's a head start, not a pass. The AI-specific controls are the ones with no ISMS analog, and a few of them can only be satisfied by what happens at runtime.
Which Annex A controls can't be satisfied by a document?
TL;DR: Three. A.6.2.6 (operation and monitoring), A.6.2.8 (AI system event logs), and A.9 (use of AI systems—responsible use and human oversight). Each asks for proof of what your agents did in production, not a description of what they should do.
Most of Annex A is genuinely a policy-and-process exercise. You can write your AI policy, define roles, document your impact-assessment method, and produce evidence an auditor can read. Three areas are different, because they describe the system in operation:
A.6.2.6—AI system operation and monitoring. The control asks you to operate and monitor your AI systems in production. For an agent executing on infrastructure, "monitoring" isn't a dashboard screenshot. It's evidence that you can see what the agent is doing as it does it, and that risky operations don't pass unobserved.
A.6.2.8—AI system event logs. Log significant events so actions are traceable. A command log is not this. Traceability means you can answer who acted, when, what they ran, under whose approval, and for what purpose—for a specific agent, on a specific system, after the fact.
A.9—Use of AI systems (responsible use and human oversight). A.9 is Annex A's control group for keeping AI use inside its intended limits and a human in the loop where it matters. In operation, that means an agent can't quietly exceed the scope it was granted, and a person can intervene before a high-risk action completes.
Notice the pattern. Each of these is an assertion about behavior over time, and none of them can be produced by a document written before the fact. This is also the recurring worry practitioners voice: on Hacker News, one skeptic dismissed the certificate as paperwork to "feed ... executives and consultants," the kind of documents that get "stash[ed] ... in a drawer with no one reading it" once audit day passes. Stage 2 exists precisely to test whether that happened.
What's on an ISO 42001 audit checklist for teams running AI agents?
If you operate AI agents on production infrastructure, walk into Stage 2 able to produce these on demand:
- A.6.2.6 evidence → a live record that agent actions are observed and risk-assessed as they run, not reviewed weeks later. Can you show that a high-risk operation was flagged at the moment it was attempted?
- A.6.2.8 evidence → an event log where each entry carries identity, time, command, approval, and declared purpose—and where you can reconstruct one agent's session without stitching together shell history and someone's memory.
- A.9 evidence → proof that each agent operated inside a defined scope, and that a human could hold or stop an action that fell outside it. Intended-use limits you can't enforce aren't limits.
And one discipline that trips people up before they ever reach these three: the Statement of Applicability. You have to evaluate all 38 controls and justify every exclusion in writing. Auditors challenge weak justifications, so "not applicable" needs a reason that survives a follow-up question.
Where does the runtime evidence come from?
TL;DR: From the execution layer, not the policy layer. Alpacon isn't an AIMS and won't make you certified—but it supplies the operational evidence for A.6.2.6, A.6.2.8, and A.9: the runtime slice your audit package needs and a policy document can't produce.
This is the seam Alpacon was built for. Traditional PAM concentrates on gating who gets in. Alpacon adds a decision at the execution boundary—judging what humans and agents actually run once they're in, as it runs—which happens to be the exact part of your ISO 42001 evidence a policy document can't produce.
To be clear about scope first: Alpacon is not an AI management system, and no tool makes you "ISO 42001 certified." What it does is supply the runtime evidence for the three controls above, mapped to how they're actually satisfied:
- A.6.2.6 (operation and monitoring) → every human and agent action runs inside a governed Work Session that's recorded, and agent commands are scored for risk at runtime—assessed as they run, before they reach the host. Where you've turned enforcement on, high-risk operations can be routed to a human approver or denied outright; either way, monitoring is something the auditor can watch work, not a report you assemble afterward.
- A.6.2.8 (event logs) → the audit is context-native. Who acted (a person or an agent, resolved to the exact credential behind the action), when, what ran, why—the purpose declared at session start—and under whose approval, all captured as fields at execution time on one timeline for humans and agents. The trail is read-only—there's no edit path through the product—and records age out on a set retention schedule, not by hand-editing. Making the store itself cryptographically tamper-evident, and forwarding it to your SIEM, are the next steps on the roadmap.
- A.9 (responsible use and human oversight) → session-scoped control defines exactly what an agent may execute, and access is revoked when the session ends, so an agent can't quietly escalate beyond its granted scope. When something crosses the line, approval routes to a human approver who signs off before the action proceeds, and OS-level privileged actions can be gated on explicit human sign-off. That's intended-use limits and human-in-the-loop oversight, in operation.
| Annex A control | What the auditor wants | Runtime evidence that satisfies it |
|---|---|---|
| A.6.2.6—operation and monitoring | Proof you observe agents in production as they act, not weeks later | Recorded Work Sessions with per-command runtime risk scoring on the agent path |
| A.6.2.8—AI system event logs | A traceable log: who acted, when, what ran, under whose approval, and why | Context-native audit fields captured at execution time, on one timeline for humans and agents |
| A.9—use of AI systems | Scope an agent can't quietly exceed, and a human able to intervene | Session-scoped access revoked at session end, with approval routed to a human before a high-risk action proceeds |
Alpacon owns the privileged-access and execution slice of that evidence—the part a policy binder can't produce. It doesn't generate the full ISO 42001 pack or replace your certification body; dropping this slice straight into a GRC tool like Vanta or Drata, and auto-generating framework-mapped evidence, are on the roadmap, scoped to that same privileged-access slice. What you have today is the evidence itself, captured at execution time. We're going through our own SOC 2 audit right now, so I'll be honest: most of an audit is miserable because the evidence gets reconstructed after the fact, under deadline. Capture it when the action runs, and it's just there.
Does ISO 42001 certification make my AI agents EU AI Act compliant?
It's worth separating these, because buyers increasingly conflate them. ISO 42001 certifies that your organization's management system is sound. The EU AI Act regulates products, and layers on conformity assessments, EU database registration, and general-purpose AI obligations that no voluntary standard covers. A certificate is strong evidence of diligence; it is not a compliance shortcut.
The standards landscape is maturing fast, which is why this matters now. ISO/IEC 42006:2025, published in mid-2025, set the requirements for the bodies that certify AIMS, so accredited certificates are finally appearing. And the in-development European standard prEN 18286—a distinct product-conformity standard, not ISO 42001 repackaged—maps to ISO 42001's controls (Annex D) so the two can be audited together for EU AI Act work. ISO 42001 on its own doesn't satisfy the Act, but it's becoming a load-bearing input to Act preparation.
Where they overlap is the same place ISO 42001's runtime controls live: Article 12 record-keeping and Article 14 human oversight. The event logs that satisfy A.6.2.8 and the human-in-the-loop control that satisfies A.9 are the same evidence a record-keeping and oversight obligation asks for. Build the runtime layer once, and it pays into both.
The takeaway
An ISO 42001 checklist made of documents will carry you through Stage 1. Stage 2 asks a different question—can you show what your agents did, under whose approval, inside what limits—and that answer has to exist before the auditor asks for it. The three controls that decide it are runtime controls, and runtime evidence comes from the execution layer, not the policy binder.
FAQ
What does an ISO 42001 audit check? It checks your AI management system against ISO/IEC 42001:2023—management-system clauses 4 through 10 plus every Annex A control you declared applicable (38 controls under 9 objectives). The audit runs in two stages: Stage 1 reviews your documentation and readiness, and Stage 2 verifies that the system operates in practice. The certificate is valid three years with annual surveillance audits.
What is on an ISO 42001 audit checklist? For teams running AI agents, the controls that decide Stage 2 are three runtime controls—A.6.2.6 (operation and monitoring), A.6.2.8 (event logs), and A.9 (use of AI systems—responsible use and human oversight)—plus a Statement of Applicability that evaluates all 38 controls and justifies every exclusion in writing.
Which ISO 42001 controls need runtime evidence instead of a policy? Three areas in particular for teams running AI agents: A.6.2.6 (AI system operation and monitoring), A.6.2.8 (AI system event logs), and A.9 (use of AI systems—responsible use and human oversight). Each asks for proof of what agents did in production—monitoring, traceable logs, enforced scope, and human intervention—not a written description of what they should do.
Can a tool make me ISO 42001 certified? No. Certification is granted by an accredited body against your management system; no product confers it. A tool like Alpacon supplies the operational evidence for specific runtime controls (A.6.2.6, A.6.2.8, A.9)—the runtime slice a policy document can't produce—but it doesn't generate the full ISO 42001 package or replace the certification body.
Does ISO 42001 certification mean my AI agents are EU AI Act compliant? No. ISO 42001 certifies your management system; the EU AI Act regulates products and adds conformity assessments, database registration, and GPAI rules no voluntary standard covers. They overlap on record-keeping (Article 12) and human oversight (Article 14), so the same runtime evidence serves both—but a certificate is not Act compliance.
How long does ISO 42001 certification take? Typically three to nine months from gap analysis to audit-ready. A mature ISO 27001 program and a small scope land at the short end, since many Annex A controls overlap with ISO 27001; the AI-specific controls are the ones that need new work.
If you're putting AI agents on production infrastructure, that's the part worth designing in before your first Stage 2, not after.
