ISO/IEC 42001:2023 Audit Readiness: 18 Evidence Checks for AI Management Systems

An AI policy is not proof that an AI Management System is working. An organization can approve a policy without knowing exactly which AI tools influence customer outcomes, who can stop an unreliable model or how an unexpected output is investigated. That gap raises a sharper audit question: what objective evidence demonstrates effective AI governance?

This ISO/IEC 42001:2023 audit readiness checklist translates management-system principles into practical evidence trails. It is for executives, compliance managers, IT teams, AI developers, purchasers and internal auditors. The checklist is a preparation aid, not a reproduction of the standard or a substitute for its normative requirements.

1. What ISO/IEC 42001:2023 requires organizations to consider

ISO/IEC 42001:2023 specifies requirements and guidance for establishing, implementing, maintaining and improving an Artificial Intelligence Management System (AIMS). It is relevant to organizations that develop, provide or use AI systems. The published edition referenced in October 2026 remains 2023; discussions about ISO 9001 and other 2026 revisions should not be confused with a new ISO/IEC 42001 edition.

An AIMS links governance, objectives, responsibilities, operational controls and improvement throughout AI-related activities. Certification is voluntary, and ISO does not itself certify companies. A certification scope concerns a defined management system; it should not be marketed as a guarantee that every AI output is correct, fair or legally compliant.

2. Define the scope before creating audit documents

Start with the activities, sites, products, users and outsourced services that the AIMS will govern. A company building a chatbot and a factory using machine vision may need different safeguards, but both should identify the decisions their systems affect. Document organizational boundaries, interfaces, relevant stakeholders and the external requirements that shape the intended scope.

An auditor should be able to trace the scope statement to actual deployed systems and responsible functions. Explain why exclusions are appropriate instead of treating the scope as a convenient way to ignore high-risk uses. Scope clarity also prevents disconnected teams from applying conflicting approval rules.

3. Maintain a testable AI system inventory

Create a register showing each AI use case, owner, intended purpose, internal or third-party provider, operating location, important data sources, status and decision impact. Distinguish pilot, production, retired and suspended systems. Include externally purchased AI tools used by business teams where they fall within the defined scope.

Then test the list. Compare selected entries with procurement purchases, software access records, service agreements and actual workflows. If an AI tool influences decisions but has no assigned owner or review record, a polished spreadsheet will not establish that the inventory control is effective.

4. Show leadership decisions, authority and accountability

Management commitment must reach beyond a signed statement. Identify who approves AI use cases, accepts residual risks, funds safeguards, resolves competing priorities and decides when systems should be restricted or stopped. A committee whose meetings produce no decisions offers weak evidence of operational oversight.

Relevant evidence includes AI objectives, assigned roles, decision records, escalation outcomes and resources approved after risks were identified. Existing ISO 27001 information security arrangements may support governance, but AI-related effects on people, outputs and decisions still need appropriate evaluation.

5. Assess risk and impact for real operating scenarios

A register entry saying “AI may be inaccurate” is not enough. Identify a credible failure scenario, the potentially affected people or processes, likely consequence, applicable controls, residual risk and the person authorized to accept or treat it. An AI supplier-screening tool, for example, could incorrectly approve a risky provider; an inspection model could fail to identify a defective product.

Evaluate privacy, security, misuse, bias, model reliability, transparency and other impacts as relevant to the use case. Reassess after meaningful changes in data, models or deployment conditions. ISO/IEC 23894:2023 provides complementary AI risk-management guidance, although its guidance is not automatically an additional certification requirement.

6. Trace data provenance and suitability

AI performance depends on the data entering development, deployment and ongoing operation. Define data origin, permissions, intended use, quality checks, access limitations and retention or deletion arrangements. Where necessary, keep meaningful dataset and configuration versions so that problematic outputs can be investigated.

Take one sampled application and follow its data trail from acquisition to approved use. The fact that information is securely stored does not prove it is sufficiently relevant, representative or lawfully usable for the AI purpose. Evaluate these different questions separately.

7. Challenge third-party AI supplier assurances

Organizations increasingly integrate hosted models, AI-enabled software and external APIs. Suppliers influence performance and risk, but using a vendor does not transfer all responsibility for the organization’s own decisions. Review the business justification, product limitations, contractual restrictions, data-handling terms, changes and incident-reporting arrangements.

A vendor questionnaire is only a starting point. Examine what the purchaser actually verified and whether continuing oversight occurs after the service changes. Shark’s supplier declarations and compliance article explores why assurances should be supported by appropriate evidence.

8. Control AI design, testing and deployment

Before releasing an AI-supported process, define the intended output, permissible operating conditions, acceptance criteria and situations requiring human escalation. Test representative inputs, known failure modes and relevant edge cases. A headline accuracy percentage without the test context cannot demonstrate suitability for an important business decision.

Retain approval evidence, limitations, version information and the basis for release. Treat changes to a model, prompt, dataset, external provider or decision threshold as possible triggers for reassessment. A repeatable change-control process connects original assumptions with the deployed configuration.

9. Demonstrate meaningful human oversight

“Human in the loop” is useful only if people can challenge the system’s result. Record when staff must review outputs, what information they need, whether they can override or pause the process and how exceptions are escalated. Excessive workload can turn formal approval into an ineffective rubber stamp.

During an audit, select a real override or unusual result. Ask who noticed it, what happened next and whether the decision was recorded. Distinguish genuine authority and competence from a process map that merely contains an approval symbol.

10. Decide what transparency requires in context

Communication needs vary with the audience and use case. An internal maintenance assistant does not create the same expectations as customer-facing advice or an automated decision affecting individuals. Identify what users, affected parties and relevant authorities should be told about AI involvement, intended purpose and meaningful limitations.

Review instructions, disclosures, notices, operator guidance and complaint or challenge routes. Confirm that these match the currently deployed system. An AIMS can support responsible management but does not, by itself, establish compliance with every applicable law.

11. Monitor drift, errors and operational effects

AI systems can behave differently after changes to data, workflows, vendors and real-world conditions. Select indicators that matter to the particular application, such as error categories, operator overrides, complaint trends, unexpected outputs or performance in important subgroups. Define a review schedule and what should trigger investigation.

Consider an illustrative factory visual-inspection system: quality personnel could compare errors across product variants, investigate false negatives and review changing lighting conditions. A dashboard is not sufficient if nobody acts on warning signals. See Shark’s discussion of measurement reliability for the broader principle of validating results in context.

12. Investigate incidents and verify corrective actions

A workable incident process should capture unexpected AI outcomes, preserve relevant evidence, identify impact, assign ownership and determine whether deployment should continue. Alerts can originate from user complaints, audit samples, monitoring tools or supplier notifications. Include applicable escalation and communication obligations.

Follow an actual case from detection to closure: what failed, which controls changed and what proves the corrective action worked? Merely retraining an operator or revising a prompt does not automatically eliminate the cause. See Shark’s root-cause analysis guide.

13. Verify role-specific competence and awareness

An AIMS does not require every employee to become a data scientist. It does require appropriate competence for assigned work. Purchasers may need to challenge vendor claims, managers may approve risk treatment, and operators may need to recognize conditions in which the AI system should not be trusted.

Review training and awareness activities, then test their practical effect. Can a supervisor describe the escalation process? Does the responsible team know who can suspend an unsafe or unreliable workflow? Training attendance alone is less persuasive than demonstrated understanding and effective action.

14. Make internal audits evidence-led and risk-based

Internal audits should sample the way policies operate across procurement, deployment, operations and review. Define clear criteria, then trace representative AI systems from approval to real outputs, incidents and controlled changes. Avoid reducing the audit to a document checklist or treating every preferred practice as a mandatory clause.

Findings require objective evidence of an unmet applicable requirement. An auditor’s impression that the organization has a weak “AI culture” is not itself a nonconformity. Shark’s article on repeated internal-audit findings explains why follow-through matters.

15. Connect management review to real decisions

Management review should consider performance, audit results, relevant changes, stakeholder concerns, incidents, residual risks and improvement needs. The output should show decisions about priorities, responsibilities, resources and the continuing suitability of the AIMS.

For example, trace a monitoring warning from its first escalation to a management decision, assigned action and later effectiveness review. A meeting agenda and attendance list cannot replace evidence that leadership responded to the actual information.

16. ISO/IEC 42001:2023 — 18 practical evidence checks

Use these checks for readiness planning; they are not an official ISO clause checklist. Map each item to the applicable normative requirement and your own scope, and record where the evidence is stored, who owns it and whether it is current.

1. 01. AIMS scope covers relevant AI activities, sites and external interfaces.
2. 02. Applicable obligations and interested-party expectations have assigned review owners.
3. 03. An AI inventory reflects real tools, providers and deployed use cases.
4. 04. Risk decisions and approvals have named accountable authorities.
5. 05. AI objectives and policy influence documented operational decisions.
6. 06. Risk assessments address specific plausible AI failure scenarios.
7. 07. Relevant AI impacts and affected parties have been evaluated.
8. 08. Data provenance, access and suitability controls are traceable.
9. 09. External AI providers receive proportionate selection and ongoing review.
10. 10. Design and release criteria are approved and applied.
11. 11. Testing addresses intended use, limitations and relevant edge cases.
12. 12. Model, dataset, prompt and service changes are controlled.
13. 13. Human oversight and escalation function during actual operations.
14. 14. AI disclosures and instructions are appropriate and up to date.
15. 15. Monitoring indicators have owners and response triggers.
16. 16. Incidents and corrective actions include effectiveness verification.
17. 17. Internal audits test implementation against valid criteria.
18. 18. Management review leads to decisions, action and follow-up.

17. Organize a realistic 30–60–90-day readiness plan

Days 1–30: appoint leadership ownership, establish the initial AIMS scope, identify deployed AI tools and prioritize use cases with significant potential impact. Use procurement records and employee interviews to check the inventory rather than assuming it is complete.

Days 31–60: perform risk and impact assessments for priority systems, review third-party dependencies and implement practical controls around data, release, oversight and monitoring. Assign actions with owners and dates based on risk.

Days 61–90: sample operational evidence, test controls, address issues, perform internal audit activities and obtain management review decisions. This is an illustrative project sequence—not a claim that every organization can be certified within 90 days.

18. Frequently asked questions on ISO/IEC 42001 audit readiness

Is ISO/IEC 42001:2023 the published standard in October 2026?

Yes. The official ISO catalogue identifies ISO/IEC 42001:2023 as the published first edition. Verify its current status with ISO whenever preparing formal contractual or certification documentation.

Does ISO/IEC 42001 apply to businesses using third-party AI tools?

It is designed for organizations developing, providing or using AI. Actual applicability, risks and the AIMS boundaries depend on each organization’s scope and activity.

Is ISO 27001 certification enough for an AI Management System?

No. Information security controls may support the AIMS, but AI introduces broader questions about system outputs, impact, oversight and lifecycle governance. Certification scopes are not interchangeable.

Are NIST AI RMF and ISO/IEC 23894 mandatory certification criteria?

Not automatically. They provide complementary guidance. The relevant ISO/IEC 42001 requirements and applicable contractual or legal obligations remain the basis for conformity assessment.

Can an auditor issue a nonconformity because the AI culture seems weak?

Not merely on a subjective impression. A nonconformity needs objective evidence linked to an unmet applicable requirement. Cultural concerns can guide investigation but cannot replace audit criteria.

Authoritative references: ISO/IEC 42001:2023 official overview, ISO/IEC 23894:2023 AI risk management, NIST AI Risk Management Framework Core, and NIST Generative AI Profile. These resources inform preparation but do not replace the normative standard.

Prepare to discuss your management system and audit objectives? Contact Shark Certification to discuss organizational needs and the relevant service scope. If ISO/IEC 42001 certification is required, independently confirm the proposed certification body’s service availability and accreditation scope. Effective AI governance is demonstrated through decisions, controls and evidence—not a policy document alone.