Tooling voor ISO 42001: wat je AIMS nodig heeft en hoe de auditor het toetst

ISO/IEC 42001:2023 schrijft geen software voor. De norm eist dat je een AI-managementsysteem (AIMS) inricht, onderhoudt en kunt aantonen, en laat vrij hoe je dat bijhoudt. Toch is tooling een vraag die bij bijna elke implementatie terugkomt: volstaat een spreadsheet, heb je een GRC-tool nodig, of loop je vast als het aantal AI-systemen groeit? Dit artikel bekijkt die vraag vanuit de kant van de auditor. Wat moet er vastliggen, wanneer werkt een eenvoudige oplossing prima, waar gaat het mis, en hoe toetst een auditor het AIMS als het eenmaal staat.

Wat de norm vastgelegd wil zien

Een groot deel van de tooling-vraag gaat over gedocumenteerde informatie. ISO 42001 vraagt onder meer om een vastgelegde scope (4.3), een AI-beleid (5.2), het proces en de resultaten van de AI-risicobeoordeling en risicobehandeling (6.1.2, 6.1.3, 8.2 en 8.3), een Statement of Applicability, het proces en de resultaten van de AI-systeemimpactassessment (6.1.4 en 8.4), AI-doelstellingen (6.2), bewijs van competentie (7.2), monitoringresultaten (9.1), het interne auditprogramma met de uitkomsten (9.2), de resultaten van de managementreview (9.3) en de afhandeling van afwijkingen en corrigerende maatregelen (10.2). Daarnaast staan in Annex A 38 beheersmaatregelen in negen domeinen, van A.2 (beleid) tot A.10 (derden en klanten). Een volledig overzicht per clausule staat in de checklist met verplichte documenten voor ISO 42001.

Clausule 7.5.3 voegt daar eisen aan toe voor het beheer van die informatie: beschikbaar waar het nodig is, beschermd tegen onbedoelde wijziging, met versiebeheer en een bewaartermijn. Dat is het punt waarop een losse verzameling bestanden het vaakst tekortschiet. Het probleem is zelden dat een document ontbreekt. Het probleem is dat niemand kan laten zien welke versie gold op het moment van de audit.

Spreadsheet, documentbeheer of GRC-tool

Voor een organisatie met een handvol AI-systemen en een kleine groep eigenaren is een goed opgezet register in een spreadsheet, met beleid en procedures in het bestaande documentbeheer, verdedigbaar. Een auditor keurt geen tool goed of af. Hij kijkt of de keten klopt: van AI-systeem naar risico, van risico naar maatregel, van maatregel naar de regel in het Statement of Applicability, en van die regel naar bewijs dat de maatregel werkt.

Een GRC-tool wordt interessant als die keten in een spreadsheet niet meer te volgen is. Signalen daarvoor zijn meerdere afdelingen die AI-systemen aanschaffen, een AIMS dat naast een bestaand ISMS draait, en herbeoordelingen die afhangen van wijzigingen aan systemen. Clausule 6.3 en de operationele eisen in 8.1 vragen dat je wijzigingen gepland doorvoert en de gevolgen beoordeelt. Als het register niet laat zien wanneer een systeem voor het laatst is beoordeeld en wat er sindsdien is veranderd, is dat een terugkerende bevinding, ongeacht de tool.

Bij de keuze helpen vier vragen. Kun je per AI-systeem de eigenaar, de rol van de organisatie (ontwikkelaar, aanbieder of gebruiker), het doel, de gebruikte data en de datum van de laatste risicobeoordeling vastleggen? Kun je risico's koppelen aan maatregelen en die aan de regels in je Statement of Applicability? Houdt het systeem bij wie wat wanneer heeft gewijzigd? En kun je een export maken die een auditor als bewijs accepteert, met datum, bron en filter erbij? Een tool die op de laatste vraag nee zegt, levert tijdens de audit extra werk op.

Het AI-register is het vertrekpunt

Welke oplossing je ook kiest, het AI-register is het onderdeel waar de rest van het AIMS op leunt. Scope, risicobeoordeling, impactassessment en Annex A-maatregelen verwijzen allemaal naar de AI-systemen in dat register. Een register dat alleen bij de start is gevuld, loopt snel achter op de praktijk: leveranciers voegen AI-functies toe aan bestaande software en medewerkers gebruiken tools die nooit via inkoop zijn gegaan. Hoe je dat gebruik boven water krijgt, staat in het artikel over de inventarisatie van shadow AI.

Hoe de auditor je tooling gebruikt

Een auditor kijkt naar wat er in de tool staat. Hij vraagt populaties op, bijvoorbeeld alle AI-systemen die in de auditperiode zijn toegevoegd of gewijzigd, trekt daar zelf een steekproef uit en vraagt per geselecteerd systeem de risicobeoordeling, de impactassessment en het bewijs van de gekozen maatregelen. Een export zonder datum of zonder zichtbaar filter roept vervolgvragen op. Een schermafdruk uit een GRC-tool is bewijs van wat er op dat moment in de tool stond, niet van hoe het proces in werkelijkheid is verlopen. Wat een bewijsstuk moet laten zien om bruikbaar te zijn, staat uitgewerkt in het artikel over bewijslast bij IT-audits.

Voor de certificeringsaudit zelf gelden sinds juli 2025 de eisen van ISO/IEC 42006 aan certificatie-instellingen die ISO 42001 certificeren. Die norm gaat over de competentie van auditors en de inrichting van de audit, niet over de tooling van de organisatie.

Een AIMS toetsen in het Secure Audit Platform

Ons platform is gebouwd voor wie audits uitvoert: auditkantoren, certificerende instellingen en interne auditfuncties. Het is geen implementatietool voor het AIMS zelf. Wel is het nuttig om te weten hoe een audit op ISO 42001 daarin verloopt, omdat de geauditeerde organisatie er via een klantportaal aan meewerkt.

De normbibliotheek bevat ISO/IEC 42001:2023 met de clausules 4 tot en met 10 en de 38 Annex A-maatregelen. Bij de planning van een audit zet de auditor maatregelen die volgens het Statement of Applicability zijn uitgesloten buiten scope, en kiest hij of ISO 42001 geïntegreerd met ISO 27001 wordt geaudit of apart. Per regel in het werkprogramma ziet de auditor het normcriterium met interviewvragen, een voorbeeld van een goede situatie, veelvoorkomende afwijkingen en de documenten die hij kan opvragen. Opzet, bestaan en werking worden per regel apart vastgelegd.

Informatieverzoeken gaan via het klantportaal. De organisatie ziet daar alleen haar eigen openstaande verzoeken, de planning en de corrigerende maatregelen, en uploadt bewijs rechtstreeks bij het verzoek. Dat bewijs hangt daarna aan de regel in het werkprogramma. Bevindingen volgen de gewone route van corrective action plan, review en, bij certificering, het certificatiebesluit. Met framework-mapping worden regels uit verschillende normen aan elkaar gekoppeld, zodat een bewijsstuk dat voor ISO 27001 en ISO 42001 geldt maar een keer hoeft te worden aangeleverd. Het platform ondersteunt ook periodieke monitoring van maatregelen, met een frequentie van wekelijks tot jaarlijks, aanlevering door de klant en goedkeuring door de auditor. Dat is periodieke controle, geen realtime bewaking van AI-systemen. Meer over de modules staat op de pagina over het platform.

Wat tooling niet oplost

De inhoudelijke afwegingen blijven mensenwerk. Of een toepassing onder de hoog-risicocategorieën van de EU AI Act valt, hoe menselijk toezicht er concreet uitziet, of de trainingsdata representatief zijn en welke gevolgen een AI-systeem voor betrokkenen kan hebben, zijn oordelen die een eigenaar moet maken en onderbouwen. Tooling maakt zichtbaar of die oordelen zijn vastgelegd en wanneer ze opnieuw moeten. Of ze deugen, blijkt pas als iemand ze inhoudelijk toetst: de interne auditor, de certificerende auditor of beide.