Statement of Applicability voor ISO 42001: zo stel je hem op

Wie ISO 27001 kent, kent de Statement of Applicability (SoA): het document waarin je per beheersmaatregel uit Annex A vastlegt of hij van toepassing is en waarom. ISO/IEC 42001 werkt met precies hetzelfde mechanisme, maar dan voor AI. Clausule 6.1.3 verplicht je om als onderdeel van de risicobehandeling een SoA op te stellen voor de 38 beheersmaatregelen uit Annex A van de norm. In de certificeringstrajecten die wij begeleiden is de SoA een van de eerste documenten die de externe auditor opvraagt. Reden genoeg om hem goed op te zetten. In dit artikel: waar de SoA vandaan komt, wat erin hoort, hoe je uitsluitingen onderbouwt en waar het misgaat.

Waar de SoA in de norm zit

De SoA is geen losstaand document maar de uitkomst van het risicobehandelingsproces in clausule 6.1.3. Dat proces bestaat uit een aantal stappen. Je kiest per geïdentificeerd AI-risico een behandeloptie: beheersen, vermijden, overdragen of accepteren. Vervolgens bepaal je welke beheersmaatregelen nodig zijn om de gekozen opties uit te voeren. Die zelf bepaalde maatregelen vergelijk je met Annex A om te controleren of je niets over het hoofd hebt gezien. Uit die vergelijking volgt de Statement of Applicability. Tot slot werk je alles uit in een risicobehandelplan met acties, verantwoordelijken en termijnen.

Die volgorde is belangrijk. Een SoA die niet herleidbaar is naar een risicobeoordeling, valt bij een certificeringsaudit door de mand. De auditor wil kunnen zien waarom een beheersmaatregel van toepassing is verklaard, en dat antwoord hoort in je risico's te liggen, niet in "de norm zegt het".

Wat er in de SoA staat

De kern is een tabel met alle 38 beheersmaatregelen uit Annex A, van A.2.2 (AI-beleid) tot en met A.10.4 (relaties met klanten). Per maatregel leg je vast of hij van toepassing is, met een onderbouwing voor zowel opname als uitsluiting. Wij adviseren daarnaast een kolom met de implementatiestatus en een verwijzing naar het document of proces waarin de maatregel is uitgewerkt. De norm eist die extra kolommen niet, maar ze maken de SoA bruikbaar als stuurinstrument en besparen tijd tijdens de audit.

Annex A is ingedeeld in negen domeinen: beleid rond AI (A.2), interne organisatie (A.3), resources voor AI-systemen (A.4), het beoordelen van impact van AI-systemen (A.5), de levenscyclus van AI-systemen (A.6), data voor AI-systemen (A.7), informatie voor belanghebbenden (A.8), gebruik van AI-systemen (A.9) en relaties met derden en klanten (A.10). Die indeling helpt bij het beleggen van eigenaarschap: het datadomein hoort ergens anders thuis dan het domein over informatievoorziening aan belanghebbenden.

Let bij het beschrijven van de maatregelen op auteursrecht. De tekst van de norm mag je niet overnemen in je eigen documenten. Beschrijf per maatregel in eigen woorden wat hij inhoudt en verwijs naar het nummer.

Uitsluitingen onderbouwen

Niet elke beheersmaatregel is voor elke organisatie relevant, en de norm biedt daar ruimte voor. De rol die je vervult bepaalt veel. Een organisatie die uitsluitend AI-systemen van derden gebruikt en zelf niets ontwikkelt, zal een aantal maatregelen uit het levenscyclusdomein anders invullen of uitsluiten dan een partij die zelf modellen traint. Andersom geldt hetzelfde: wie alleen ontwikkelt en niet zelf inzet bij eindgebruikers, kijkt anders naar de maatregelen rond gebruik.

De onderbouwing moet wel kloppen en gedocumenteerd zijn. "Niet relevant" is geen onderbouwing. Een goede uitsluiting beschrijft de feitelijke situatie (wij ontwikkelen geen eigen modellen, alle AI-functionaliteit wordt ingekocht als onderdeel van SaaS-diensten) en trekt daaruit de conclusie voor de maatregel. Wees terughoudend met uitsluiten: in de praktijk blijken maatregelen die op het eerste gezicht niet van toepassing lijken, dat bij nader inzien vaak wel te zijn. Ingekochte AI valt bijvoorbeeld gewoon binnen je verantwoordelijkheid richting gebruikers en betrokkenen.

De koppeling met het risicobehandelplan

De SoA zegt welke maatregelen van toepassing zijn, het risicobehandelplan zegt hoe en wanneer ze worden geïmplementeerd. Die twee documenten horen op elkaar aan te sluiten. Het behandelplan bevat per maatregel de implementatieacties, de verantwoordelijke, de termijn en het verwachte restrisico. Restrisico's die overblijven na behandeling moeten formeel worden geaccepteerd door een daartoe bevoegde risico-eigenaar. Dat klinkt als een formaliteit, maar het ontbreken van vastgelegde restrisico-acceptatie is een afwijking die wij regelmatig tegenkomen.

Verschil met de ISO 27001-SoA

Het mechanisme is identiek, de inhoud niet. Annex A van ISO 27001:2022 telt 93 beheersmaatregelen gericht op informatiebeveiliging; Annex A van ISO 42001 telt er 38, gericht op verantwoorde ontwikkeling en verantwoord gebruik van AI. Er zit overlap in thema's als beleid, rollen en leveranciersrelaties, maar de AI-maatregelen vragen om andere expertise: impactbeoordelingen op individuen en samenleving, datakwaliteit voor training, transparantie richting gebruikers.

Organisaties met beide certificeringen kiezen soms voor één gecombineerd SoA-document. Dat kan, zolang per norm duidelijk blijft welke maatregelen onder welke Annex vallen en de onderbouwingen apart herleidbaar zijn. Twee losse documenten met kruisverwijzingen werkt in de praktijk vaak overzichtelijker.

Veelvoorkomende afwijkingen

Bij interne audits en certificeringstrajecten zien wij rond de SoA steeds dezelfde patronen. Er is geen SoA, of hij is onvolledig: niet alle 38 maatregelen zijn behandeld met een onderbouwing voor opname of uitsluiting. De behandelkeuzes zijn niet gedocumenteerd, waardoor niet te achterhalen is waarom een maatregel is gekozen of een risico is geaccepteerd. Restrisico's zijn niet formeel beoordeeld of geaccepteerd door een bevoegde eigenaar. Het behandelplan mist termijnen, verantwoordelijken of voortgangsbewaking. En de geïmplementeerde maatregelen sluiten niet aan op de risico's uit de risicobeoordeling, waardoor beoordeling en behandeling los van elkaar staan.

Elk van deze punten is te voorkomen door de SoA niet als invuloefening te behandelen maar als uitkomst van je risicoproces.

Welke documenten de auditor verwacht

Reken erop dat een externe auditor rond clausule 6.1.3 vraagt naar: de procedure voor risicobehandeling, de Statement of Applicability zelf, het risicobehandelplan, de vastlegging van geaccepteerde restrisico's en bewijs van implementatie en effectiviteit van de maatregelen. De SoA hoort daarnaast een versienummer en een vaststellingsdatum te hebben, en wordt minimaal jaarlijks herzien en bij grote veranderingen tussentijds bijgewerkt. Een nieuw AI-systeem in de scope of een gewijzigde rol (je gaat bijvoorbeeld zelf modellen ontwikkelen) is zo'n verandering.

Wil je de SoA en het bijbehorende risicoproces gestructureerd opzetten? Het Secure Audit platform bevat een interne-auditmodule met per ISO 42001-maatregel concrete criteria, interviewvragen en voorbeelden van goede invulling en veelvoorkomende afwijkingen. Neem contact op voor een vrijblijvend gesprek.