11.2 Determining Audit Objectives, Scope & Criteria
Key Takeaways
- Audit objectives state why the audit is done (e.g., certification recommendation support, surveillance of continued conformity, internal improvement, or supplier assurance)—they drive depth, sampling, and reporting.
- Audit scope defines boundaries: organizational units, locations, AI systems/processes, lifecycle activities, and exclusions; multi-system AI estates require explicit system-by-system or process-by-process boundaries.
- Audit criteria for AIMS are primarily ISO/IEC 42001:2023 requirements (Clauses 4–10), applicable Annex A controls per the Statement of Applicability, plus the organization’s own AIMS requirements and relevant legal/other requirements it commits to meet.
- Scope or criteria changes after agreement must be controlled, documented, and communicated; informal mid-audit expansion without agreement creates invalid findings and client disputes.
- Written agreements (plan, contract, engagement letter, Stage 1 conclusions) record the tripartite foundation of objectives, scope, and criteria before Stage 2 execution.
11.2 Determining Audit Objectives, Scope & Criteria
Quick Answer: After feasibility is confirmed, lock the tripartite foundation of the engagement: objectives (why), scope (what/where/which AI systems), and criteria (against what). For AIMS audits, criteria always include ISO/IEC 42001 requirements; Annex A is applied through the auditee’s Statement of Applicability (SoA); legal and other requirements enter when the organization has committed to them inside the AIMS. Write the agreement down before you sample models and interview engineers.
ISO 19011 treats objectives, scope, and criteria as inputs to planning. Certification practice under ISO/IEC 17021-1 similarly requires clear definition of the management system to be audited. Exam essays often fail when candidates confuse “scope of the AIMS” (organizational system boundary) with “scope of this audit engagement” (what will be examined this visit)—related, but not always identical (e.g., surveillance may sample a subset).
Setting Audit Objectives
Objectives answer: What should this audit achieve? They are not a copy-paste of clause titles. They describe outcomes for the client and auditee.
| Audit type | Example AIMS objective language |
|---|---|
| Initial certification | Evaluate conformity of the AIMS to ISO/IEC 42001 and applicable SoA controls; assess implementation and effectiveness enough to support a certification recommendation process |
| Surveillance | Confirm continued conformity and effectiveness of selected AIMS processes and AI systems; follow up prior nonconformities; sample changes since last visit |
| Recertification | Confirm overall continued conformity and effectiveness of the AIMS for certificate renewal within the certification cycle |
| Internal audit | Provide independent information to management on AIMS conformity and improvement opportunities before external audit or after major AI launches |
| Supplier / second-party | Provide assurance that a vendor’s AI services and controls meet contractual AIMS-related requirements and agreed criteria |
Certification Stage 2 needs broad clause and system sampling; internal audits may risk-focus new generative launches; supplier audits may limit criteria to the contracted service line. “Check if AI is ethical” is not an auditable objective—translate values into criteria-linked evaluation of policy, impact assessments, controls, monitoring, and improvement.
Defining Scope Carefully for Multi-System AI Estates
Scope answers: What is included and excluded? For ISO/IEC 42001, poor scope is the #1 planning failure.
Layers of scope
- Organizational — legal entities, business units, functions (R&D, product, shared MLOps, customer support using AI).
- Physical / virtual locations — offices, data centers, cloud accounts/regions, remote work.
- AI systems and processes — named systems or system classes (e.g., credit scoring models v3.x; support LLM assistant; computer-vision QC line).
- Lifecycle activities — design, data preparation, training, evaluation, deployment, operation, monitoring, retirement.
- Interfaces — human oversight teams, customers, and third-party model APIs in or out of boundary.
EXAMPLE MULTI-SYSTEM ESTATE
+------------------------------------------------------+
| AIMS organizational boundary (Corp AI Governance) |
| +----------------+ +----------------+ +---------+
| | Loan models | | HR screening | | Chatbot |
| | (in scope) | | (in scope) | | (EXCL.) |
| +----------------+ +----------------+ +---------+
| Third-party OCR vendor (in scope as supplier ctrl) |
+------------------------------------------------------+
Multi-system scoping techniques
| Technique | Use when | Risk if misused |
|---|---|---|
| Named system list | Small number of high-impact systems | Misses “shadow” AI not on the list |
| System classes + sampling rules | Large estates with many similar models | Classes too broad hide high-risk outliers |
| Process-based scope | Shared MLOps platform across products | Process existence ≠ control of each high-risk use case |
| Exclusions with justification | True non-application (e.g., pure R&D sandbox not in AIMS) | Excluding high-impact production AI to “pass” is not acceptable |
Certificate and report wording must match the agreed scope, not marketing that claims “all AI is certified.”
Changes to scope
Legitimate changes include acquisitions, retirements, multi-site sampling, or Stage 1 discovery of a material omitted system. Raise issues early, assess impact on time/competence/criteria, obtain client (and CB) agreement, and update plan/working documents/report consistently. Silent expansion without agreement invites rejected findings and contract disputes.
Audit Criteria for an AIMS
Criteria are the policies, procedures, or requirements used as a reference against which evidence is compared. For ISO/IEC 42001 Lead Auditor work, think in stacked layers:
| Layer | Content | Notes |
|---|---|---|
| Normative AIMS requirements | ISO/IEC 42001:2023 Clauses 4–10 | Cannot be “excluded” like an Annex A control; they are management-system requirements |
| Annex A controls | Controls applicable per the auditee’s SoA | Exclusions require justification; audit tests implementation of claimed applicable controls and validity of exclusions |
| Organization’s AIMS | AI policy, objectives, procedures, risk criteria, impact methods | Auditee must meet its own defined requirements where they form part of the system |
| Legal and other requirements | Those the organization has determined as applicable to the AIMS | Auditors verify the process of identification and control, not act as the regulator of record |
| Contractual criteria (esp. second-party) | Customer AI requirements, SLAs for model performance/safety | Only when included in agreed criteria |
SoA as a criteria bridge
The SoA is not a decorative appendix. It tells you which Annex A controls are in force. Your Stage 2 tests should not invent a private control set that ignores the SoA—nor accept empty justifications such as “N/A because we use AI” for a control that clearly applies.
Organizations may map sector rules or privacy law into AIMS context. Verify that obligations were identified and that controls address them as claimed—do not issue a legal opinion that the product is lawful everywhere. Findings must cite agreed criteria (42001, SoA, policy, listed regulatory expectations), not the auditor’s personal fairness metric.
Documenting Agreements
Record the tripartite foundation in durable artifacts:
- Application / contract (third-party) — high-level scope and standards
- Stage 1 report / readiness conclusions — refinements after document review
- Audit plan — operational objectives, scope, criteria, dates, sites, methods
- Opening meeting confirmation — restate and resolve last-mile misunderstandings
Internal audits use an audit program entry and a plan approved by the program manager. Supplier audits use the purchase order / MSA audit clause plus the plan.
Before fieldwork: can an outsider tell which AI systems are in scope; can the team state criteria without inventing mandatory “best practices”; do objectives match time and competence? If not, replan. Document review/Stage 1 and the audit plan then operationalize this foundation.
In an ISO/IEC 42001 audit, which statement best describes audit criteria?
A certification scope lists two production credit models, but during planning the auditee asks auditors to also “quickly check” an experimental generative system outside the certificate application. What should the team leader do first?
Which objective is most appropriate for a second-party audit of a foundation-model API supplier supporting the auditee’s AIMS?
Why is the Statement of Applicability essential when setting Annex A-related criteria for an AIMS audit?