Your First
42001 Audit

0.1What this combines

Three standards do three different jobs in a 42001 audit, and confusing them is the fastest way to produce a report nobody can act on.

There is a fourth input that is easy to forget and is often where the sharpest findings come from: the auditee's own documents. Their AI policy, their procedures, their contractual commitments to customers. These are criteria too, under ISO 19011 clause 3.8, and an organisation failing its own stated policy is a cleaner finding than one failing a standard's general wording.

0.2The chain you never break

Five defined terms in a strict order. Every weak audit you will ever read broke this chain somewhere, usually at the first link.

0.3Are you fit to audit this?

ISO 19011 clause 7 asks this formally. Answer it honestly now, because the alternative is discovering the gap in an interview when someone explains model validation to you.

• Independence. I am independent of the activity being audited — or the conflict is documented, mitigated and disclosed to the audit client.19011 clause 4.6. In a small organisation full independence is often impossible. Manage and record it; do not declare it away.
• I know the criteria. I have read 42001 clauses 4–10 and the Annex A controls marked applicable in their SoA.Not skimmed. An auditor who has not read the criteria cannot recognise a gap against them.
• I know the method. I understand 19011's audit process and can run each of the six stages of clause 6.
• I can judge an impact assessment. I know what ISO/IEC 42005 expects one to contain, well enough to tell a real one from a template filled in defensively.
• Technical depth is covered. Either I can evaluate model development, validation and monitoring evidence, or I have a technical expert on the team who can advise me.19011 clause 3.17: a technical expert advises and does not act as an auditor. They do not raise findings; you do.
• I know the sector and its law. I understand what a wrong output costs a real person in this domain, and which regulations bear on it.
• Team competence is collective. Where I am thin, someone on the team is strong — and the plan puts them in the right interviews.

0.4Words to use precisely

Auditees mirror your vocabulary. Use these accurately from the opening meeting and the whole audit gets easier.

Step 1Confirm the assignment

Three things must be written down and agreed before anything else happens: objectives, scope, criteria. ISO 19011 clause 5.5.2. Skipping this is why audits end in arguments about whether something was in scope.

• Objectives, scope and criteria written down and agreed with the audit client
• Auditee contact confirmed, with authority to provide access
• Confidentiality arrangements agreed — including recording consent if any session is remoteAgree this before the opening meeting, not during it.
• Feasibility confirmed: enough information, cooperation, time and resource to do it properly19011 clause 6.2.3. Declaring an audit infeasible is a legitimate outcome and better than a hedged report.

Step 2Build the criteria pack

One folder. Everything you will cite a finding against, and nothing else. Assemble it before the desk review so you are reading documents against something.

• ISO/IEC 42001:2023 — full text, licensed copy
• The current Statement of Applicability, with version and dateThis is your spine. It tells you exactly which of the 38 controls are criteria for this audit.
• The AI policy and any subordinate AI policies
• AIMS procedures — risk assessment, risk treatment, impact assessment, change control, incident handling
• The AIMS scope statement (clause 4.3)
• Applicable legal and regulatory requirements, and the register that identifies them
• Customer or contractual AI commitments, if second-party
• Previous audit reports and open findings

Step 3Request documents in advance

Send this list a fortnight out. What arrives — and what does not, and how long it takes — is already evidence.

Step 4Desk review

ISO 19011 clause 6.3.1. Read before you arrive, and read to build questions rather than to form conclusions.

Read in this order

1. AIMS scope statement — what is in, what is out, and does the exclusion make sense
2. AI system inventory — how many systems, what roles, which look highest-exposure
3. Statement of Applicability — which controls apply, what justifications say, what status is claimed
4. Risk register and impact assessments — are these two distinct exercises or one wearing two labels?
5. Management review minutes and internal audit reports — is the loop running?
6. Nonconformity log — what kind of problems does this organisation find in itself?

Red flags to note now and test later

Step 5Choose the sample

You cannot audit everything, and 19011's risk-based principle (clause 4.8) says you should not try. Sampling is where a new auditor most needs a deliberate strategy rather than a checklist walked top to bottom.

Sample on four axes

Step 6Choose the method

ISO 19011:2026 clause 5.5.3, with remote auditing now a defined method (3.4) drawn from ISO/IEC TS 17012. For an AIMS this matters more than usual, because much of what you are auditing has no physical location.

A hybrid design is usually right for an AIMS: remote for the document and system evidence, on-site for the human-oversight and operational reality. Where something cannot be verified remotely, plan for it — and if it ends up unverified, the report says so.

Step 7Write the audit plan

ISO 19011 clause 6.3.2. Send it to the auditee in advance. A plan they have seen is a plan they can staff.

• Objectives, scope and criteria — restated in the plan itself
• Team members, roles, and any technical expert or observer named
• Schedule: dates, sessions, durations, who is needed in eachName roles, not people, so the auditee can allocate. Then confirm the people.
• Locations, physical and virtual; method for each session
• Opening and closing meeting times
• Communication arrangements — how potential findings will be raised during the audit
• Access needed: systems, records, people, sites; confidentiality and recording consent
• Risks to achieving the audit, and contingencies
• Reporting: format, recipients, date — treated as a commitment
• Follow-up arrangements and who verifies effectiveness

Step 8Opening meeting

Fifteen to thirty minutes. Its job is to remove every ambiguity that could otherwise surface as friction later.

Step 9Interview technique

The skill that separates a competent auditor from a checklist-reader. Four moves, in order, every time.

Handling the four answers you will get

Step 10Clause question banks

Clauses 4 to 10, with what to ask, who to ask, what evidence settles it, and the weak answer to watch for. Take these in as prompts — an auditor reading from a script finds only what the script anticipated.

Clause 4 — Context

Clause 5 — Leadership

Clause 6 — Planning

Clause 7 — Support

Clause 8 — Operation

Clauses 9 and 10 — Evaluation and improvement

Step 11Annex A — the 38 controls

Only the ones marked applicable in their SoA are criteria. Sample rather than sweep — but sample across all nine areas, because coverage is what stops you auditing only what you find comfortable.

Step 12Auditing the impact assessment

The AI-specific heart of the audit, and the part a general management system auditor is least equipped for. This is where ISO/IEC 42005 becomes your reference — not as criteria, but as the basis for judging whether what you are looking at is real.

Confirming an assessment exists takes five minutes. Judging whether it is any good is the actual work. Take one completed assessment for a high-exposure system and test it against these twelve questions.

• 1 · Is it about people, or about the organisation? Read the findings. If they are phrased as reputational, legal or regulatory exposure, this is a risk assessment wearing an impact assessment's label.The single most common substantive failure in an AIMS.
• 2 · Does every harm have a named bearer? “Risk of bias” is not a finding. “Applicants who did not attend a listed institution are ranked below their assessed performance” is.
• 3 · Are benefits there too, with who receives them? Both directions. If benefits are listed only as justification for proceeding, ask who is accountable for delivering them.
• 4 · Does it cover indirect and non-user affected parties? People who never touch the system but live with its output — and who have no relationship with the organisation and no way to complain.
• 5 · Does it address failures and reasonably foreseeable misuse? What a false positive costs the person, what a false negative costs them, behaviour when the system is unavailable, and the predictable workaround an intended user will find.
• 6 · Is human oversight assessed as it actually operates? Ask for the override rate. A reviewer who concurs 999 times in 1,000, under time pressure, without the information needed to disagree, is not oversight.Automation bias is not a model defect and no technical review will find it. It is the finding a well-run audit produces and a poorly-run one never sees.
• 7 · Is the model version named? If not, the assessment cannot be checked against what is running. If it is, check it against what is running.
• 8 · Is data representativeness addressed by segment? Not “the data was reviewed for quality” — which groups are under-represented, and what does that do to performance for them?
• 9 · Was anyone affected consulted? A user researcher, an advocacy group, a handful of structured conversations. A room of employees guessing is weak evidence, and its complete absence is worth recording.
• 10 · Did mitigations actually happen? Take three from the measures section. Find the evidence each was implemented. This is the check that most often fails.
• 11 · Is there recourse, and do affected people know it exists? How does someone contest an outcome? How would they learn they could?
• 12 · Is it still current? Check the review date. Check whether the system has changed since. Check whether the deployment has moved to a new population or jurisdiction.

Step 13Trace one system end to end

The highest-yield ninety minutes of the audit. Take one deployed AI system and follow it through every clause. This finds what reading policies never finds.

• Pick it. Highest impact rating in their own assessments, or the one changed most recently.
• Is it on the inventory? With the correct role — develop, provide, use. Clause 4.4
• Is it inside the AIMS scope? Clause 4.3
• Does it have a current risk assessment? Dated, following the documented method. Clauses 6.1.2, 8.2
• Does it have a current impact assessment? Apply Step 12. Clauses 6.1.4, 8.4
• Does the assessment name the version that is running? Ask engineering what version is in production. Compare.
• Were the mitigations implemented? Pick three. Find the evidence. Clause 6.9 of the assessment; clause 8.1
• Was it approved before deployment? Check the approval date against the deployment date. A.6.2.5
• Is validation evidence real? Disaggregated performance, not a single headline accuracy number. A.6.2.4
• Is monitoring live? Look at the actual dashboard or report, not the plan. Clause 9.1, A.6.2.6
• Has a threshold ever been crossed? If yes, what happened? If nothing happened, the control is decorative.
• What changed in the last six months? Retraining, data source, oversight step, vendor model upgrade. Clause 6.3
• Did that change trigger re-assessment? This is the question that most often produces the audit's best finding.
• What are users and affected people told about it? A.8.2, A.8.5
• If third-party: who is responsible for what, in writing? A.10.2, A.10.3
• Has there been an incident? What was communicated, and to whom? A.8.4

Step 14The evidence log

Keep it as you go. Reconstructing evidence references from memory the following week is how findings become unverifiable — and an unverifiable finding will be dismissed the moment it becomes inconvenient.

Step 15Closing meeting

Present findings in the four-part structure below. Do not soften a nonconformity into an opportunity because the room is uncomfortable — that is the failure of fair presentation (19011 clause 4.3) and it is far more costly to the audit function than a difficult ten minutes.

Equally, do not prescribe the fix. The finding states the gap; the auditee determines the cause and the action. An auditor who supplies the remedy has taken ownership of a problem that is not theirs, and has made themselves un-independent for the follow-up.

Step 16Write the findings

Four parts, every time. A finding that cannot survive being questioned costs the audit function credibility it will need later.

Worked example

Step 17Grade them

ISO 19011 does not prescribe a grading scale. Your programme should define one and apply it consistently — inconsistent grading is the fastest way for an audit function to lose authority.

Record good practice. ISO 19011 clause 3.11 allows it and almost nobody uses it. A report containing only nonconformities trains the organisation to treat audit as a threat, and an audit people defend against yields far less than one they help with.

Step 18The report

Complete, accurate, concise, clear — and on the agreed date. Findings act on decisions being made now; a report arriving weeks later arrives after them.

• Audit objectives, scope and criteria, restated
• Audit client, auditee, team, dates, locations (physical and virtual), methods used
• What was sampled — and an explicit statement that sampling means not everything was examined
• Findings, each with criterion, evidence, gap and grade
• Good practice observed
• One audit conclusion, drawn from the objectives and all findings together
• Significant obstacles, unresolved disagreements, and anything left unverified19011 clause 4.3, fair presentation. This is a requirement of the principle, not a courtesy.
• Follow-up arrangements: who acts, by when, who verifies effectiveness
• Distribution list, and confidentiality statement

Step 19Follow-up

ISO 19011 clause 6.7. The stage where internal audit programmes most reliably decay: findings raised, actions logged, effectiveness never checked.

The auditee owns the correction, the corrective action and the improvement. The audit programme verifies. And it verifies effectiveness, not completion — an action marked closed that did not work is still an open finding.

• Auditee has determined the root cause — not the instance, the cause
• Auditee has checked whether similar nonconformities exist elsewhere42001 clause 10.2 requires this. It is routinely skipped.
• Action has an owner and a date
• Effectiveness verified by evidence, at a point far enough out to mean something
• Risk register or impact assessments updated where the finding warranted it
• Verification of this finding built into the next audit's scopeThe most reliable way to stop follow-up becoming an administrative afterthought.
• Lessons fed back into the audit programme19011 clause 5.7 — the programme improves too.

4.1Common nonconformities in an AIMS

What audits of AI management systems actually turn up, roughly in order of how often. Use it to aim your sampling, never as a list of findings to go and confirm.

4.2Traps for new auditors

Being led

A skilled auditee will walk you through their best-prepared area at a comfortable pace until the time runs out. You set the schedule and you choose the sample. Say so, pleasantly, and then do it.

Accepting a plausible explanation

The single biggest difference between an experienced and an inexperienced auditor. Plausible explanations are exactly what a weak process produces, because the person has had to explain it many times. Ask for the evidence — every time, including when you believe them.

Nodding through what you did not follow

Especially with technical material, and especially when you are conscious of being the least technical person in the room. Say “I need to connect that to the requirement” and make them do it. Nobody has ever thought less of an auditor for asking; plenty of weak evidence has been accepted by auditors who did not.

Auditing the paperwork instead of the system

The characteristic AIMS failure. Policies read beautifully, procedures are complete, and nobody looked at a deployed model. Step 13 exists for this.

Going native

You spend three days with people who are working hard on something difficult, you come to like them, and the findings soften. Write the finding before the sympathy has a chance to work — draft it the evening you observe it.

Over-collecting

Forty pieces of evidence and no findings. Evidence exists to answer a question against a criterion. If you cannot say which criterion a document speaks to, you do not need it.

Confusing your role with the auditee's

You state the gap. They determine the cause and the fix. Prescribing the remedy feels helpful, removes their ownership, and disqualifies you from verifying it.

Treating the checklist as the audit

A checklist is a memory aid. The best findings in any audit come from a thread that the checklist did not anticipate — someone's aside, a date that does not line up, a version number that does not match. Leave room to follow them.

4.3Before you sign

Ten minutes with the draft report, on your own.

• Every finding cites a specific criterion I can point to
• Every finding rests on evidence a second auditor could go and verify
• No finding contains a solution I invented
• The conclusion follows from all the findings, not from the most memorable one
• The report states what was sampled and what was not
• Anything I could not verify is named as unverified
• Grades are consistent with how this programme graded last time
• Nothing was softened because the closing meeting was uncomfortable
• Good practice is recorded where I saw it
• I asked, at least once, what this system does to the people it decides about — and the report reflects the answer

4.4Sources and companion guides

• ISO/IEC 42001:2023, ISO 19011:2026 and ISO/IEC 42005:2025 on the ISO Online Browsing Platform — forewords, introductions, scopes, terms and bibliographies are publicly viewable; the requirement and guidance text is not.
• Deep reference guides in this series: ISO/IEC 42001 — the AI management system · ISO 19011:2026 — auditing management systems · ISO/IEC 42005 — AI system impact assessment.
• For third-party certification audits, requirements are in ISO/IEC 17021-1. For remote auditing method detail, ISO/IEC TS 17012:2024.