Tooling for ISO 42001: what your AIMS needs and how the auditor tests it

ISO/IEC 42001:2023 does not prescribe any software. The standard requires you to establish, maintain and demonstrate an AI management system (AIMS), and leaves open how you keep track of it. Even so, tooling comes up in almost every implementation: is a spreadsheet enough, do you need a GRC tool, or will you get stuck once the number of AI systems grows? This article looks at that question from the auditor's side. What has to be recorded, when does a simple solution work fine, where does it go wrong, and how does an auditor test the AIMS once it is in place.

What the standard wants recorded

Much of the tooling question is about documented information. ISO 42001 asks for, among other things, a documented scope (4.3), an AI policy (5.2), the process and results of the AI risk assessment and risk treatment (6.1.2, 6.1.3, 8.2 and 8.3), a Statement of Applicability, the process and results of the AI system impact assessment (6.1.4 and 8.4), AI objectives (6.2), evidence of competence (7.2), monitoring results (9.1), the internal audit programme and its results (9.2), the results of the management review (9.3) and the handling of nonconformities and corrective actions (10.2). On top of that, Annex A contains 38 controls in nine domains, from A.2 (policies) to A.10 (third parties and customers). A full overview per clause is in the checklist of required documents for ISO 42001.

Clause 7.5.3 adds requirements for controlling that information: available where it is needed, protected against unintended changes, with version control and a retention period. That is where a loose collection of files most often falls short. The problem is rarely that a document is missing. The problem is that nobody can show which version applied at the time of the audit.

Spreadsheet, document management or GRC tool

For an organization with a handful of AI systems and a small group of owners, a well-built register in a spreadsheet, with policies and procedures in the existing document management system, is defensible. An auditor does not approve or reject a tool. He checks whether the chain holds: from AI system to risk, from risk to control, from control to the line in the Statement of Applicability, and from that line to evidence that the control works.

A GRC tool becomes worth considering when that chain can no longer be followed in a spreadsheet. Signs of this are several departments procuring AI systems, an AIMS that runs alongside an existing ISMS, and reassessments that depend on changes to systems. Clause 6.3 and the operational requirements in 8.1 ask you to carry out changes in a planned way and assess their consequences. If the register does not show when a system was last assessed and what has changed since, that is a recurring finding, whatever the tool.

Four questions help with the choice. Can you record for each AI system the owner, the role of the organization (developer, provider or user), the purpose, the data used and the date of the last risk assessment? Can you link risks to controls and those to the lines in your Statement of Applicability? Does the system record who changed what and when? And can you produce an export that an auditor accepts as evidence, with date, source and filter included? A tool that says no to the last question creates extra work during the audit.

The AI register is the starting point

Whichever solution you choose, the AI register is the part the rest of the AIMS relies on. Scope, risk assessment, impact assessment and Annex A controls all refer to the AI systems in that register. A register that was only filled at the start soon falls behind practice: vendors add AI features to existing software and employees use tools that never went through procurement. How to bring that use to the surface is covered in the article on the shadow AI inventory.

How the auditor uses your tooling

An auditor looks at what is in the tool. He requests populations, for example all AI systems added or changed during the audit period, draws his own sample from them and asks for each selected system the risk assessment, the impact assessment and the evidence for the chosen controls. An export without a date or without a visible filter raises follow-up questions. A screenshot from a GRC tool is evidence of what was in the tool at that moment, not of how the process actually ran. What a piece of evidence has to show to be usable is set out in the article on audit evidence.

For the certification audit itself, the requirements of ISO/IEC 42006 have applied since July 2025 to certification bodies that certify against ISO 42001. That standard deals with the competence of auditors and the conduct of the audit, not with the organization's tooling.

Testing an AIMS in the Secure Audit Platform

Our platform is built for those who perform audits: audit firms, certification bodies and internal audit functions. It is not an implementation tool for the AIMS itself. It is still useful to know how an ISO 42001 audit runs in it, because the audited organization takes part through a client portal.

The standards library contains ISO/IEC 42001:2023 with clauses 4 to 10 and the 38 Annex A controls. When planning an audit, the auditor takes controls excluded in the Statement of Applicability out of scope and chooses whether ISO 42001 is audited integrated with ISO 27001 or separately. For each line in the audit programme the auditor sees the requirement with interview questions, an example of a good situation, common nonconformities and the documents he can request. Design, implementation and operating effectiveness are recorded separately per line.

Information requests go through the client portal. The organization sees only its own open requests, the schedule and the corrective actions there, and uploads evidence directly against the request. That evidence is then attached to the line in the audit programme. Findings follow the usual route of corrective action plan, review and, for certification, the certification decision. Framework mapping links lines from different standards, so a piece of evidence that applies to both ISO 27001 and ISO 42001 only has to be provided once. The platform also supports periodic monitoring of controls, with a frequency from weekly to annually, submission by the client and approval by the auditor. That is periodic checking, not real-time surveillance of AI systems. More about the modules is on the platform page.

What tooling does not solve

The substantive judgements remain human work. Whether an application falls into the high-risk categories of the EU AI Act, what human oversight looks like in practice, whether the training data are representative and what consequences an AI system can have for the people affected are judgements an owner has to make and justify. Tooling shows whether those judgements have been recorded and when they are due again. Whether they are sound only becomes clear when someone tests them on substance: the internal auditor, the certification auditor or both.