Reading a Statement of Applicability the way an auditor does
In preparation
ISO/IEC 42001 was published in December 2023 as the first certifiable management system standard for artificial intelligence. Within a year, boards that had never asked about a management system standard in their lives were asking about this one. Here is what it actually requires, read the way an auditor will read it.
It is a management system standard, not a technical standard
The most common misreading is to expect a control list for models: fairness thresholds, accuracy floors, approved architectures. ISO/IEC 42001 contains none of that, and it was never going to. It follows the same harmonised structure as ISO/IEC 27001 and ISO 9001: context, leadership, planning, support, operation, performance evaluation, improvement, because its subject is how your organisation governs AI, not which loss function you chose.
If you already run a certified ISMS, the shape will be immediately familiar, and a significant amount of clause 4 to clause 10 machinery can be shared: document control, internal audit, management review, corrective action. The AI-specific work sits in the planning clauses and in Annex A.
The Annex A control set
Annex A carries 38 controls organised under nine headings. In summary, they require you to have:
- Policies for AI that are approved, published and actually reviewed, not a page written for the audit
- Internal organisation: named roles, defined accountability, and a reporting route for AI concerns
- Resources documented: the data, tooling, compute and human expertise each AI system depends on
- Impact assessment of AI systems on individuals, groups and society, not just on the organisation
- Life cycle management: requirements, design, verification, deployment, operation, monitoring and retirement
- Data governance: provenance, quality, preparation and the acquisition basis for training data
- Information for interested parties: what you tell users, customers and regulators about the system
- Responsible use: the rules governing how your own people use AI systems, including ones you did not build
- Third-party relationships: allocating responsibility across suppliers, partners and customers
As with ISO/IEC 27001, controls are selected and justified rather than adopted wholesale. Expect an auditor to ask why an excluded control is not applicable, and to be unimpressed by "we are only a deployer".
The clause that catches people: AI system impact assessment
Clause 6.1.4 requires a process for assessing the potential consequences of an AI system for individuals and groups of individuals, and for society, and requires it to be performed at defined points in the life cycle, documented, and fed back into risk treatment.
This is the requirement that most organisations underestimate. A privacy impact assessment does not satisfy it: PIAs are scoped around personal data, whereas an AI impact assessment has to consider effects that have nothing to do with data protection: a scoring model that systematically disadvantages a group, an automated decision with no practical route to challenge it, an output that is confidently wrong in a safety-relevant context.
On audit, the finding is rarely "you have no impact assessment". It is that the impact assessment exists, was done once at launch, references no defined trigger for repeating it, and has no visible connection to the risk register.
What an auditor will actually ask for
Five requests come up almost every time. If you can answer these with documents rather than explanations, you are in a reasonable position:
- An inventory of AI systems in scope, including the ones procured as features inside other software, which is where the shadow inventory always hides
- Your role for each system: developer, provider, deployer, because the obligations differ and organisations routinely hold several roles at once
- Evidence of human oversight that is real: who can override the system, whether they have ever done so, and whether they have the standing to
- Data provenance for training and fine-tuning, and the basis on which that data was acquired
- Post-deployment monitoring records: drift, incidents, complaints, and what was done about them
How it sits beside ISO/IEC 27001 and 27701
The three are designed to interlock. ISO/IEC 27001 governs information security; ISO/IEC 27701 extends it into privacy; ISO/IEC 42001 governs the AI systems that increasingly sit on top of both. Where an ISMS is already certified, an integrated management system is usually the sensible path: one internal audit programme, one management review, one set of corrective action machinery, three scopes.
What does not transfer is judgement about AI-specific harm. An auditor who has spent a decade on access control will not, without further training, be equipped to challenge an AI impact assessment. That gap is the reason the lead auditor course for 42001 exists as a separate program rather than a bolt-on module.
Where to start if you are starting now
Build the inventory first. Almost every organisation that begins a 42001 programme discovers it is operating more AI systems than it believed, most of them procured rather than built, and several of them making decisions nobody has classified. Until that inventory exists, every other clause is being applied to a scope you cannot describe , and an undefined scope is the one finding that will stop a certification audit before it starts.
This article is general guidance, not a substitute for the standard itself. ISO/IEC 42001:2023 is copyrighted and available from ISO or your national standards body. ZULTIV is a training and assurance provider; we are not an accredited certification body and do not issue ISO certificates.