Common nonconformities in ISO 42001 audits, chapter by chapter

Anyone preparing for an ISO/IEC 42001 audit wants to know where things usually go wrong. Our audit practice shows a recognizable picture: most nonconformities sit in the management system around the AI, rarely in the models themselves. Organizations with technically solid AI stumble over vague scope statements, recycled ISMS documents and processes that only exist on paper. Below are the nonconformities we encounter most often, organized by chapter of the standard.

Chapter 4: context and scope

The classic: the organization reuses its ISMS context analysis without AI-specific content. AI regulation such as the EU AI Act, societal expectations around AI and internal factors like data quality and AI expertise are then missing. A second recurring point is that the organization has not determined its role per AI system: are you a provider, producer or deployer? Without that determination, responsibilities remain unclear. On scope (4.3) we see vague statements like "all AI activities", procured AI left out of scope and shadow AI that appears nowhere. People affected by AI decisions, such as applicants screened by an algorithm, are also often not recognized as interested parties.

Chapter 5: leadership

This chapter is about top management involvement. The nonconformity we record most often: all AI governance has been delegated to IT or the data team, without executive oversight, budget or ownership. An AI policy exists but is generic and says nothing about fairness, explainability or human oversight. Or the policy was never communicated to the teams that build the models. And there is no single point of accountability for the AIMS: responsibilities are fragmented across departments that do not coordinate.

Chapter 6: planning

Around the AI risk assessment (6.1.2) we see criteria that only consider organizational interests (financial, reputational) and skip the impact on individuals and groups. Methodologies do not account for AI-specific factors such as training data bias or model behavior that changes after retraining. Risk assessments are performed once, during initial development, and never again. In risk treatment (6.1.3) a Statement of Applicability is missing or incomplete. And the impact assessment (6.1.4) is confused with the risk assessment: there is no separate process assessing the consequences for individuals, groups and society, and reasonably foreseeable misuse is not analyzed.

Chapter 7: support

Competence requirements for AI roles are not defined: there is no competence matrix and no training evidence. Training covers technology only and skips ethics, responsible AI and regulation. Awareness stays within the data team, while it is business users who work with AI outcomes daily. In documentation (7.5) we see AI-specific documents such as model cards and data sheets that simply do not exist, missing version control and documentation scattered across personal drives and chat messages.

Chapter 8: operation

Development processes differ per team and are not documented anywhere. Models are retrained and redeployed without formal change management, so the risk assessment and the impact assessment are not updated while the system does change. Outsourced AI, such as third-party APIs and cloud AI services, falls outside governance. The operational reassessments chapter 8 requires are often skipped entirely: the assessment from the development phase is treated as a one-time exercise.

Chapter 9: evaluation

Monitoring measures technical performance only, such as accuracy and uptime, without fairness, bias or drift. There are no KPIs for the management system itself. The internal audit (9.2) checks documentation only and does not verify whether processes work; an audit programme is missing or auditors assess their own work. In the management review (9.3) top management is absent, there is no structured input package and the minutes contain no concrete decisions.

Chapter 10: improvement

Nonconformities are corrected but without root cause analysis, so they recur. The effectiveness of corrective actions is not verified. And a pattern we see often: AI incidents such as biased output are handled as technical issues, without any link to the AIMS. The lesson from the incident never reaches the management system, so the governance process that allowed the incident remains unchanged.

Annex A: three domains that stand out

In the data controls (A.7) the organization cannot demonstrate the provenance of training data, quality requirements are not defined and data preparation is not documented, making training runs impossible to reproduce. In the life cycle (A.6) model cards and technical documentation are missing, and developers validate their own models without an independent check on fairness and robustness. With third parties (A.10) AI is procured through the standard procurement procedure without AI-specific due diligence, and contracts contain no agreements on transparency, bias testing or incident notification.

The common thread

Nearly all these nonconformities share the same cause: the AIMS exists on paper, but the connection to daily AI practice is missing. The remedy is as predictable as it is effective. Before the certification audit, perform a full internal audit that does not just read documents but requests evidence: completed risk assessments, monitoring data, minutes, log files. Run the management review for real at least once, with top management present. And walk through the Annex A controls asking one question: can we show this, or can we only tell it?

The internal audit module of the Secure Audit platform contains the criteria, interview questions, examples of good practice and the common nonconformities from this article for every ISO 42001 clause and Annex A control. Use it to run the internal audit that surfaces these points before the certification body arrives. Contact us for a no-obligation conversation.