ISO 42001 Evidence: What Auditors Ask For

ISO 42001 is the management system standard for artificial intelligence. It sits on the backbone of ISO 27001 but with a different focus: do you have a system for governing AI, and can you prove that system runs, with evidence?

Core to the standard is an Artificial Intelligence Management System (AIMS), a structured set of policies, processes, and controls an organization uses to govern AI. Rather than focusing on any single model, ISO 42001 determines if an AIMS shows control over how AI gets built, deployed, and used across its lifecycle.

Why organizations pursue ISO 42001

In my experience, organizations pursue ISO 42001 for three main reasons:

1. They already have AI in production and need to demonstrate governance, something more defensible than "we're being careful."
2. A customer or a contract now requires it, and the deal does not move until they can demonstrate control over the use of AI.
3. Pressure from the top, a board or leadership team that has read the same headlines everyone else has and wants to know the company's AI risk is being managed rather than assumed.

The procurement angle is worth naming on its own, because it is increasingly the thing that forces the decision. Customers now ask whether AI is used, what it is used for, and how it touches their data. They want to know the use cases and if there is any risk of their data being exposed.

ISO 42001 certification turns that hard conversation into a short one. Instead of walking a prospective customer through your controls or completing a large assessment, you can point to an independent assessment that proves that a system is in place.

Regulation comes up as well. The EU AI Act is the one clients ask about frequently. To be clear, ISO 42001 does not make you compliant with the AI Act. ISO 42001 is a voluntary certification that requires organizations to define their AI requirements, whereas the EU AI Act is binding law with fines up to €35 million or 7% of global turnover for the most serious violations.

The NIST AI Risk Management Framework is another voluntary standard that clients use as a baseline for building AI risk practices from scratch. What 42001 provides that these other frameworks do not is organized, defined roles, risk assessment, and human oversight, so that when a regulation like the AI Act or framework, such as NIST AI RMF does apply to you, you’re starting from a strong foundation.

What I ask for in an ISO 42001 audit

I have sat on both sides of the audit table, as an auditor and as an auditee. I am a certified ISO 42001 and ISO 27001 auditor, and I have worked across GDPR, HIPAA, SOC 2 and other regulatory requirements for over 15 years.

I’ve observed organizations fail an ISO 42001 audit because they cannot demonstrate that they are following policies and procedures systematically and consistently, and not the week before the assessment.

I tend to find these three different failures:

1. Sometimes the control ran and nobody captured proof that it ran
2. Sometimes the control ran, was captured, but cannot be tied to a person or a time
3. In some cases, the control was never there at all, which is the one nobody discovers until an assessor finds it

From the outside, all three look identical. I cannot give credit for what I cannot see.

What follows is the evidence I ask for, what makes me reject the answer, and what you can test before an auditor shows up.

Access reviews of AI system resources (A.4.5)

The standard requires you to identify and document your AI system and computing resources, which quickly becomes a question of who can reach them and what level of privilege they have. ISO 42001 leans on your existing security management system for the identity and access mechanics, so if you are certified to ISO 27001 this transition becomes easier.

I sample several access reviews across a period to determine if reviews are occurring on a systemic cadence or as a one off.

Then I assess how each was performed. Was it based on a system export, somebody cross referencing access sheets, or with GRC tooling integrated with the identity source to consolidate access and highlight changes? The latter provides more robust, traceable evidence compared to a manually maintained spreadsheet.

I reject the artifact when it cannot tell me who reviewed it, when, and against what. I look for the change record behind a removal, because access that disappears between two reviews with no request behind it is its own finding.

Infrastructure evidence that supports AI development and deployment controls (A.6.1.2, A.6.2.4, A.6.2.5)

ISO 42001’s development and deployment controls cover how an AI system is built (A.6.1.2), verified and validated (A.6.2.4), and moved into production (A.6.2.5).

This is where the trail usually breaks. Engineering records may be scattered across source control, CI/CD, model registries, cloud infrastructure, and access management systems.

Infrastructure evidence can support development and deployment controls by showing who could access the relevant environments, what privileges they held, and what actions they took.

A.6.1.2 — Objectives for responsible development of AI systems

Infrastructure records can show whether the access guardrails behind your responsible-development objectives are actually being applied. Review who can reach development Kubernetes clusters, GPU environments, training-data stores, model registries, and cloud accounts, and what privileges they hold.

Evidence might include: A Kubernetes RoleBinding or cloud IAM role assignment, group-membership records, approved elevated-access requests, and audit logs showing that access being used.

A.6.2.4 — AI system verification and validation

Infrastructure records add traceability around who or what could access the staging or validation environment and what happened there during the test period.

Evidence might include: A CI test or validation run, the cluster or namespace used, a record of the engineers, service accounts, or pipelines with access at that time, and cloud or Kubernetes audit logs from the same window.

A.6.2.5 — AI system deployment

An approved release should be traceable into production and connected to the infrastructure activity that followed. You should be able to identify who or what deployed it, what production access was used, and which resource was changed.

Evidence might include: An approved PR or change record, the CI/CD job or engineer that performed the deployment, the production role or temporary access grant used, the target cluster or cloud account, and infrastructure audit logs showing the deployment activity.

Evidence for operations, monitoring and event logging (A.6.2.6, A.6.2.8)

ISO 42001’s operations and logging controls cover how an AI system is monitored in use and how event records are retained across its life cycle. I ask which phases of the AI system life cycle have logging enabled, what you chose to record, and why. Then I pick an event and ask you to rebuild it from the records.

Those records also need to be attributable. I would not accept activity that cannot be tied back to the engineer, service account, workload, pipeline, or agent responsible.

If the event resulted in corrective action, the evidence trail should continue through to closure. I saw this gap in a recent HIPAA engagement. The organization had investigated a reportable breach and completed the required response work, but could not produce evidence that the required communication with the affected user had actually been completed.

The process ran. However, proof of the final step did not exist. Here’s the evidence that shows the controls are working.

A.6.2.6 — AI system operation and monitoring

Operational evidence should show that you have visibility into what is happening in the infrastructure supporting the AI system: failed workloads, configuration changes, unexpected privilege use, service disruptions, or changes to production clusters and services.

Evidence might include: Monitoring alerts, cloud and Kubernetes audit logs, application and system logs, and access records showing the affected resource, timestamp, and engineer, service account, pipeline, workload, or agent involved.

A.6.2.8 — AI system recording of event logs

Event logs provide the retained record needed to understand what happened after the fact. They should contain enough context to connect an action to a specific actor, resource, time, and activity.

Evidence might include: Cloud or Kubernetes audit events, authentication and access logs, CI/CD activity, system events, and records tying an action to a specific engineer, service account, workload, pipeline, or agent.

If an event triggers corrective action, the evidence should continue beyond the logs. I ask for the artifact that closes the loop. It is closed when you can show the corrective action was carried through to the end, which is what Clause 10.2 asks for.

Objectives for responsible use of AI systems (A.9.3)

Under A.9.3, organizations should define and document objectives for responsible AI use, including meaningful human oversight that demonstrates control, review, and intervention over an AI system's behavior and operations.

Human oversight is separate from monitoring.

A note on mapping, since it can confuse some readers: A.8 covers information for interested parties of AI systems, including information about human oversight where relevant. It does not define the organization’s human oversight requirements.

• A.9.3 addresses objectives for responsible use, including human oversight
• A.6.1.3 addresses human oversight requirements during responsible AI system design and development
• A.6.2.6 covers operation and monitoring of the AI system

In a recent ISO 42001 gap analysis, I looked at an organization that had deployed an AI tool producing daily system status output. The output would be sent to end users.

There was no human review of it at any point, and the day I saw it, the output made no sense. Nobody had checked, because there was no step at which anybody was supposed to check. This was not an evidence problem. The control did not exist. In a certification audit I would expect this to be raised as a major nonconformance, and that it would not sit under a single control because it touches oversight, verification and validation of output before release.

The remediation was an obvious one; an engineer or the data science team reviews and validates the daily output before it goes anywhere. This is typically the shape of AI oversight problems. Systems produce output, but nobody checks, and agents act with nobody to intervene.

The strongest evidence demonstrates a review that happened, a stopped session, or an override with an attributable identity and a time on it.

Evidence might include: A review record showing who checked the AI output and when, an approval or sign-off before the output was released, a ticket or workflow showing an escalation to a human, and logs showing a person paused, stopped, rejected, or overrode an AI action.

For higher-risk workflows, I’d also look for the role or permission that gave that person authority to intervene and a record of what happened after the intervention.

Evidence of responsible and intended use of AI systems (A.9) and authorized third-party access (A.10)

A.9 covers the use of AI systems for their intended purpose, including the requirement to restrict access to authorized parties. A.10 extends this to third party and customer relationships, where responsibility is allocated across suppliers and customers.

I ask how an authorized party is defined, then I ask you to show the definition is enforced rather than described. Logs of the identities that are connected are half of it; RBAC rules, access approvals, and records of blocked attempts where they occur show how the boundary is actually applied.

A.9.4 — Intended use of the AI system

Access controls can help enforce the boundaries around intended use—for example, limiting an AI service to approved teams, workloads, environments, or applications.

Evidence might include: IAM/RBAC rules, role or group assignments, API/application access policies, and logs showing which users, service accounts, or workloads actually accessed the system.

A.10.2 — Allocating responsibilities

When a third party is involved, its technical access should reflect the responsibilities assigned to it. Evidence might include: Documented responsibility assignments alongside third-party accounts, roles, permissions, and access approvals showing what infrastructure that party is allowed to reach.

A.10.3 — Suppliers

Where suppliers operate or support AI infrastructure, their access should be scoped to the systems and work they are responsible for.

Evidence might include: Supplier or service accounts, scoped or temporary access grants, access reviews, and logs showing which resources the supplier actually accessed.

Demonstrating access governance and traceability for data used by AI systems (A.7)

This section matters most to your stakeholders. Clients want to know how you obtain data, protect it, manage it, restrict access to it, and what governance you hold over it. Organizations lean heavily on MSAs, DPAs, and similar agreements, and these requirements differ depending on whether you act as Data Controller or Data Processor.

An access trail is the record of who (or what) reached the data, when, and what they did, with every action tied to an identity regardless of privilege level or access type.

Evidence might include: Identity-provider logs such as Okta or Azure AD for authentication and MFA, database audit logs showing access to the data itself, cloud audit logs such as AWS CloudTrail or Azure Activity Logs, PAM logs for privileged or break-glass access, and SIEM records that correlate and retain those events so the access trail can be reconstructed after the fact.