ISO 42001 audit readiness — the controls that fail most often

The auditor arrives with the standard, your Statement of Applicability, your AIMS documentation, and a list of the AI systems you have declared in scope. Their job is to verify three things in sequence: that the management system is documented, that the documented processes are operating, and that the records prove operation.

Stage 1 is documentation review. The auditor reads your policies, procedures, risk assessment process description, and Statement of Applicability. They identify gaps in the documentation — clauses without policies, controls flagged as applicable without an implementation description, references to procedures that do not exist. Stage 1 produces a list of areas to examine in detail at Stage 2, and a judgement on whether the organisation is ready for the certification audit.

Stage 2 is implementation audit. The auditor walks through your declared AI systems and asks for evidence that the documented processes operated for those systems. They sample. They pick three or four systems, ask for the risk register entries, the management review records, the change history, the training records, and the monitoring outputs. If the sample passes, the certificate is recommended; if it fails, findings are raised.

The auditor is not testing whether your AI is safe. They are testing whether your organisation has the records to prove that you assessed whether it was safe — and that you keep assessing it as it changes.

This framing — process and evidence rather than system behaviour — is what most organisations get wrong in their first audit. They prepare as if the auditor will review the AI systems. The auditor reviews the management system around the AI systems. The artefacts that matter are the management artefacts: the register, the triggers, the gates, the reviews, the records.

The findings raised in ISO 42001 audits fall into five recurring categories. They are not equally severe — but they are equally predictable. An organisation that closes all five before the audit has a much higher chance of a clean certification cycle.

The remainder of this piece treats each gap in turn: what it looks like in practice, how an auditor surfaces it, what the standard requires, and how to close it before the audit team arrives.

The single most common finding in ISO 42001 audits is an AI risk register that does not contain enough information to evaluate the risks it lists. Clause 6.1.2 of the standard requires an AI risk assessment process; in practice, the auditor instantiates this requirement by asking a simple question.

What the auditor typically receives is one of three things. The first is a category list — a generic enumeration of AI risks (prompt injection, hallucination, bias, data leakage) that could apply to any system. The second is a partial register — five risk entries for a system that the threat model shows has fifteen attack paths. The third is a register that exists but is not connected to anything else: no link from controls, no link from DPIAs, no link from management review records.

A risk register that holds up to audit has five fields populated for every entry. The fields are not exotic. They are the minimum required to reason about a risk and to evidence that you have reasoned about it. The table below summarises them.

The deeper problem behind incomplete registers is that they are often produced once, for an internal audit or a procurement question, and then frozen. Clause 9.1 of ISO 42001 requires monitoring and measurement; clause 8.5 requires lifecycle management. A register frozen at the date of its first creation fails both clauses simultaneously — which is why this gap so often produces a major nonconformity.

The second most common finding is closely related to the first. Even when a risk register exists in workable shape, it is rarely connected to a set of named re-assessment triggers. The auditor reads the register, reads the control plan, reads the change log — and finds that nothing in the documentation names what would trigger a re-review.

ISO 42001 clause 9.1 requires the organisation to determine what needs to be monitored and measured, the methods, and the frequency. Clause 8.5 covers lifecycle management for AI systems. Together they imply that you must know when a system has changed enough to require a fresh review — and you must record that you did the review. A register dated months ago with no monitoring outputs, no review records, and no named triggers is evidence that neither clause is operating.

A risk register without a re-review trigger is a snapshot. A snapshot of an AI system is out of date the moment the model provider ships a new version, the upstream data source schema changes, or the user population shifts.

Named triggers tend to fall into four classes, and the auditor will expect to see at least one trigger per class for each in-scope AI system:

• Model triggers. A change in the model provider, the model family, the model version, or a configuration that affects determinism (temperature, sampling, safety settings). These are the triggers most organisations forget — model providers ship silent updates routinely.
• Data triggers. A change in the training data source, the retrieval index contents, the fine-tuning corpus, or the data classification of any source feeding the system.
• Surface triggers.Addition or change of tools in an agent's tool manifest, a change to the autonomy level, a change to the user population, or a change to the integration boundary.
• Incident triggers. Any AI-specific incident, a near miss, a complaint that mentions the AI behaviour, or a regulator enquiry that touches the system.

The trigger list is meaningless without an owner. Each trigger needs a named role accountable for noticing the trigger, raising it, and initiating the re-review. The most common implementation puts the trigger list at the bottom of the risk disposition memo with a single owner — typically the AI governance lead — and a quarterly cadence for asking each system owner whether anything on the trigger list has fired.

The third gap is where the auditor and the engineering team most often miscommunicate. The control plan says, in plain language: “Output filter implemented for sensitive data categories.” The auditor asks for the artefact behind that statement. The engineering team produces a screenshot of the configuration, or a paragraph from the design document, or — most commonly — nothing.

The pattern is consistent. A control gets described in the control plan because someone wrote a sentence about it. The sentence is true on the day it is written. Three months later the auditor arrives and asks: when was the filter last tested, what was the result, who reviewed it, and what would have happened if it had failed. The engineering team has the filter — it is in production, it does work — but no record of any of those four things exists.

Closing this gap is mechanical but tedious. For every control on the plan, you need at minimum:

• A verification artefact — a test result, an exported configuration, a log sample, or a signed attestation from the implementing team.
• A verification date and the name of the person who performed it.
• A verification cadence — how often the control is re-verified, and what triggers an off-cycle verification.
• A retention statement — how long the verification record is kept and where it lives.

Some controls are verified by their nature — a configuration export from a production system is its own evidence. Others require explicit test cases — an output filter is only as good as the inputs you tested it against. The control plan should make the distinction clear and should not state that a control is implemented unless one of the two evidence types exists.

The fourth gap appears whenever the documented lifecycle and the actual deployment history disagree. The AIMS policy describes how systems progress through review gates — typically a design review, a pilot review, and a go-live review. The procedure attached to the policy describes who signs off at each gate and what the gate requires. On paper, the process is clean.

The auditor then asks for the gate sign-off records for a system the organisation has declared in scope. The records are missing, or they exist but are dated after the production deployment, or the named approver does not match the role specified in the procedure. The gap is not a process gap — it is an enforcement gap.

A lifecycle gate that does not block deployment is a documentation exercise. The auditor cannot distinguish between a process that operates and a process that is written down but routinely bypassed.

Enforcement does not require automation. It requires a record that the gate was reached, the named approver assessed the gate criteria, and the decision was recorded with a date. The simplest enforcement mechanism is procedural: the system cannot be deployed to production until a signed go-live review document exists, and the document carries the date of the deployment authorisation.

The auditor will look at this in two ways. First, they will sample systems and ask for the gate records. Second, they will ask the engineering team how a deployment actually happens and compare the answer to the procedure. When the answers do not match — when the procedure says the AI Committee signs off but the engineer says they merge the PR and CI deploys — the gap is recorded as a finding against clause 8.1 or 8.4 of the standard.

For organisations that struggle with this gap, the most useful intervention is to treat the gate record as the deployment authorisation itself. There is no separate deployment ticket — the signed go-live review is the ticket. This collapses the procedural step and the enforcement step into a single artefact, and removes the common pattern of going live first and producing the gate record afterwards.

Clause 9.3 of ISO 42001 requires top management to review the AIMS at planned intervals. The review must consider a defined set of inputs — performance of the management system, results of monitoring, incident and complaint history, status of previous management review actions, changes that affect the system, opportunities for improvement — and produce defined outputs, namely decisions and actions.

The gap appears in two forms. The first is review records that are missing for systems deployed before the current management review cycle. A system that went live in February is in scope for the next annual review; if the annual review was held in March and did not reference the new system, the review is incomplete.

The second form is reviews that took place but were recorded as attendance. The minutes say: “The AI portfolio was reviewed. No issues raised.” The auditor reads the minutes, then reads clause 9.3, then asks: which inputs were considered, which decisions were taken, which actions were assigned, and which previous actions were closed. The minutes cannot answer any of those four questions, because they record presence and not substance.

Management review records are also the artefact that most often reveals other gaps. If the review does not discuss any incidents, the incident log is missing. If the review does not reference monitoring outputs, the monitoring plan is not operating. The auditor uses the review record as a cross-check against the rest of the management system — which means a thin review record opens a number of related findings rather than just one.

The five gaps are not difficult to close. They are tedious. They require sustained attention to the records rather than to the system itself, and they require the documentation team and the engineering team to work in the same evidence model. The sequence below is the one that produces the highest closure rate for organisations preparing for a Stage 2 audit.

1. Populate the risk register with all five fields per entry.Pick a top-priority system. Walk through every entry. If any of the five fields is missing, add it or remove the entry. Generic entries should be replaced with system-specific ones; entries with no controls should either get controls or be moved to a separate “accepted without controls” section with the residual risk acceptor named.
2. Name the re-assessment triggers and the owner. Add a trigger list at the bottom of every disposition memo. Aim for at least one trigger from each of the four classes — model, data, surface, incident. Assign a single owner per system who is responsible for noticing trigger events and initiating the re-review.
3. Replace descriptions with artefacts.Walk through the control plan. For every control marked implemented, attach a verification artefact (test record, configuration export, log sample, signed attestation) and a verification date. Where no artefact exists, mark the control as “planned” rather than implemented and add it to the action plan with a date.
4. Reconcile lifecycle policy with deployment practice. Ask the engineering team how a system actually moves from development to production. If the answer does not match the AIMS procedure, fix the procedure first and then close the enforcement gap by ensuring no deployment goes live without the signed gate record.
5. Re-run management review with the right inputs.Run a fresh review meeting that addresses each of clause 9.3's required inputs in turn. Record the discussion, the decisions, and the actions. If your last review minute is thinner than this, do another review and produce a minute that the auditor will accept.

Each of these steps is a few days of work per in-scope system. The hard part is not the work itself — it is the sequence. If you fix the risk register but not the re-assessment triggers, the register is out of date again within a quarter. If you fix the control plan but not the gates, the controls are not actually enforced. The steps reinforce each other; doing one without the others tends to leave the gap open in a different form.

The audit produces findings. ISO 17021 — the standard that governs how certification audits are conducted — defines three categories of finding, and the certification decision depends on which categories are observed and how many.

• Observations. Things the auditor flagged that are not nonconformities but could become one. No corrective action required for certification. Often used to highlight weak evidence that is still compliant.
• Minor nonconformities. Specific lapses in evidence or records, but the management system is operating. The certification body accepts a corrective action plan and expects the lapse to be closed within an agreed period — typically thirty to ninety days. Certification proceeds.
• Major nonconformities. A clause of the standard is not being met systemically, or a process is absent, or the evidence is so thin that the auditor cannot conclude the management system operates. A major typically prevents certification this cycle. The organisation is expected to remediate and re-audit.

Of the five gaps in this piece, the first two — incomplete risk registers and missing re-assessment triggers — are the ones most likely to produce a major nonconformity. The remaining three usually appear as minors. Two minors in a cluster (for instance, evidence-by-description plus management review gaps in the same audit) can be escalated to a major at the auditor's discretion if they reflect a systemic weakness.

The certificate does not record the findings. It records that the management system was found to conform. Buyers who care about the substance of your AIMS will ask for the audit report, not the certificate.

For organisations using the certificate in procurement, this distinction matters. The certificate is a binary signal — you have one or you do not. The audit report is the substantive signal — it tells a buyer whether your management system was judged mature or whether it scraped through with a list of minors and a corrective action plan. Buyers with security maturity will ask for the report; buyers who only ask for the certificate will accept it without further questions.

Most organisations underestimate how long ISO 42001 preparation takes. The typical timeline from “we want to certify” to “Stage 2 audit complete” is six to twelve months for an organisation with a partially mature security management system already in place. Organisations starting without ISO 27001 or an equivalent should plan for twelve to eighteen months.

The trap is engaging the certification body too early. There is a strong incentive to lock in dates because audit slots can be scarce; the cost of pulling the audit forward, only to fail Stage 2 because the evidence is not ready, is high — both in fees and in the organisational morale damage of a public failure. The cleaner approach is to engage internally first, run an internal audit against the standard, close the findings, and only then engage the certification body.

Three checkpoints help calibrate readiness before contacting the audit body:

• Risk register completeness. Every in-scope AI system has a register with all five fields populated, named re-assessment triggers, and at least one trigger that has fired and been actioned in the past quarter. The last point is important: an unfired trigger list looks suspicious, because real systems generate trigger events.
• Control plan evidence ratio. The percentage of controls marked implemented that have an attached verification artefact. An audit-ready evidence ratio is 100 percent. Anything below 80 percent will produce findings; anything below 50 percent will likely produce a major.
• Management review substance. At least one management review minute set that addresses every clause 9.3 input, names decisions and actions, and closes previous actions. A single substantive review is usually enough; a sequence of attendance minutes is not.

A pre-audit gap analysis — either internal or via an independent advisor — that confirms these three checkpoints is the right precondition for engaging the certification body. The cost of the gap analysis is a fraction of the cost of a failed Stage 2 audit, and the timeline tightening is real.

The relationship to other reading: this piece focuses on audit readiness for ISO 42001 specifically. For the upstream content — what evidence the EU AI Act Article 9 demands, and how that maps to ISO 42001 clauses — see the Article 9 evidence piece in this field-notes series. For the dispositional record that ties the register, the controls and the triggers together, see the AI Risk Disposition piece.