14.1 Establishing & Implementing an Audit Program

14.1 Establishing & Implementing an Audit Program

Managing individual AIMS audits well is necessary but not sufficient. Domain 7 of the PECB ISO/IEC 42001 Lead Auditor competency model asks you to manage an audit program—the portfolio of audits that, over time, gives management or a certification body (CB) confidence that the Artificial Intelligence Management System (AIMS) remains suitable, adequate, and effective.

ISO 19011:2018 Clause 5 provides the core guidance for establishing, implementing, monitoring, reviewing, and improving an audit programme. ISO/IEC 17021-1 adds mandatory requirements when the programme is a third-party management-system certification programme. This section focuses on establishment and implementation for AIMS contexts.

---

Audit programme vs audit plan (do not mix them)

Exam trap: “Write the audit plan for the year” when the question asks about the programme. Programme = multi-audit governance. Plan = one engagement.

     AUDIT PROGRAMME (ISO 19011 Cl. 5) — AIMS
┌──────────────────────────────────────────────────────────┐
│  Objectives │ Extent │ Responsibilities │ Procedures     │
│  Resources  │ Schedule │ Risk-based prioritization       │
├──────────────────────────────────────────────────────────┤
│  Audit A (internal Q1)  │ Audit B (Stage 2) │ Audit C   │
│  each has its own audit plan, team, report, follow-up    │
└──────────────────────────────────────────────────────────┘

---

Applying PDCA to the AIMS audit programme

ISO 19011 structures programme management with a Plan–Do–Check–Act loop:

1. Plan — establish objectives, extent, responsibilities, resources, procedures, and risk-based schedule.
2. Do — implement: select teams, initiate audits, conduct audits, report, follow up.
3. Check — monitor schedule attainment, NC closure, auditor performance, auditee feedback, and whether objectives are being met.
4. Act — improve the programme (competence, methods, sampling focus, remote techniques, combined audits).

For AIMS, PDCA must keep pace with AI product velocity. A programme designed only around annual policy reviews will lag behind quarterly generative-AI launches.

---

Objectives of an AIMS audit programme

Programme objectives differ slightly by context but always answer: What confidence do stakeholders need from this set of audits?

Internal (first-party) programme objectives

Aligned with ISO/IEC 42001 Clause 9.2 and management needs:

• Determine whether the AIMS conforms to the organization’s own requirements and to ISO/IEC 42001
• Confirm the AIMS is effectively implemented and maintained
• Provide input to management review (Clause 9.3) and improvement (Clause 10)
• Cover processes, locations, and AI systems on a risk-based cycle so that high-impact systems are not permanently unsampled

Certification body (third-party) programme objectives

Aligned with ISO/IEC 17021-1 and the CB’s scheme:

• Obtain sufficient objective evidence to support certification, surveillance, and recertification decisions
• Maintain impartiality and competence across the certification cycle
• Ensure the certified AIMS scope remains accurate as AI systems change
• Address special audits when significant changes or complaints arise

Second-party programmes

Customers may run supplier AIMS programmes against contracts, Annex A.10 themes, and selected ISO/IEC 42001 requirements (onboarding, periodic reassessment, or incident-driven deep dives).

Worked internal objective: “Each year audit all mandatory AIMS processes (Clauses 4–10) at least once; sample every high-risk production AI system’s impact assessment, monitoring, and change control at least once every 18 months; verify major NC closure by due dates.”

---

Extent of the programme: size and complexity of the AI estate

Extent means how broad and deep the programme must be—number of audits, frequency, methods (on-site, remote, hybrid), and coverage of organizational units, processes, and AI systems.

Factors that expand extent include number and diversity of AI systems, risk/impact profile, lifecycle complexity (internal training vs foundation-model APIs), multi-cloud footprint, third-party AI relationships (Annex A.10), integration with ISMS/PIMS/QMS, prior audit history, and change velocity (releases, M&A).

A startup with one low-risk chatbot needs a lighter programme than a bank with twenty production decisioning models. Risk-based thinking—not equal checklist rotation—drives extent.

---

Roles: programme manager vs audit team leaders

Exam trap: The person who “leads Stage 2 next week” is the team leader for that audit. The person who decides “we need three internal AIMS audits and one supplier AI audit this year, and who is competent for generative AI” is the programme manager (titles vary: CAE, AIMS internal audit lead, CB scheme manager).

Independence still applies: programme design should prevent self-review (e.g., the ML platform owner should not be the only auditor of their own pipeline under Clause 9.2).

---

Procedures that make the programme operable

For CBs, procedures must also satisfy ISO/IEC 17021-1 (application review, team appointment, certification decisions, impartiality).

---

Scheduling: initial certification, surveillance, special audits

Internal schedule

• Map audits so that over a defined period (often annual, multi-year for large estates) all AIMS processes and significant AI risks receive coverage
• Front-load high-risk systems and areas with weak prior results
• Align timing with management review, major product launches, and external certification windows

Certification-body schedule (typical)

  Year 0: Stage 1 (readiness) → Stage 2 (implementation/effectiveness)
          → Certification decision (certificate typically 3 years)
  Year 1: Surveillance 1
  Year 2: Surveillance 2
  Year 3: Recertification (before expiry) → new 3-year cycle
  Any time: Special audit (major change, complaint, serious incident)

Stage 1 / Stage 2 establish initial certification confidence. Surveillance maintains confidence between recertifications, sampling portions of the AIMS and focusing on change, effectiveness, and prior findings. Special audits respond to triggers such as major AI product launches, mergers that absorb new model estates, significant scope expansion, or serious AI incidents—not on a fixed calendar alone.

Implementing (the “Do” phase)

Implementation means the programme is not a slide deck: management (or CB) approves objectives and schedule; resources are assigned; each audit is initiated with defined objectives, scope, and criteria; teams are appointed with AIMS-relevant competence; audits are conducted and reported; and follow-up is tracked at programme level.

---

Establishing checklist (memory aid)

Confirm purpose (internal / CB / supplier); define objectives; set extent from AI estate risk; assign programme manager vs team leaders; approve procedures; build a risk-based multi-audit schedule (Stage 1/2, surveillance, special, Clause 9.2); authorize audits only when competence and access are feasible. Weak establishment produces ad hoc firefighting; strong establishment gives every AIMS audit clear purpose, priority, and authority—what Domain 7 expects you to design and defend.