What ISO 42001 audit evidence do certification auditors ask for?
When a customer, contract or regulator asks for ISO 42001, the first thing an auditor looks for is proof that the AI management system runs in practice. Auditors start with the statement of applicability, which clause 6.1.3 requires to list the Annex A controls the organization needs and to justify including or excluding each one, and then ask for the records behind every control claimed as implemented. A policy that has never been applied to a real AI system is weak evidence, so the organization should expect to show dated outputs, approvals and logs for each in-scope control.
The organization owns its controls, its records and its decisions about scope and risk. An implementation partner such as DeployOpen can help prepare systems, record templates and evidence collection, but it does not issue reports or certificates. Only an independent certification body can certify, and ISO itself does not certify organizations. The evidence required depends on the AI systems in scope, how they are built or used, and the risks the organization has identified, so two organizations with the same Annex A list may need very different records.
Before arranging an audit, confirm with the certification body which records it will sample and in what period. Check that the impact assessment results required by A.5.3 are documented and retained for the defined period, that verification and validation criteria and deployment approvals under A.6.2.4 and A.6.2.5 exist for each system, and that event log settings under A.6.2.8 are recorded. Ask whether the internal audit (9.2), management review (9.3) and corrective action (10.2) records already exist, because these show the management system is operating before the auditor arrives.
Which records prove the AI system controls work
Auditors do not accept a policy as proof that an AI control operates. They sample dated records from each control area and check that the records match the process the organization describes. The five cards below cover the evidence families the Annex A life cycle and impact assessment controls most often produce.
Impact assessment records
Under A.5.3, the organization must document the results of its AI system impact assessments and keep them for a defined period. Auditors typically sample several assessed systems and check that each assessment is dated, names the system version it covers, and records the impacts identified and the decisions taken on them. A weak record is a generic template with no system name, no owner, no retention period, or assessment results that were never acted on. Confirm the retention period is written down, not assumed.
Verification and validation results
Under A.6.2.4, the organization must define and document verification and validation measures for each AI system and state the criteria that decide when they are used. Auditors look for a defined test plan, executed results, and a clear pass or fail decision against the stated criteria. A weak record is a test plan with no executed results, or results that were reviewed without criteria, so nobody can say whether the system was fit to release.
Deployment plans and pre-deployment approvals
Under A.6.2.5, the organization must document a deployment plan and confirm that the appropriate requirements are met before the AI system goes live. Auditors sample releases and trace each one from the deployment plan to a signed approval that predates the production change. A weak record is an approval dated after deployment, an approver who is not accountable for the requirement, or a plan that does not match what was actually released.
Operation and monitoring plans
Under A.6.2.6, the organization must define what the ongoing operation of each AI system requires, covering at least system and performance monitoring, repairs, updates and support. Auditors check that a written operations plan exists for each system and that monitoring output, change records and support tickets show the plan being followed. A weak record is an operations plan that describes monitoring nobody performs, or repairs and updates made with no record of who approved them.
Event log settings by life cycle phase
Under A.6.2.8, the organization must decide which life cycle phases require event log recording, with logging required at a minimum while the AI system is in use. Auditors ask for the documented logging decision and then check the logging configuration and retained logs for each system in scope. A weak record is a logging decision that never names the phases, logs that stop after a deployment change, or retention settings that nobody can show were set. Confirm logging covers the in-use phase before the first audit.
Management system records auditors check before stage 2
Before a certification audit, the management system has to be running, not just written down. Auditors look for evidence that the performance evaluation clauses and the nonconformity process have already cycled at least once: monitoring, measurement, analysis and evaluation under clause 9.1, internal audit under 9.2, management review under 9.3, and nonconformity and corrective action under 10.2. A policy that says the organization will review AI systems each quarter has no weight if no review has happened.
In practice, the auditor is checking for dated records that show the cycle ran. For 9.1, that means monitoring results for the AI systems in scope, with the criteria used to judge them and the analysis that followed. For 9.2, it means an internal audit program, a completed audit with a named auditor who was independent of the area audited, and findings written up against the requirements. For 9.3, it means minutes showing that top management reviewed the inputs the standard requires and made decisions with owners and dates. For 10.2, it means each nonconformity logged, its root cause recorded, the corrective action taken, and evidence that the action was verified as effective. Gaps between these records are what auditors tend to probe first.
Confirm the timing with your certification body before you set the cycle, because the sequence of these records across stage 1 and stage 2 depends on the certification body's audit plan. The stage 1 and stage 2 page covers how that timing is handled. Your job now is to make sure each of these four processes has a named owner, a recurring schedule and a record format that an outside auditor can sample without help from the people who produced it.
How event logs and monitoring become audit evidence
Engineering decides what the AI system records and for how long. Control A.6.2.8 asks the organization to determine the life cycle phases in which event log recording should be enabled, and at a minimum while the AI system is in use. The design should be written down before go-live, so an auditor can compare the design with what the running system actually captures. The standard does not prescribe a tool or a format, so the team must choose both and justify the choice.
- Event scope: List the events to record, such as model invocations, prompt and response metadata, retrieval calls, tool executions, configuration changes and access to the model endpoint.
- Model and tool traces: Capture which model version, prompt template and tool was used for each request, so a single output can be traced back through the chain of calls.
- Retention: Set retention periods for each log category and record who approved them, since retention has to match the organization's own review and incident needs.
- Integrity: Protect logs from alteration and restrict who can delete them, and document where they are stored.
- Open-source tracing: Langfuse, which is MIT licensed, records traces with timing, inputs, outputs, token usage and metadata for LLM calls, retrieval steps and tool executions. Confirm with your own logging design whether it covers every event class you have defined.
Before relying on any tool, read ISO/IEC FDIS 24970 on AI system logging and check the tool's documentation against your design. Confirm that the design, the configuration and the retention settings match each other.
Governance turns logs and monitoring output into decisions. Clause 9.1 requires the organization to monitor, measure and evaluate its AI management system, and the operation control A.6.2.6 requires documented arrangements for monitoring the system's performance and for repairs, updates and support. Someone must own the review of this output, and the review must produce a record. A log that nobody reads is hard to defend in an audit.
- Named reviewers: Assign owners for reviewing AI system monitoring, including who receives alerts out of hours and who signs off on periodic reviews.
- Review cadence: Define how often each monitored measure is reviewed and keep dated records of each review, including what was checked.
- Exception handling: Record each anomaly, such as an unexpected output pattern, a tool call outside the intended purpose or a performance drop, with its cause and disposition.
- Feeding corrective action: Route exceptions into the nonconformity and corrective action process under clause 10.2, with root cause, action owner and closure evidence.
- Management review input: Summarize monitoring trends and open exceptions as an input to management review under clause 9.3.
The organization owns this process. An implementation partner may help design the review workflow, but an independent auditor only tests whether the process operates.
An auditor tests the chain from a recorded event back to the control that should govern it. A typical sample starts with an event from the logs, such as a model decision or a tool action, and asks which approval, impact assessment and deployment record authorized the system to behave that way. The auditor expects the organization to find the chain quickly. Gaps in that chain are more likely to produce findings than gaps in the logs themselves.
- Sampling from logs: Auditors select events across the period in scope and check that the log entry exists, is complete and has not been altered.
- Linking to approvals: Each sampled event should trace to the deployment approval and the version of the system that was approved under control A.6.2.5.
- Linking to impact assessments: Check that the use case behind the event appears in a documented impact assessment under A.5.3, with retained results.
- Evidence of review: Show the monitoring review record and any exception and corrective action linked to the sampled period.
- Consistency: Confirm that the statement of applicability matches the controls the logs actually support.
Before the audit, run this trace yourself on a few events. Ask the certification body for its sampling approach and confirm which period and systems it expects to see.
How to assemble the audit evidence file
This sequence turns scattered AI governance records into one organized file that shows an auditor how each in-scope control operates, what it covers and where the proof sits. Each step closes with an output the next step depends on, so the file is ready for stage 1 review when the sequence finishes.
Confirm scope and build the AI system inventory
Start by agreeing the scope of the AI management system in writing: which products, internal tools, AI-enabled services and business units fall inside it, and which AI systems the organization develops, provides or uses. The accountable AI owner compiles an inventory that names each system, its purpose, its owner, its data sources, its hosting location and its lifecycle stage. Confirm the inventory with the people who run each system, since it becomes the reference point for every later record. The step is done when the scope statement and the signed-off inventory exist and every in-scope system has a named owner.
Draft the statement of applicability
Using the scope and inventory, the organization reviews each of the 38 Annex A controls and decides whether it is necessary for the AI systems in scope. For each control, the statement of applicability records the decision to include or exclude it, the justification for that decision, and the location of the implementing evidence for included controls. Clause 6.1.3 makes this document mandatory, so exclusions need reasons an assessor can test against the inventory. The step is done when the statement of applicability is approved by the people accountable for AI governance and each control has a status and justification.
Collect records against each included control
For each included control, the control owner gathers the records that show it operates, and places them in a consistent folder structure keyed to the control identifier. Typical records include the AI impact assessment results retained under A.5.3, verification and validation criteria and results under A.6.2.4, the deployment plan and approval under A.6.2.5, operational monitoring and maintenance plans under A.6.2.6, and event log settings under A.6.2.8. Each record should show a date, an owner and the version of the AI system it describes. The step is done when every included control points to at least one dated, owned record, and gaps are logged rather than hidden.
Verify the performance evaluation records exist
Before presenting the file, confirm that the management system is already operating its performance evaluation clauses. Monitoring and measurement results under clause 9.1, internal audit records under clause 9.2 and management review minutes under clause 9.3 must exist as real outputs, not planned activities. Nonconformities raised in these activities should be tracked through corrective action records under clause 10.2. The step is done when the organization can show at least one completed cycle of each activity with dated outputs, and the owners can explain how findings were handled.
Run an internal audit against the file
Assign an internal auditor who did not build the controls to test the assembled file against the statement of applicability and the requirements in clauses 4 to 10. The auditor samples records, checks that they match the inventory and the stated version of each AI system, and confirms that exclusions are justified. Findings are written as nonconformities or observations with owners and due actions. The step is done when the internal audit report lists every finding, and each nonconformity has a corrective action record linked to the affected control.
Hold management review and record the decisions
Management reviews the internal audit results, the status of monitoring, the AI risk and impact picture, and open corrective actions, then records its decisions on resources, scope changes and priorities. The minutes should show who attended, what was reviewed and what was decided, and they should update the statement of applicability if a control status changed. The step is done when signed minutes exist, actions have owners, and any change to scope or controls is reflected in the controls register.
Correct gaps and present the file for stage 1
Close the gaps raised by the internal audit and management review, updating records, controls and the statement of applicability as needed, and retain the version history so the auditor can see what changed and when. Then assemble an index that maps each in-scope control to its evidence location, and give it to the certification body as part of the stage 1 preparation. Confirm the certification body's document requirements in writing before submission, because the format and depth of what they request can vary. The step is done when the index, the statement of applicability, the inventory and the management system records are complete and the certification body has confirmed the submission package.
Evidence auditors expect for each control area
This table lists, for each Annex A area and the performance evaluation and improvement clauses, the record a certification auditor typically asks to see, who usually owns it, and where organizations most often fall short. Read it as a checklist to build before stage 1, not as a list of controls to implement in full, since the statement of applicability decides which Annex A controls apply. The main takeaway is that auditors test whether records exist, are current and show the process actually running.
| Annex A area or clause | Record auditors ask for | Usual owner | Common gap |
|---|---|---|---|
| A.5 Impact assessment (A.5.3) | Documented AI system impact assessment results, with retention period and the criteria used to decide when an assessment is needed | Product or AI governance lead with privacy or legal input | Assessments written once at launch and never refreshed after model or data changes |
| A.6.2.4 Verification and validation | Defined V&V measures, acceptance criteria and the test results that show the system met them before release | Engineering or data science team | Test results exist but the criteria for accepting them were never written down |
| A.6.2.5 Deployment | Deployment plan and a record that the required requirements were met before the AI system went live | Release or platform engineering owner | Deployment approvals missing for changes made after the first release |
| A.6.2.6 Operation | Documented operational procedures covering monitoring, repairs, updates and support for the AI system | Operations or platform team | Monitoring configured but no record of reviews, incidents or updates acted on |
| A.6.2.8 Event logs | Documented decision on which life cycle phases log events, and log samples showing logging while the system is in use | Platform or security engineering | Logging policy not defined, so logs are either absent or cannot be tied to a system version |
| A.7 Data for AI systems | Data management records covering acquisition, quality checks, provenance and preparation for each dataset used | Data owners with data engineering | Provenance recorded for training data but not for data used in retrieval or evaluation |
| A.8 Information for interested parties (A.8.2 to A.8.4) | User documentation, adverse impact reporting records and incident communication records | Product, support and legal teams | User documentation out of date with the deployed system's behavior and limitations |
| A.9 Use of AI systems | Records showing use stays within the intended purpose and the objectives guiding use | Business system owners | Intended purpose stated in the impact assessment but not enforced in deployed workflows |
| Clause 9.1 and 9.2 monitoring and internal audit | Monitoring and measurement results, and internal audit program plan with completed audit reports | Management system owner and internal auditors | Internal audit not yet run across all in-scope AI systems before stage 1 |
| Clause 9.3 and 10.2 management review and corrective action | Management review minutes and nonconformity records with root cause and corrective action status | Top management and the management system owner | Review minutes that record attendance but no decisions or resource choices |
Why evidence files fail or delay the audit
Most ISO 42001 evidence problems are not missing policies. They are policies without operating records, decisions without justification, and records spread across tools that cannot be traced back to a single AI system. Each card below names one pitfall auditors commonly find and the fix that closes it before stage 1 or stage 2 begins.
Procedures with no operating records
A documented procedure shows what the organization intends to do, not that it does it. Auditors look for dated outputs that the procedure produced, such as completed impact assessments, review minutes and sign-offs for each AI system in scope. Check that every documented process has at least one record from real operation, and remove procedures that nobody follows, since an unused procedure invites questions about the rest of the system.
Exclusions without justification
Clause 6.1.3 requires a statement of applicability that lists the controls the organization needs and justifies including or excluding each Annex A control. An exclusion written as "not applicable" with no reason is the simplest finding to raise. Give each excluded control a reason tied to the organization's AI systems, its role as provider, deployer or both, and the risk assessment that supports the decision.
Impact assessments not linked to deployment
A.5.3 asks for impact assessment results to be documented and retained, and A.6.2.5 asks for a deployment plan that confirms requirements are met before release. Auditors trace an assessment forward to the deployment approval for the same system. Give every deployment approval a reference to the impact assessment version it relied on, and reopen the assessment when the model, data or use case changes materially.
Event logs turned off in production
A.6.2.8 asks the organization to decide in which life cycle phases event logs are enabled, with a minimum of when the system is in use. Logging that works in a test environment but is disabled or sampled in production leaves no evidence for the period auditors care about most. Confirm logging is enabled in production, record the setting and its owner, and test that a sample of production events can be retrieved before stage 2.
Internal audits that skip AI controls
Internal audit under clause 9.2 must cover the management system, and the AI controls in Annex A are part of that system. An internal audit that only checks the policy document and the organization chart will not surface gaps in monitoring, verification or third-party management. Sample at least one AI system end to end in each internal audit, from its impact assessment through its deployment approval, logs and corrective actions.
Records scattered across tools
Evidence for one AI system often sits in a ticketing tool, a model registry, a shared drive, a trace store and an email thread, with no shared identifier. Auditors then spend their time reconstructing the chain instead of testing it. Assign each AI system a single identifier and store cross-references in one register that points to the location of every record, so an auditor can follow one system from policy to log without manual searching.
Who owns each piece of audit evidence
The organization owns the AI management system and every record that proves it works. Its leadership sets the AI policy, names the people accountable for AI decisions, approves the risk and impact assessments, and decides which Annex A controls apply. The statement of applicability is signed off by the organization because it states what the organization has chosen to do and why. Auditors will test whether staff actually follow these records, so ownership cannot be delegated on paper alone.
- Statement of applicability: the organization decides each Annex A control's inclusion or exclusion, justifies it, and signs the document.
- Impact and risk records: named owners review and approve assessment results before any AI system goes live.
- Deployment approvals: an accountable manager signs off that the requirements in the deployment plan were met.
- Management review and internal audit: leaders hold the review meetings, act on findings and keep minutes.
- Corrective actions: the organization tracks nonconformities through to closure under clause 10.2.
Before stage 1, confirm that each of these records has a named owner and that the people who sign them can explain what they approved.
An implementation partner helps build the systems that generate evidence and organizes that evidence for the organization. Typical work includes configuring logging and monitoring on self-hosted platforms, drafting templates for impact assessments and deployment plans, setting up evidence repositories, and collecting records on a schedule. The partner prepares material for the organization's review. It does not decide the controls, approve records, sign the statement of applicability or represent the organization to the certification body in a way that replaces its own staff.
- Logging and telemetry: configure event log capture, retention and access in the client's infrastructure.
- Templates: draft assessment, approval and review forms that the organization adopts and edits.
- Evidence collection: gather monitoring output, test results and change records into a retrievable structure.
- Gap support: document where current practice falls short, without deciding how the organization closes the gap.
- Handover: train named staff to maintain systems and evidence after the engagement ends.
Confirm in the written scope that the partner will not sign records or issue any assurance statement, and that the organization retains administrator access to its own evidence.
An accredited certification body is the only party that can issue an ISO 42001 certificate. It plans the audit, samples evidence from the organization's records and interviews staff, and then decides whether to grant, maintain or withdraw certification. ISO does not certify organizations, and certification bodies must be independent of the organizations they audit. Accreditation of the body is voluntary, which is why the body's accreditation status should be checked before it is engaged.
- Sampling: the auditor selects records, such as impact assessments and event logs, and tests them against the requirements.
- Findings: the body raises nonconformities that the organization must close within the set time.
- Decision: the certification decision rests with the body, separately from the audit team's work.
- Certificate issue: only the body issues the certificate and its scope statement.
- Surveillance: the body returns on a recurring schedule to test the system again.
Verify the body's accreditation and scope for AI management systems before contracting, and confirm that no consultant on your team will also perform the audit.
ISO 42001 audit evidence questions buyers ask
What evidence does an ISO 42001 auditor expect before stage 1?
Before stage 1, the auditor expects a documented management system that already produces records, not a plan to create them. The core set is the statement of applicability under clause 6.1.3, which lists each Annex A control and justifies its inclusion or exclusion, plus the AI policy, role assignments, the AI risk and impact assessment records, and documented verification and validation results for the AI systems in scope. Auditors also look for evidence that clauses 9.1 (monitoring, measurement, analysis and evaluation), 9.2 (internal audit) and 9.3 (management review) are operating, along with 10.2 records of nonconformity and corrective action. Ask the certification body to confirm its stage 1 document list in writing before you start collecting material.
Can our own team prepare ISO 42001 audit evidence without outside help?
Yes, an organization can prepare its own evidence, because the controls, records and decisions must belong to the organization. The work is substantial, though. Teams need people who understand the AI systems in scope, who can write the impact assessments and deployment approvals, and who can run internal audits that are independent of the work they check. Outside help is typically used to prepare systems, collect logs, document procedures and test readiness, while the organization keeps ownership of every decision. Any implementation partner will not issue the certificate. Only an independent certification body does that. Before you decide, compare your internal skills against the Annex A control list and the clause 4 to 10 requirements.
How far back must ISO 42001 audit records go?
The answer depends on how the management system has been operating, and the certification body sets how much history it needs to see. Clauses 9.2 and 9.3 require internal audits and management reviews to have actually been performed, so an auditor will want to see them run at least once. Annex A control A.5.3 requires impact assessment results to be retained for a defined period, and the organization must define that period itself. Record retention for event logs under A.6.2.8 must also be defined by the organization. Confirm with your certification body how much operating history it expects at each stage and which retention periods it will test against.
Does a certification body pre-audit replace our internal readiness work?
No. A pre-audit or readiness review by a certification body is a limited check of documents and status, and it does not replace the internal work of building and running the management system. Certification bodies must keep their independence from the clients they certify, so they generally cannot design the controls or prepare the evidence for you. The internal work includes a gap analysis against clauses 4 to 10 and the Annex A controls, documented impact assessments, verified AI systems, operating internal audits and management reviews. Ask the body exactly what its pre-audit covers and what it excludes before you treat the result as readiness.
How can ISO 27001 evidence be reused for ISO 42001?
ISO 42001 uses the harmonized structure shared by ISO management system standards, so much of the governance machinery is similar to ISO 27001. Documented information control, internal audit, management review, nonconformity handling and corrective action can often be shared, with one document register, one audit programme and one set of review minutes. The AI-specific evidence must still be separate. That includes the AI system inventory, AI impact assessments, verification and validation results, deployment approvals for AI systems, and AI event logs. Map each ISO 27001 record to the clause it supports, then add the AI-specific records where ISO 42001 requires them. Confirm with your certification body how it will audit an integrated system.
Who issues the ISO 42001 certificate, and who prepares the evidence?
An external certification body issues the ISO 42001 certificate after an audit. ISO itself does not certify organizations. The organization owns its AI management system and prepares the evidence. An implementation partner can help build systems, controls and records, and can test readiness, but it cannot issue audit reports or certificates. Certification bodies should be accredited for ISO 42001 scope where accreditation is available, and ISO/IEC 42006 sets additional requirements for bodies certifying AI management systems. Check the accreditation status and scope of any body you consider, and verify issued certificates directly with that body.
Where to read the requirements yourself
Read the control text in the official standard before you rely on any summary, including the one on this page. The ISO/IEC 42001:2023 standard is available from ISO at ISO/IEC 42001:2023 (ISO), where you can confirm the edition, the publication date and the current status. For the clause structure, the Annex A control titles and the scope wording, the free preview PDF from the IEC is the most practical starting point, since it covers the contents, introduction and scope. Use it to check the control identifiers in the statement of applicability you are drafting, but treat the full standard, purchased through ISO or the IEC, as the controlling text for wording on each control and its Annex B implementation guidance.
Certification body rules are a separate source and are often overlooked by teams focused on the controls. Read ISO/IEC 42006:2025 (ISO) to understand what the certification body must demonstrate about its own competence when it audits an AI management system, because that shapes what the auditor will ask you to produce and how the findings are written. Ask any prospective certification body to confirm in writing which edition of ISO/IEC 42006 and which version of ISO/IEC 17021-1 its audit process follows, so that your evidence pack matches the auditor's method from the first engagement.
For the general rules on how certification works, including the roles of the organization, the certification body and the accreditation bodies, read ISO: Certification (ISO). It explains that ISO does not certify organizations and that external certification bodies do. Your internal owner for AI governance should keep these three sources in a controlled document folder with a review date, and should record which edition each control reference was taken from. Any change to the standard or to certification body requirements should trigger a check of the statement of applicability and the evidence index.
How DeployOpen prepares AI governance evidence
DeployOpen plans and implements self-hosted open-source platforms in the client's own infrastructure, then prepares the systems and records that an ISO 42001 certification audit will sample. The organization owns its AI governance controls and decisions, and only an independent certification body issues a certificate.
How we scope
- Agree in writing which Annex A controls and evidence records the engagement covers before work starts.
- Confirm which AI systems, environments and teams fall inside the scope of the management system.
- Engagements are fixed-scope, so deliverables and timelines are set out in writing before any work begins.
How we build
- Configure self-hosted tooling to capture event logs, monitoring data and deployment records for in-scope AI systems.
- Set up document control so impact assessments, verification results and approvals are dated, versioned and retained.
- Test the evidence pipeline end to end so records can be retrieved for a sampled AI system during an audit.
How we hand over
- Deliver an evidence map linking each in-scope Annex A control to the records, systems and owners that support it.
- Provide runbooks describing how records are generated, reviewed, retained and exported for an auditor.
- Document where the organization must still perform reviews, sign-offs and internal audits itself.
How we support
- Available as a retainer for ongoing support, upgrades and evidence maintenance between audit cycles.
- Support can cover updates to the statement of applicability when AI systems or controls change.
- Confirm with the certification body which evidence it expects and how it samples records before stage 1.
