ISO 42001 Certification: The Audit Stages, the Annex A Controls, and the AI Traffic Evidence Most Teams Cannot Produce
ISO/IEC 42001:2023 is the first management system standard for AI, and certification against it runs through a Stage 1 documentation review and a Stage 2 implementation audit by an accredited certification body, followed by a three-year cycle with annual surveillance. The auditor asks for evidence that the Annex A controls actually operate. For the controls that govern AI inference traffic, access, and logging, most teams cannot produce a record tied to who sent what to which model. This piece walks the certification path and the evidence gap on AI request traffic.
ISO/IEC 42001:2023 published in December 2023 as the first management system standard for artificial intelligence, and certification against it follows the same two-stage audit path as ISO 27001: a Stage 1 review of your documented AI management system, then a Stage 2 audit where an accredited certification body checks that the system operates in practice. The certificate runs three years with annual surveillance audits in between. The standard itself is available from ISO. What trips teams at Stage 2 is not the policy binder. It is producing evidence that the Annex A controls governing AI inference traffic actually run, tied to who sent what to which model. I want to walk the certification path and the specific evidence gap on AI request traffic.
What ISO 42001 certification actually checks
Certification is not a self-declaration. An accredited body sends auditors, and they work in two stages.
Stage 1: documentation and readiness. The auditor reviews your AI management system scope, policies, risk assessment, and Statement of Applicability against the Annex A controls, and confirms you are ready for the operational audit.
Stage 2: implementation. The auditor samples live evidence that the controls operate as documented. This is where a policy that says "AI usage is logged and access is controlled" gets tested against the records those controls are supposed to produce.
The three-year cycle. After the certificate issues, surveillance audits in years one and two re-sample evidence, and a recertification audit happens before year three closes. Evidence has to keep existing, not appear once.
The Annex A controls that touch AI traffic
Annex A of ISO 42001 lists controls across the AI system lifecycle. Several of them land directly on the inference traffic between your users, your agents, and the models they call: controls on access to AI systems, on logging and monitoring of AI system operation, on data classification and handling for AI, and on accountability for AI use. An auditor reading those controls asks a concrete question. Show me, for a sampled AI request, who made it, what data it carried, which policy applied, and what the system decided. A control marked "implemented" in the Statement of Applicability has to survive that question with a record.
Where the evidence gap opens
Teams routinely document the controls and then discover at Stage 2 that their AI traffic produces the wrong kind of record. Application logs show that a feature ran. They rarely carry the caller's corporate identity, because the call was authenticated with a service key. The data classification of the prompt is usually absent too, because the application never evaluated it. Worse, the log is written by the same application the auditor is examining, which makes it self-attested rather than independent. An auditor sampling ten AI requests wants ten records that each answer identity, data, policy, and outcome. A stack of application logs that answer only "a request happened at 10:42" leaves the control unproven, and an unproven control is a finding.
What auditable AI traffic evidence looks like
Closing the gap means producing an identity-bound record for every AI request, generated on the path to the model rather than by the application after the fact. A policy decision point in front of your model endpoints evaluates each request and commits a record like this, independently, before the response returns:
That record maps cleanly onto the Annex A controls for access, logging, and accountability, and an auditor can sample it directly. It is the difference between telling an auditor a control exists and handing them the evidence it ran.
How this connects to other frameworks
The evidence an ISO 42001 auditor wants is the same evidence other regimes require under different names. EU AI Act Article 12 requires automatic, traceable event logging for high-risk systems, including inputs and the natural persons involved, applying from August 2, 2026 per the European Commission. A team that builds identity-bound audit for its AI traffic satisfies the ISO 42001 logging controls and the Article 12 obligation with one architecture. Teams already scoping ISO 27001 alongside this should read ISO 42001 vs ISO 27001, and teams mid-build should see the ISO 42001 implementation guide and ISO 42001 audit evidence.
DeepInspect
This is the gap DeepInspect closes. DeepInspect is a stateless proxy that sits inline in front of your AI traffic and is model-agnostic, so one layer covers OpenAI, Anthropic, Bedrock, Vertex, Azure OpenAI, and self-hosted endpoints. For every request it evaluates the caller's identity and role, the data classification in the prompt, and organizational policy, then returns a pass or block decision before the traffic reaches the model. Enforcement adds under 50 milliseconds in internal testing, and the default on ambiguity is deny.
For every decision it commits an identity-bound audit record before the response returns, written independently of the calling application. That record is exactly what an ISO 42001 Stage 2 auditor samples for the access, logging, and accountability controls, and it keeps existing across the surveillance cycle without a scramble each year. DeepInspect does not write your AI management system or your Statement of Applicability. It produces the operating evidence that the AI-traffic controls in Annex A actually ran. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- How long does ISO 42001 certification take?
The audit itself runs in two stages, Stage 1 documentation review and Stage 2 implementation, usually weeks apart. The larger variable is readiness: building and operating the AI management system so that the Annex A controls produce evidence before Stage 2 samples them.
- What evidence do ISO 42001 auditors ask for on AI usage?
For the controls on access, logging, and accountability, auditors sample specific AI requests and ask who made each one, what data it carried, which policy applied, and what the system decided. Records that answer only that a request occurred leave those controls unproven.
- Is ISO 42001 the same as ISO 27001?
ISO 27001 governs an information security management system. ISO 42001 governs an AI management system with controls specific to AI development and use. Many organizations certify against both, and shared evidence like identity-bound AI request logs supports controls in each.
- How often is ISO 42001 re-audited?
The certificate runs three years with annual surveillance audits in years one and two and a recertification audit before year three ends. Evidence for each control has to persist across the cycle, not appear once at initial certification.
- Can application logs satisfy the ISO 42001 logging controls?
Application logs usually fall short here. They are written by the system under audit, often lack corporate identity and data classification, and are self-attested. An identity-bound record produced independently of the application is the stronger evidence for the access and logging controls.