11.4 Audit Plan, Team & Working Documents
Key Takeaways
- The audit plan converts objectives, scope, and criteria into a time-bound operational schedule covering dates, sites, team, methods, interviews, and logistics—and must be communicated to the auditee in time for preparation.
- Team selection for AIMS audits requires management-system audit competence plus sufficient AI-domain understanding (or technical experts) matched to in-scope systems, risks, and technologies.
- Responsibilities must be assigned clearly: team leader ownership of the plan and conclusions, auditors for process areas, technical experts for explanation without taking audit decisions, and guides for logistics—not for answering for process owners.
- Working documents (checklists, sampling plans, interview guides, evidence logs) should be tailored to AI artifacts—impact assessments, SoA lines, model/system documentation, data lineage, monitoring logs, human-oversight records, supplier controls—without becoming rigid scripts that ignore unexpected evidence.
- Plans and working documents are living tools: controlled updates are allowed when scope or logistics change; secrecy that blindsides the auditee on logistics is poor practice, while revealing every audit test question in advance can undermine sampling integrity if misused.
11.4 Audit Plan, Team & Working Documents
Quick Answer: When feasibility, objectives/scope/criteria, and Stage 1 readiness are in place, operationalize the engagement. Produce an audit plan, select a competent team for the AI domains in scope, assign responsibilities, prepare working documents tailored to AIMS evidence, and communicate the plan so the auditee can provide access. ISO 19011 Clauses on planning and working documents apply; certification bodies add ISO/IEC 17021-1 plan expectations.
This section is the last preparation gate before opening meetings and evidence collection (Chapter 12). A brilliant Stage 1 report is wasted if Stage 2 starts with no plan, the wrong skill mix, and a generic ISO 9001 checklist with “AI” written in the header.
Audit Plan Contents
An audit plan is the team’s operational schedule and agreement framework for a specific audit (or Stage). Typical contents:
| Plan element | AIMS-oriented detail |
|---|---|
| Objectives | Certification Stage 2, surveillance focus, internal objective, etc. |
| Criteria | ISO/IEC 42001, SoA-applicable controls, organizational/legal requirements agreed |
| Scope | Entities, sites, AI systems/processes, exclusions |
| Dates and times | Stage days, time zones for remote interviews |
| Sites / platforms | Offices, cloud environments, SOC-like monitoring rooms, vendor meetings |
| Audit team | Names, roles, contact points |
| Methods | Interviews, observation, document/record review, remote screen-share of registries |
| Schedule of activities | Process areas mapped to times and auditors |
| Logistics | Rooms, remote tools, security clearance, interpreters, NDAs |
| Sampling approach (high level) | Which systems/classes get deep dives |
| Report timing & language | Draft/final expectations |
| Confidentiality & safety | Handling of model IP, personal data in prompts, restricted labs |
Illustrative multi-day flow: opening and context → risk/impact → lifecycle and data deep dive → deployment/monitoring/oversight/third parties → performance evaluation/improvement → closing. Adjust to risk and size; keep traceability from plan lines to criteria and systems. Prefer secure read-only registry/dashboard access over screenshots alone; pair process and technical owners; book third-party sessions when foundation-model controls are critical; buffer for access failures.
Selecting Competent Team Members for AI Domains
Competence = ability to apply knowledge and skills to achieve intended results. For AIMS audits, combine:
- Management system audit competence — ISO 19011 process, evidence, findings, impartiality
- ISO/IEC 42001 knowledge — clauses, Annex A intent, SoA logic
- AI domain competence — enough to understand evidence in scope (ML lifecycle, data issues, generative systems, human oversight, evaluation metrics)
- Sector competence where needed — medical, financial, safety-critical contexts
| Team role | Function | Caution |
|---|---|---|
| Audit team leader | Plan ownership, direction, consolidation, client communication | Must have lead competence; cannot outsource conclusions |
| Auditor | Collect evidence in assigned areas | Needs enough AI literacy for assigned systems |
| Technical expert | Provide specific AI/sector knowledge to the team | Does not act as auditor of record; no independent findings without auditor evaluation |
| Translator / interpreter | Language support | Must not filter or “improve” auditee answers |
| Guide | Logistics, introductions, escorts | Must not answer for process owners or steer sampling |
| Observer | Training or CB oversight | No interference with audit |
Match skills to systems (e.g., generative chatbots need prompt/filter/transparency literacy; credit models need model-risk and drift evidence literacy). If the only auditor is an ISMS specialist with zero AI literacy, add a technical expert or reassign. Preparation also includes impartiality conflict checks for anyone who recently implemented the AIMS or systems under review.
Assigning Responsibilities
Document assignments in the plan or a team briefing note:
- Who leads opening/closing meetings
- Who owns each process cluster (e.g., Clause 6 risk/impact vs. A.6 lifecycle vs. A.10 third parties)
- Who deep-dives which AI systems
- Who consolidates findings each day
- Who manages evidence logging and confidentiality of AI artifacts
- Escalation path if access is blocked mid-audit
Team briefing before site work should cover Stage 1 concerns, high-risk systems, cultural notes, remote tool rules, and “what good evidence looks like” for AI (not only signed policies).
Working Documents Tailored to AI Artifacts
Working documents guide and record audit activities. They are tools, not prisons. ISO 19011 warns against checklists that prevent additional investigation.
Core working document types
| Document | AIMS tailoring ideas |
|---|---|
| Clause/control checklist | Map 4–10 + SoA controls to example evidence questions |
| AI system sampling plan | Population (inventory), risk ranking, sample size/rationale, backups if systems unavailable |
| Interview guides | Role-based questions for executives, model owners, data stewards, human reviewers, procurement |
| Observation guides | What to watch in human-in-the-loop queues, release meetings, incident bridges |
| Evidence/request logs | Trace requests for model cards, lineage extracts, monitoring exports |
| Finding drafts worksheets | Criteria → evidence → evaluation → classification |
| Time sheets / attendance | Support later credential hour claims where relevant |
Build guides around impact assessments, SoA vs. procedures, model/system docs, data quality evidence, evaluation results, deployment approvals, monitoring/incident records, human-oversight logs, transparency artifacts, and third-party due diligence. A Y/N “do you have an AI policy?” checklist misses effectiveness—pair presence with implementation probes. For multi-system sampling, record stratification (risk, lifecycle, tech, site), mandatory deep dives, medium-risk sample size/rationale, and fallbacks if a system is deprecated. Judgmental sampling is fine when reasoned and recorded.
Communicating the Plan to the Auditee
Communicate the plan with enough lead time for the auditee to:
- Book process owners and executives
- Arrange access to tools and rooms
- Notify third parties if joint sessions are needed
- Prepare logistics without manufacturing fake records overnight (you cannot fully prevent last-minute document creation, but surprise full schedules make chaos more likely)
What to share vs. hold back
| Usually share | Use professional judgment |
|---|---|
| Objectives, scope, criteria, dates, team names/roles | Exact detailed checklist questions that would allow gaming every sample |
| High-level agenda by process area | Confidential risk notes for the team only |
| Logistics and access needs | Internal team disagreements |
| Request for key documents/records availability | Personal opinions about individuals |
Confirm receipt and invite questions. Update the plan when the auditee reveals a site outage or a critical system owner is on leave—document the change.
Final gate: feasibility/access still holds; objectives/scope/criteria match Stage 1; plan acknowledged; competence and impartiality confirmed; working documents controlled; confidentiality briefed; sampling plan ready. Then the engagement is prepared to conduct—opening meetings and evidence collection succeed only if this preparation was real.
Which set of elements belongs in a typical ISO/IEC 42001 audit plan?
What is the correct role of a technical expert on an AIMS audit team?
Why should working documents for an AIMS audit be tailored to AI artifacts rather than only generic facilities checklists?
When communicating the audit plan to the auditee, which practice is most professional?