Running an ISO 42001 Internal Audit Programme With a Small Team

It usually arrives as a calendar entry. Your certification body confirms the stage 2 date, or the first surveillance visit, and the draft audit plan lands with a line reading "Clause 9.2 — internal audit programme, audit reports, auditor competence and impartiality". You have an AI policy, a Statement of Applicability, an AI system inventory and a risk register. What you may not have is evidence that somebody impartial has tested whether any of it happens in practice.

In a mid-size organisation the AI governance function is often one person, plus a part-time DPO and a sympathetic engineering lead. That person wrote the SoA and chaired the risk workshops — and cannot audit their own work. This guide covers running a defensible internal audit programme under ISO/IEC 42001 with a small team.

What clause 9.2 actually asks for

There are two halves. Clause 9.2.1 requires internal audits at planned intervals to determine whether the AI management system conforms both to your own requirements for it and to the requirements of the standard, and whether it is effectively implemented and maintained. That first limb matters: your own policies and SoA commitments are audit criteria alongside the clauses. If your procedure says an impact assessment precedes deployment and one did not, that is a nonconformity.

Clause 9.2.2 requires a programme — frequency, methods, responsibilities, planning requirements and reporting — informed by the importance of the processes concerned and by previous audit results. It also requires defined criteria and scope for each audit, auditors selected to ensure objectivity and impartiality, results reported to relevant management, and documented information retained as evidence. So there are two artefacts: the forward-looking programme, and the records of each audit. Small teams routinely produce the second and never write the first.

Worth knowing what is not required: auditing every clause annually, using an accredited firm, or holding a lead auditor certificate. Competence and impartiality are required; a certificate is not.

Who is responsible for what

• Top management is accountable for the effectiveness of the AI management system and for resourcing the programme, and receives audit results as a required input to management review (clause 9.3).
• The audit programme owner — usually the AI governance or compliance lead — plans the programme, assigns auditors and retains records. They may not audit their own work.
• The auditor gathers evidence against defined criteria, records findings and classifies nonconformities. They do not design the fix or own the corrective action.
• The process owner owns correction, cause analysis, corrective action and evidence of effectiveness under clause 10.2.
• The certification body audits your management system under its own accredited procedure. It does not perform your internal audit, and its findings do not discharge clause 9.2. Bodies operating to ISO/IEC 17021-1 are restricted from providing internal audits and consultancy to organisations they certify; confirm the position with yours.

One distinction that gets muddled in board papers: ISO 42001 certifies a management system within a declared scope, not that a model is accurate, unbiased, safe or lawful. Your auditor tests whether you have and follow processes for impact assessment, data provenance, validation, deployment approval and monitoring. They do not re-run your evaluations.

Designing a programme a small team can actually run

Two choices make the difference. First, spread the programme across the certification cycle rather than attempting an annual full-scope audit — cycle length, surveillance frequency and audit duration are set by your certification body under its accreditation rules, so build around the cycle it confirms. Second, slice vertically: trace one real AI system end to end rather than marching through Annex A control by control, since one traced system touches impact assessment, data, lifecycle, logging and supplier terms at once.

Audit slice	Primary criteria	Evidence to pull	Who must not audit it
Scope and governance	Clauses 4–5; Annex A policy and internal organisation controls	Scope statement, AI system inventory, defined roles, records of concerns raised	Whoever drafted the scope or AI policy
One high-impact system, end to end	Annex A impact assessment, lifecycle and data controls	Impact assessment, design records, V&V results, data provenance, deployment sign-off, event logs	The system owner and whoever performed the impact assessment
Third-party AI and internal use	Annex A third-party, customer and responsible-use controls	Contracts, documented allocation of responsibilities, intended-use statements, records of off-purpose use	The procurement or contract owner
Operation, change and incidents	Clause 8; clause 10.2; monitoring controls	Monitoring outputs, incident records, change approvals, corrective action records	The operations owner
Risk treatment and SoA	Clause 6.1 and the Statement of Applicability	Risk assessment, treatment plan, SoA justifications and implementation status	Whoever maintains the SoA

Across the cycle, cover every requirement and every applicable control at least once, weighted towards higher-risk systems and areas with previous findings. If you already run an ISO 27001 programme, combine the visits — one auditee session, two sets of criteria — but do not assume information security evidence discharges the AI-specific requirements.

Impartiality when everyone does everything

• Cross-audit between functions: engineering audits governance, governance audits operations. Record who audited what.
• Pair a competent auditor from elsewhere in the business with an AI subject-matter expert. The expert advises on what the evidence means; the auditor audits.
• Contract an independent auditor — permitted, but check they are not your certification body and hold no consultancy stake in what they examine.
• Set up a reciprocal arrangement with a peer organisation under a confidentiality agreement.
• Where the team cannot be split, separate by activity: whoever did the work does not audit it, and top management records that independence judgement.
• Write the impartiality reasoning into the programme. Asserting "auditors were impartial" without saying how is a finding waiting to happen.

Where small programmes go wrong

The most common failure is auditing documents rather than practice. Reading the impact assessment procedure proves the procedure exists; pulling the last three deployments and checking whether an assessment preceded each one proves the system works. Close behind is the internal audit report raising no nonconformities at all. In a first-year management system, that reads as a programme which did not look hard — and external auditors treat it that way.

Other recurring problems: corrective action recorded as correction only, when clause 10.2 also requires eliminating the cause, checking whether the nonconformity exists elsewhere and reviewing effectiveness; audits that slip and are then dated as though they happened; a scope statement never tested against actual AI use, so embedded or procured tools sit outside the declared boundary; and audit results that never reach management review.

Limits, and when to take advice

An internal audit programme is a conformity mechanism for a management system; neither it nor certification discharges legal duties. Data protection duties sit with controllers and processors under UK and EU GDPR; EU AI Act duties sit with providers, deployers, importers and distributors according to role. A certificate alters neither. The penalty ceilings are up to 7% of global annual turnover for prohibited AI practices, up to 3% for most other AI Act obligations, and up to 4% under UK and EU GDPR.

Be careful about claims that ISO 42001 satisfies the AI Act's quality management system requirement for high-risk providers. Harmonised standards are still being developed and no presumption of conformity flows from ISO 42001 today; treat any mapping you produce as your own reasoned argument, not a settled position. Similarly, what your certification body accepts as clause 9.2 evidence is governed by its own accredited procedure. Ask, rather than assuming.

Take specialist advice where your role classification is uncertain — particularly where putting your name on a system, substantially modifying it or changing its intended purpose could turn a deployer into a provider; where AI is used in employment, biometric, safety-regulated or health contexts; or where an audit uncovers a possible personal data breach or reportable serious incident. At that point it stops being an audit finding and becomes a notification decision with clocks attached.