Common ISO/IEC 42001 audit nonconformities and how to avoid them

Why nonconformity is an evidence problem

ISO/IEC 42001 is a management system standard. It specifies requirements for establishing, implementing, maintaining and continually improving an AI management system (AIMS). A nonconformity is the non-fulfillment of a requirement. General ISO auditing guidance adds two points that matter for preparation: without audit evidence there is no nonconformity, and the auditor must identify the specific requirement that was not met.

This changes how a compliance team should prepare. A policy that exists but cannot be tied to operating records invites a finding, because the organization has stated a requirement for itself and cannot show it was fulfilled. The practical test for every documented control is a pair: the requirement, and the evidence an auditor could inspect to confirm it operated during the audit period.

The same guidance says evidence should be recorded in enough detail for the audited organization to find and confirm what the auditor observed. Apply that standard to your own records. If your team cannot locate an artifact quickly, treat it as missing.

Scope, inventory, risk and impact assessment

Clause 4 and planning requirements are where weak foundations show first. An unclear AIMS scope is a common root cause because everything downstream depends on it: which AI systems are covered, which roles apply and which controls are relevant. Auditors will expect the scope statement to match what they find in the organization. An AI system in production that is absent from the scope or the inventory is a likely finding.

Preventive practice: maintain one AI system inventory with a named owner and a defined update trigger, such as procurement, deployment or material change. Reconcile it against actual usage, including AI features embedded in purchased software and tools adopted by individual teams. Expected evidence is the inventory with change history and the reconciliation record.

Risk and impact assessments fail in a different way. They exist but were completed once and never refreshed, or they cover some systems and not others. A typical risk method combines estimated impact and likelihood into a score on a defined scale. Whatever method you choose, show that it was applied to each in-scope system, that the impact assessment is linked to the same inventory entry, and that reassessment follows changes. Expected evidence is dated assessments, approvals, and the decisions that followed from them. This work is organizational. No runtime control substitutes for performing the assessment.

Annex A controls, operation, oversight and third-party AI

The statement of which Annex A controls apply, and why, is the center of many findings. In the ISO/IEC 27001 context, the Statement of Applicability is described as one of the most common root causes of audit findings, along with policies no one reads, processes no one owns, and evidence produced only for audit season. That is an analogy, not 42001 evidence, but the failure mode transfers. For each applicable Annex A control, record the justification, the owner, how it is implemented and how effectiveness is assured. For each excluded control, record the reason.

Operational control, human oversight and monitoring are where documented intent most often outruns records. Auditors will look for evidence that a control ran on actual AI use, not only that a procedure exists. Set and document monitoring and review frequency, and set a retention policy for test and evaluation history. Keep records of who reviewed what, what was decided and what changed as a result.

Some of this evidence can be generated by the system itself. Trussed enforces policy in the execution path across models, agents, tools and MCP servers. Each individual interaction or tool call is allowed, redacted, blocked, rate limited or escalated for human approval at runtime, not reviewed after the fact. Enforcement produces audit-ready evidence of those decisions, with configurable retention and data residency in a self-managed deployment. That can support records of operational control and human approval at the level of individual interactions. It does not define your oversight roles, assess risk or replace management review, and it does not deliver certification.

For third-party AI, auditors will expect due diligence and contracts to be on file. Keep contracts, terms of service, third-party audit reports, testing results and verification of third-party security audits. Calls to third-party models can be subject to the same runtime policy as internal ones, but vendor selection and review remain process activities.

Internal audit, management review and corrective action

Performance evaluation and improvement clauses are where organizations discover their other gaps, or fail to. In the 27001 context, internal audit and management review are the mechanisms that validate control selection and effectiveness. Assign owners to both for the AIMS and keep their records. Define what effective means for key controls, then have internal audit test operation, not only documentation. An internal audit that reads policies but samples no operating records will not surface the findings an external auditor will raise.

When a finding does occur, ISO auditing guidance expects three things: correction, cause analysis and corrective action. The auditor checks whether the cause was systematic or accidental, whether it lay outside what the management system covers, and whether the corrective action creates further problems. Effective corrective action eliminates the cause and prevents recurrence. A fix that only patches the single instance, such as adding one missing inventory entry without changing how entries are created, is likely to repeat. Verify each corrective action after implementation and keep the verification record.

Which evidence comes from runtime enforcement and which from process

Use this split to decide where to invest before an audit. Runtime enforcement evidence covers what happened to individual interactions and tool calls. Everything that requires judgment, accountability or review stays with the organization.

• Operational control records: Runtime: dated records of allow, redact and block decisions on individual interactions. Process: deciding which controls apply and why.
• Human oversight: Runtime: escalation for human approval and its outcome on a given tool call. Process: defining oversight roles, authority and competence.
• Monitoring: Runtime: continuous enforcement evidence for interactions in the path. Process: setting monitoring frequency, reviewing results and acting on them.
• Risk and impact assessment: Process: performing, approving and refreshing assessments. Enforced policy can apply the resulting decisions but cannot make them.
• Third-party AI oversight: Runtime: policy applied to calls into third-party models and tools. Process: contracts, due diligence and review of vendor audit reports.
• Internal audit and management review: Process only: owners, schedules, findings and corrective action records.