Writing an Audit Plan, Scope and Criteria for an AI Management System
An audit plan is your roadmap for a specific audit activity. It differs from the audit programme (which covers a year) in that it details one or more audits you will conduct in the coming weeks. A well-written audit plan saves time during the audit itself and ensures the auditor and auditee understand what will be examined. An audit plan also creates evidence that the audit was planned systematically, which matters to certification auditors.
An audit plan must start with scope. Scope for an individual audit states which systems, departments, processes or controls you will examine. A scope might be “internal audit of AI risk assessment practices across the data science team, covering systems deployed in production in the past 12 months.” Alternatively, scope might be “internal audit of Clause 7 competence and awareness for all personnel with AI governance responsibilities.” Scope sets expectations so that the auditee does not feel blindsided and knows what to prepare.
Scope must also state what is explicitly excluded. If you are auditing only deployed systems, say so. If you are auditing Clause 9 monitoring but not Clause 10 corrective action, document that boundary. Exclusions prevent misunderstanding and protect against later disputes about whether a control should have been examined.
The plan must identify criteria. Criteria are the standards against which you will judge conformity. The primary criterion is ISO/IEC 42001 itself. Your plan might state: “Conformity will be assessed against ISO/IEC 42001 clauses 6, 8 and 9.” You might also include secondary criteria such as relevant EU AI Act articles if your organisation is subject to the Act, or internal policies that go beyond the standard. If your organisation has documented a policy that all model changes require sign-off within 24 hours, that policy becomes an audit criterion too. Explicit criteria prevent auditors from inventing standards as they go.
The plan must identify the auditor or audit team, their competence and any potential conflicts of interest. If an auditor has worked closely with a particular model development team, that relationship is a conflict. Document it and either mitigate it or assign a different auditor. The plan should also state the audit’s objective in concrete terms. “Verify that all deployed AI systems have model documentation meeting Annex A.4.1” is a concrete objective. “Check whether AI systems are working” is vague. Concrete objectives guide auditors and allow management to assess whether the audit succeeded.
The plan must include sampling strategy. Sampling strategy states how you will select evidence to examine. Will you audit all approved systems or a statistical sample? Will you interview all relevant staff or targeted individuals? If you have 20 deployed AI systems and cannot audit all 20, a sampling strategy might be: “Stratified random sample of 5 systems, including at least one high-risk system.” If you have 50 data scientists, a sampling strategy might be: “Interview a cross-section: two senior data scientists, three mid-level engineers, two junior staff and one from each operational team.” A documented sampling strategy ensures the auditor is not arbitrary about what evidence is examined.
The plan must identify scheduling. Schedule states which weeks the audit will occur, how many days it will take, and when the opening and closing meetings will happen. Realistic scheduling prevents rushing through evidence examination or cutting the audit short. A hurried audit produces superficial findings; an overly long audit exhausts resources without adding value.
Finally, the plan should identify resources: which documents the auditor will need beforehand, which systems they need access to, and whether they will need quiet space to work or time for interviews. This preparation phase is often overlooked but saves hours during the audit itself. When auditors arrive unprepared, they waste time searching for information that could have been provided in advance.
A well-developed audit plan also sets expectations clearly so that misunderstandings do not arise mid-audit. For example, if the auditor plans to examine only production systems and not development or pilot systems, that should be stated in the plan. If the audit will not examine compensation structures or hiring practices (even though they might relate to bias), that should be stated. Clarity prevents situations where the auditee feels ambushed by questions about areas they thought were out of scope.
The audit plan is also a communication tool for obtaining approval and resources. It should be shared with management and the auditee well enough in advance that objections can be raised and resolved. If an audit plan calls for interviews with the CEO and they will be unavailable during the planned audit window, better to discover that when the plan is shared than to discover it when the auditor arrives.