Statement of Applicability (SoA) opstellen: de complete gids

Een Statement of Applicability (SoA) — in het Nederlands de Verklaring van Toepasselijkheid — hoort bij de eerste documenten die een auditor opvraagt bij een audit van het ISMS. Toch blijft het voor veel organisaties het document waarover de meeste onzekerheid bestaat: is de lijst compleet, is de onderbouwing sterk genoeg, en overleeft die de kritische blik van een auditor? Een SoA die niet meer is dan een gekopieerde Annex A-lijst met overal "ja, van toepassing" erachter, is een van de meest zichtbare signalen van een afvink-ISMS — en precies het soort document waar een auditor het langst bij stilstaat. Deze gids laat zien hoe u een SoA opbouwt die niet alleen op papier compleet is, maar ook daadwerkelijk standhoudt tijdens een audit.

Wat is een Statement of Applicability precies?

De Statement of Applicability is een verplicht document uit artikel 6.1.3(d) van ISO/IEC 27001: voor elke beheersmaatregel uit Annex A legt u vast of die van toepassing is op uw organisatie, waarom (wel of niet), en hoe die is — of wordt — geïmplementeerd. Het is geen bijlage die u eenmalig invult en daarna wegbergt, maar het scharnierpunt tussen twee andere verplichte onderdelen van uw ISMS: de risicobeoordeling (wat kan er misgaan, en hoe groot is dat risico?) en de daadwerkelijke beheersmaatregelen (wat doet u eraan, en kunt u dat aantonen?). Zie ook de bestaande SoA-samenvatting op onze checklistpagina, die het kernachtig samenvat: "de SoA koppelt uw risico's aan de 93 beheersmaatregelen uit Annex A en motiveert per maatregel of die van toepassing is." Dit artikel bouwt daarop voort en laat zien hóe u dat per maatregel goed onderbouwt — inclusief de vragen waar een auditor het vaakst op doorvraagt.

Praktisch gezien is de SoA meestal een tabel — op papier, in Excel of in een GRC-tool — met één rij per beheersmaatregel en kolommen voor elk van de vereiste onderdelen. Er bestaat geen voorgeschreven bestandsformaat; wél bestaat er een vaste set vragen die elke rij moet beantwoorden. Zie ook ons antwoord op 'wat is een Verklaring van Toepasselijkheid' in de veelgestelde vragen voor de korte definitie — hieronder werken we die uit tot een stappenplan dat u direct kunt toepassen.

De opbouw: van risico naar maatregel naar bewijs

Een sterke SoA volgt voor elke beheersmaatregel dezelfde vaste opbouw. Dat klinkt eenvoudig, maar in de praktijk is dit precies waar de meeste bestaande SoA's op vastlopen: velden die zijn ingevuld met een enkel woord, of onderbouwing die voor tientallen maatregelen tegelijk letterlijk dezelfde zin bevat. Doorloop onderstaande vijf stappen per maatregel, niet per document.

Van toepassing?

De eerste vraag per maatregel is simpel gesteld, maar niet altijd simpel te beantwoorden: is deze beheersmaatregel relevant voor uw scope? Het antwoord volgt logisch uit uw risicobeoordeling — niet uit een gevoel of uit wat er "de vorige keer" is ingevuld. Een maatregel is van toepassing zodra er een geïdentificeerd risico is dat hij mitigeert, zodra wet- en regelgeving of een klantcontract hem verplicht stelt, of zodra u er zelf bewust voor kiest hem toe te passen als goede praktijk. Is geen van die drie het geval? Dan mag de maatregel als niet van toepassing worden gemarkeerd — mits u dat in de volgende stap onderbouwt.

Onderbouwing

Dit is het onderdeel waar de meeste bestaande SoA's zwak scoren. Onderbouwing betekent: een concrete, specifieke reden, gekoppeld aan uw eigen risico's, wetgeving of een bewuste bedrijfsbeslissing — nooit een generieke zin die voor elke organisatie zou kunnen gelden. "Van toepassing omdat het een goede maatregel is" is geen onderbouwing; "van toepassing omdat dit het risico van ongeautoriseerde toegang tot de productieomgeving mitigeert" wel. Voor maatregelen die u uitsluit geldt hetzelfde: "niet van toepassing" zonder reden is precies het soort antwoord waar een auditor op doorvraagt, omdat scope zich zo ongemerkt kan versmallen.

Implementatiestatus

Naast of een maatregel van toepassing is, moet de SoA laten zien hoe ver de implementatie staat. Gebruik heldere, concrete statussen — geïmplementeerd, gedeeltelijk geïmplementeerd met een geplande einddatum, of gepland — en vermijd een status als "in ontwikkeling" die jaar na jaar terugkomt zonder zichtbare voortgang. Een auditor accepteert een realistisch tijdpad met een concrete datum; een aanhoudende, vage "onderweg"-status niet.

Gekoppeld risico

Elke toegepaste maatregel hoort terug te verwijzen naar een specifiek, benoemd risico uit uw risicoregister — niet naar "informatiebeveiliging in algemene zin". Deze koppeling is wat de SoA daadwerkelijk verbindt met uw risicobeoordeling, in plaats van een los document ernaast. Zonder deze koppeling is het voor een auditor — en voor uzelf — nauwelijks te beoordelen of uw maatregelen daadwerkelijk zijn afgestemd op de risico's die u zelf heeft geïdentificeerd.

Bewijslocatie en eigenaar

Tot slot: waar staat het bewijs, en wie is er verantwoordelijk? Een SoA-rij zonder eigenaar is een rij die niemand actueel houdt. Leg per maatregel vast wie eindverantwoordelijk is voor de uitvoering, en waar het bewijs te vinden is — een beleidsdocument, een configuratiescreenshot, een trainingsregistratie, een contract. Tijdens de audit bespaart dit veel tijd: in plaats van live te zoeken naar bewijs, verwijst u direct naar de juiste plek.

Zo ziet dit er in de praktijk uit voor één beheersmaatregel:

Onderdeel	Voorbeeld (fictief, ter illustratie)
Maatregel	Gebruik van cryptografie
Van toepassing?	Ja
Onderbouwing	Mitigeert het risico van onderschepping van klantgegevens tijdens verzending; tevens contractueel vereist door meerdere klanten.
Implementatiestatus	Geïmplementeerd — versleutelde verbindingen verplicht voor alle externe koppelingen, versleuteling van gevoelige data in de productieomgeving.
Gekoppeld risico	Risico "onderschepping van gegevens tijdens transport", risicoregister
Bewijslocatie en eigenaar	Cryptografiebeleid; eigenaar: IT-verantwoordelijke

Dit voorbeeld is fictief en uitsluitend bedoeld om de structuur te illustreren — gebruik het niet als kant-en-klare tekst voor uw eigen SoA.

Per maatregel: wat hoort er in de onderbouwing?

Een auditor beoordeelt de onderbouwing van elke maatregel op drie punten: is de reden specifiek voor uw organisatie, is die aantoonbaar gekoppeld aan een risico of verplichting, en klopt die met wat er daadwerkelijk in de praktijk gebeurt? Onderbouwing valt in de praktijk uiteen in drie categorieën:

• Risicogebaseerd: de maatregel mitigeert een specifiek, benoemd risico uit uw risicobeoordeling. Dit is de meest gebruikte en sterkste vorm van onderbouwing, mits de koppeling naar het risico expliciet is.
• Wettelijk of contractueel verplicht: de maatregel is vereist door wetgeving, een norm, of een klantcontract. Benoem de concrete verplichting, niet alleen "wettelijke eisen" in algemene zin.
• Bewuste bedrijfsbeslissing: u past de maatregel toe als goede praktijk, ook zonder een direct geïdentificeerd risico of verplichting. Dat is legitiem, mits gedocumenteerd als bewuste keuze en niet als vergeten in te vullen veld.

Auditors besteden opvallend veel aandacht aan de maatregelen die zijn gemarkeerd als niet van toepassing. De reden is eenvoudig: hier kan scope zich ongemerkt versmallen zonder dat iemand het opmerkt. "Niet van toepassing, want wij doen dit niet" is geen onderbouwing; "niet van toepassing, want het onderliggende proces valt buiten de vastgestelde scope van dit ISMS" wel. Behandel elke uitsluiting met minstens zoveel zorg als elke opname.

Wilt u weten of uw eigen SoA een audit zou doorstaan? Vraag een audit-scan aan — we nemen uw Statement of Applicability inclusief onderbouwing per maatregel met u door en geven concreet aan waar die nog kwetsbaar is.

De vier 2022-thema's en de nieuwe maatregelen

Sinds de herziening van 2022 is Annex A opnieuw ingedeeld: de vier thema's en nieuwe maatregelen van ISO 27001:2022 vervangen de veertien hoofdstukken uit de vorige versie. De 93 beheersmaatregelen zijn nu gegroepeerd in vier thema's: organisatorisch, mensen, fysiek en technologisch. Voor uw SoA betekent dit twee dingen. Ten eerste: de structuur van uw document volgt bij voorkeur deze indeling, niet de oude structuur uit veertien hoofdstukken. Ten tweede — en belangrijker — zijn elf maatregelen nieuw ten opzichte van de vorige versie, onder meer op het gebied van threat intelligence, informatiebeveiliging bij clouddiensten, ICT-continuïteit, fysieke beveiligingsmonitoring, configuratiebeheer, data leakage prevention, monitoring, webfiltering en secure coding.

Een veelgemaakte fout bij de transitie is dat organisaties hun bestaande SoA simpelweg herschikken naar de nieuwe thema-indeling, zonder voor elk van deze elf nieuwe maatregelen apart te beoordelen of die van toepassing is. Loop bij een transitie dus niet alleen de structuur na, maar behandel elke nieuwe maatregel als een volwaardige, nieuwe beoordeling — met een eigen onderbouwing, niet een hergebruikte tekst uit een aanpalende, oudere maatregel.

Veelgemaakte fouten in een bestaande SoA

Drie fouten komen opvallend vaak terug wanneer een bestaande SoA tegen het licht wordt gehouden.

Een "niet van toepassing" zonder specifieke onderbouwing. Zoals hierboven beschreven: dit is de plek waar scope ongemerkt versmalt. Een auditor die bij verschillende maatregelen telkens dezelfde generieke reden tegenkomt, trekt daar terecht conclusies uit over de rest van het document.

Een SoA die niet is bijgewerkt sinds de eerste certificering. Risico's veranderen, systemen veranderen, leveranciers veranderen — maar de SoA van veel organisaties staat nog exact zoals die was op de dag van het initiële certificaat. Het gevolg is een document dat niet meer klopt met de praktijk: precies het type afwijking dat auditors het vaakst signaleren.

De SoA behandeld als eenmalig project in plaats van een levend document. Dit patroon is zo bepalend voor de houdbaarheid van uw SoA dat het een eigen sectie verdient.

De SoA als levend document, niet als eenmalig project

Een SoA die na oplevering in een la verdwijnt tot de volgende audit, is een gemiste kans — en een risico. Behandel de SoA als een document dat meebeweegt met uw organisatie, langs een vast ritme:

• Koppel elke maatregel aan een concreet, benoemd risico: verwijs naar uw risicoregister, niet naar risico's in algemene zin.
• Onderbouw elke opname of uitsluiting schriftelijk: specifiek voor uw situatie, op het moment van beoordelen — niet achteraf, vlak vóór een audit.
• Wijs per maatregel een eigenaar aan: verantwoordelijk voor het bewijs en de actualiteit van die regel.
• Neem de SoA mee bij elke directiebeoordeling, niet alleen bij de jaarlijkse interne audit — risico's en context veranderen vaker dan de auditcyclus.
• Overweeg een onafhankelijke review vóór de volgende audit, zeker als de SoA is opgesteld door dezelfde mensen die ook de maatregelen hebben geïmplementeerd. Een frisse blik van buiten ziet sneller waar onderbouwing te generiek is geworden.

Nog niet begonnen aan een risicobeoordeling of SoA, of twijfelt u waar u precies staat? Een gap-analyse legt de basis voor uw audit-checklist en SoA, waarmee u de stappen in dit artikel direct en gestructureerd kunt doorlopen.

ISO/IEC 27001 — officiële normpagina (clausule 6.1.3(d), de formele eis voor de SoA) en ISO/IEC 27002:2022 — Information security controls (de toelichting per beheersmaatregel uit Annex A) zijn de officiële bronnen voor dit artikel.