Statement of Applicability (SoA) in ISO 27001: wat erin moet en hoe je hem opstelt

De Statement of Applicability (SoA), in het Nederlands de verklaring van toepasselijkheid, is het document waarin je vastlegt welke beheersmaatregelen je organisatie nodig heeft, waarom, en of ze zijn geïmplementeerd. ISO 27001 stelt het document verplicht in clausule 6.1.3 d. Bij een certificeringsaudit is het meestal een van de eerste stukken die de auditor opvraagt, omdat het laat zien hoe de risicobeoordeling heeft geleid tot concrete maatregelen. Hieronder staat wat de norm precies eist, hoe je een SoA opbouwt en waar het in de praktijk misgaat.

Wat de norm eist in clausule 6.1.3

De SoA is het sluitstuk van de risicobehandeling. Clausule 6.1.3 beschrijft een volgorde. Je kiest per risico een behandeloptie, je bepaalt welke beheersmaatregelen nodig zijn om die behandeling uit te voeren, en je vergelijkt die maatregelen met Annex A om na te gaan of je niets noodzakelijks hebt overgeslagen. Pas daarna stel je de SoA op.

Volgens 6.1.3 d bevat de SoA vier dingen: de noodzakelijke beheersmaatregelen, de rechtvaardiging waarom ze zijn opgenomen, of ze geïmplementeerd zijn of niet, en de rechtvaardiging voor het uitsluiten van maatregelen uit Annex A. Het derde punt wordt vaak gemist. Een SoA mag maatregelen bevatten die nodig zijn maar nog niet volledig zijn ingericht, zolang dat eerlijk staat vermeld en het risicobehandelplan beschrijft wanneer en door wie het gat wordt gedicht.

Wat ook vaak ontgaat: Annex A is geen uitputtende lijst. De norm zegt zelf dat je maatregelen uit andere bronnen kunt gebruiken, bijvoorbeeld uit ISO 27017 voor cloudomgevingen of uit eisen die voor je sector gelden. Die horen dan ook in de SoA.

Annex A in de versie van 2022

ISO 27001:2022 telt 93 maatregelen in vier thema's: organisatorisch (37), mensen (8), fysiek (14) en technologisch (34). De versie van 2013 had er 114 in veertien domeinen. Bij de herziening zijn veel maatregelen samengevoegd en zijn er elf nieuw bijgekomen: threat intelligence (5.7), informatiebeveiliging bij het gebruik van clouddiensten (5.23), ICT-gereedheid voor bedrijfscontinuïteit (5.30), monitoring van fysieke beveiliging (7.4), configuratiebeheer (8.9), het verwijderen van informatie (8.10), datamaskering (8.11), het voorkomen van datalekken (8.12), monitoring van activiteiten (8.16), webfiltering (8.23) en veilig programmeren (8.28). Wie een SoA uit de 2013-periode heeft omgezet, moet juist bij die elf nagaan of de onderbouwing inhoudelijk is of alleen uit een mappingtabel is overgenomen. De verdere wijzigingen staan in het artikel over de ISO 27001:2022-update.

Hoe een regel in de SoA eruitziet

Een tabel met vaste kolommen werkt het best: nummer en naam van de maatregel, toepasselijk ja of nee, de reden van opname of uitsluiting, de implementatiestatus, en een verwijzing naar het beleid, de procedure of het systeem waarin de maatregel is belegd. Veel organisaties voegen een kolom toe met de risico's waar de maatregel aan hangt. De norm vraagt daar niet om, maar het maakt de herleidbaarheid naar de risicobeoordeling in één oogopslag zichtbaar.

Neem maatregel 5.15, toegangsbeveiliging. Een zwakke onderbouwing luidt: van toepassing, wij hebben een toegangsbeleid. Een bruikbare onderbouwing noemt de risico's uit het register waar de maatregel op ingrijpt, verwijst naar het toegangsbeleid met versienummer en naar het proces voor het toekennen en intrekken van rechten, en vermeldt de status. De auditor kan dan vanuit die ene regel doorvragen naar bewijs, bijvoorbeeld een steekproef uit de medewerkers die het afgelopen jaar uit dienst zijn gegaan.

Uitsluitingen onderbouwen

Een maatregel uitsluiten mag, maar de reden moet volgen uit je scope en je risico's. Niet relevant is geen rechtvaardiging. Binnen de scope vindt geen eigen softwareontwikkeling plaats en alle applicaties worden als SaaS afgenomen: dat is er wel een. Een auditor zal dan wel kijken of er binnen de scope echt nergens scripts, koppelingen of low-code-toepassingen worden gebouwd, want daar wankelt een uitsluiting van de ontwikkelmaatregelen 8.25 tot en met 8.28 geregeld. Let er ook op dat 8.26, over beveiligingseisen aan applicaties, net zo goed geldt bij het aanschaffen van software als bij het zelf bouwen.

Het omgekeerde komt minstens zo vaak voor: uit voorzichtigheid alles op van toepassing zetten. Dat voelt veilig, maar elke maatregel die je als toegepast opvoert, moet je bij de audit kunnen aantonen. Een goed onderbouwde uitsluiting geeft minder kans op een bevinding dan een maatregel die op papier bestaat en in de praktijk niet.

Fysieke maatregelen zijn een terugkerend twijfelgeval. Een organisatie die volledig in de cloud werkt en geen eigen serverruimte heeft, kan thema 7 niet in zijn geheel uitsluiten. Er blijven kantoren, werkplekken en apparatuur buiten het kantoor (7.9). Voor het datacenter verschuift de maatregel naar de leverancier, en dan hoort de SoA te verwijzen naar hoe je die leverancier beoordeelt, bijvoorbeeld aan de hand van diens ISO 27001-certificaat of ISAE 3402-rapport.

De SoA en de risicobeoordeling horen bij elkaar

De volgorde is risicobeoordeling, risicobehandeling, SoA. Wie begint met het invullen van Annex A en daarna risico's zoekt die erbij passen, draait de logica om. Een auditor ziet dat terug aan een SoA waarin elke maatregel met dezelfde standaardzin op van toepassing staat, en aan een risicoregister dat geen enkele maatregel noemt die niet ook letterlijk in Annex A voorkomt. Hoe je de risicobeoordeling zelf opbouwt, staat in het stappenplan voor risicoanalyse.

De SoA, het risicobehandelplan en het risicoregister moeten na elke wijziging nog op elkaar aansluiten. Verandert de scope, komt er een belangrijke leverancier bij of wordt een systeem uitgefaseerd, dan werk je alle drie bij. Geef de SoA een versienummer en een datum, en zorg dat de goedkeuring herleidbaar is. ISO/IEC 27006, de norm waar certificatie-instellingen zich aan houden, schrijft voor dat het certificaat naar de versie van de SoA verwijst. Een SoA die achterloopt, valt bij de volgende audit dus op.

Wat een auditor in de SoA controleert

In fase 1 van de certificeringsaudit kijkt de auditor vooral naar volledigheid. Staan alle 93 maatregelen erin, is elke uitsluiting gerechtvaardigd en sluit de SoA aan op de vastgestelde scope? In fase 2 en bij de surveillance-audits wordt de SoA het steekproefkader. De auditor kiest maatregelen die als geïmplementeerd staan en vraagt naar het bewijs dat ze werken. Een verschil tussen wat de SoA claimt en wat de organisatie kan laten zien, levert dan een bevinding op. Hoe de fasen van certificering verder verlopen, staat in het stappenplan voor ISO 27001-certificering.

De interne audit hoort de SoA ook te toetsen, en met dezelfde vraag: klopt wat er staat met wat er is ingericht? Een interne auditor die de SoA regel voor regel naast de werkelijke inrichting legt, vindt de gaten voordat de certificatie-instelling dat doet.