Verklaring van Toepasselijkheid (SoA) ISO 27001: Voorbeeld & Uitleg
Elke auditor begint ermee. Elke certificering staat of valt ermee. En toch is de Verklaring van Toepasselijkheid (SoA) het document waar de meeste organisaties mee worstelen. De SoA — voluit: Statement of Applicability — is het verplichte ISO 27001-document waarin je vastlegt welke beveiligingsmaatregelen (controls) je wél en welke je níét toepast, inclusief de onderbouwing waarom. Klinkt simpel. Maar in de praktijk zien wij dat 7 van de 10 MKB-bedrijven hier fouten maken die tijdens de audit direct opvallen.
In dit artikel leer je precies wat de SoA inhoudt volgens clausule 6.1.3d, zie je een uitgewerkt voorbeeld met concrete controls, en krijg je een stappenplan waarmee je jouw eigen verklaring van toepasselijkheid opstelt — audit-proof.
Wat is de Verklaring van Toepasselijkheid (SoA)?
De Verklaring van Toepasselijkheid is een verplicht document binnen ISO 27001 dat alle 93 Annex A controls opsomt en per control aangeeft of deze toepasselijk is of niet. ISO 27001 clausule 6.1.3d schrijft dit document letterlijk voor — zonder SoA geen certificering.
Concreet bevat een SoA per control minimaal vier elementen:
- De control zelf — referentienummer en beschrijving uit Annex A
- Toepasselijk ja of nee — is deze maatregel relevant voor jouw organisatie?
- Rechtvaardiging — waarom wel of niet toepasselijk, gekoppeld aan jouw risicoanalyse
- Implementatiestatus — is de maatregel al geïmplementeerd, gedeeltelijk of gepland?
Waarom vragen auditors er altijd als eerste naar? Omdat de SoA het enige document is dat in één oogopslag laat zien hoe jouw ISMS zich verhoudt tot de complete Annex A. Het is de brug tussen jouw risicoanalyse en de daadwerkelijke beveiligingsmaatregelen. Geen enkel ander document geeft dat totaaloverzicht.
De 4 categorieën controls in ISO 27002:2022
Sinds de update van ISO 27002 in 2022 zijn de controls ingedeeld in 4 heldere categorieën in plaats van de oude 14 domeinen. Dit maakt de SoA overzichtelijker — maar je moet wel weten hoe de indeling werkt.
| Categorie | Annex A-referentie | Aantal controls | Voorbeelden |
|---|---|---|---|
| Organisatorische controls | A.5 | 37 | Beleid, rollen, classificatie, leveranciersbeheer |
| Mensgerichte controls | A.6 | 8 | Screening, bewustzijn, thuiswerken |
| Fysieke controls | A.7 | 14 | Toegangsbeveiliging, apparatuur, cabling |
| Technologische controls | A.8 | 34 | Endpoint-beveiliging, encryptie, logging, back-ups |
Totaal: 93 controls. Elke control moet in jouw SoA terugkomen — ook als je hem niet toepast. Juist het onderbouwen waarom een control niet toepasselijk is, toont aan de auditor dat je bewust hebt nagedacht.
In onze praktijk zien we dat organisatorische controls (A.5) de meeste tijd kosten om te documenteren, terwijl technologische controls (A.8) vaak al deels geïmplementeerd zijn via bestaande IT-oplossingen. Begin daarom met een inventarisatie van wat je al hebt — dat scheelt werk.
Voorbeeld SoA-tabel: 10 representatieve Annex A controls
Hieronder een uitgewerkt voorbeeld van een SoA voor een fictief MKB-softwarebedrijf met 35 medewerkers dat volledig in de cloud werkt. Dit geeft je een concreet beeld van hoe een SoA eruitziet.
| Control | Beschrijving | Toepasselijk | Rechtvaardiging | Implementatiestatus |
|---|---|---|---|---|
| A.5.1 | Beleid voor informatiebeveiliging | Ja | Fundament van het ISMS; vereist door scope | Geïmplementeerd |
| A.5.15 | Toegangsbeheer | Ja | Risico R-03: ongeautoriseerde toegang tot klantdata | Geïmplementeerd |
| A.5.31 | Wettelijke en contractuele eisen | Ja | AVG-verplichtingen en klantencontracten | Geïmplementeerd |
| A.6.1 | Screening | Ja | Risico R-07: onbetrouwbaar personeel met toegang tot broncode | Gedeeltelijk geïmplementeerd |
| A.6.3 | Bewustzijn en training informatiebeveiliging | Ja | Risico R-12: menselijke fouten bij phishing en social engineering | In uitvoering |
| A.7.1 | Fysieke beveiligingsperimeters | Nee | Organisatie werkt volledig cloud-based, geen eigen serverruimte of datacenter | N.v.t. |
| A.7.4 | Monitoring fysieke beveiliging | Nee | Geen eigen fysieke IT-infrastructuur; verantwoordelijkheid cloud-provider | N.v.t. |
| A.8.1 | User endpoint devices | Ja | Risico R-05: dataverlies via laptops en mobiele apparaten | Geïmplementeerd |
| A.8.9 | Configuratiebeheer | Ja | Risico R-09: misconfiguratie van cloud-omgevingen | Gedeeltelijk geïmplementeerd |
| A.8.24 | Gebruik van cryptografie | Ja | Risico R-11: onderschepping van data in transit en at rest | Geïmplementeerd |
Let op een paar dingen in dit voorbeeld:
- Elke "Ja" verwijst naar een specifiek risico uit de risicoanalyse (R-03, R-07, etc.). Dit is precies wat auditors willen zien.
- De twee "Nee" controls bij A.7 hebben een duidelijke, logische reden — geen eigen fysieke infrastructuur. Dit is een volledig acceptabele rechtvaardiging.
- Implementatiestatus is eerlijk — niet alles staat op "geïmplementeerd". Dat is realistischer en geloofwaardiger.
Stappenplan: hoe stel je een SoA op?
De SoA stel je op ná je risicoanalyse — niet ervoor. Dit is de volgorde die werkt:
Stap 1: Start vanuit je risicoanalyse
Je risicoanalyse identificeert de dreigingen en kwetsbaarheden voor jouw organisatie. Elk geïdentificeerd risico krijgt een of meer controls als behandeling. Deze koppeling is het fundament van je SoA.
Stap 2: Loop alle 93 controls langs
Neem de complete Annex A-lijst en beoordeel per control of deze toepasselijk is. Gebruik je risicoanalyse als leidraad, maar kijk ook naar wettelijke eisen (AVG, NIS2) en contractuele verplichtingen.
Stap 3: Onderbouw elke keuze
Voor toepasselijke controls: verwijs naar het specifieke risico. Voor niet-toepasselijke controls: geef een concrete reden waarom de control niet relevant is voor jouw context.
Stap 4: Bepaal de implementatiestatus
Wees eerlijk. Gebruik categorieën als: geïmplementeerd, gedeeltelijk geïmplementeerd, in uitvoering, gepland. Auditors waarderen eerlijkheid boven een lijst waar alles op groen staat.
Stap 5: Laat de SoA reviewen
Laat minimaal de CISO of informatiebeveiligingsverantwoordelijke en een proceseigenaar meekijken. Twee paar ogen vangen fouten op die je zelf mist.
Stap 6: Koppel aan je risicobehandelingsplan
De SoA en het risicobehandelingsplan zijn twee kanten van dezelfde medaille. Zorg dat ze naar elkaar verwijzen. Een control in de SoA zonder bijbehorende actie in het behandelingsplan is een rode vlag.
Wat anderen niet vertellen: de SoA als strategisch document
De meeste artikelen behandelen de SoA als een compliance-checklist. Afvinken en klaar. Maar in onze praktijk zien we dat de beste organisaties de SoA gebruiken als strategisch sturingsinstrument.
Hoe? Door de SoA te koppelen aan je jaarlijkse managementreview. Je hebt dan in één document zichtbaar welke controls nog aandacht nodig hebben, waar budget naartoe moet, en welke risico's je bewust accepteert. Eén directeur die we begeleidden noemde het "de cockpit van onze informatiebeveiliging."
Daarnaast zien we dat organisaties die hun SoA actief onderhouden — niet alleen bij de jaarlijkse audit — gemiddeld 40% minder bevindingen hebben bij hercertificering. De SoA is geen statisch document. Nieuwe dreigingen, nieuwe systemen, een overstap naar een andere cloud-provider — het hoort allemaal te leiden tot een update van je SoA.
Een ander punt dat vaak wordt gemist: de SoA is ook je communicatiemiddel naar klanten en leveranciers. Steeds vaker vragen opdrachtgevers om bewijs van informatiebeveiliging. Een goed onderbouwde SoA laat in één document zien welke maatregelen je hebt getroffen, zonder dat je je complete ISMS hoeft te delen.
Veelgemaakte fouten bij de SoA
In 8 van de 10 audits die we begeleiden, zien we dezelfde fouten terugkomen. Vermijd deze:
1. Alles op "toepasselijk" zetten Dit is de nummer-één-fout. Organisaties durven geen control op "niet toepasselijk" te zetten uit angst dat de auditor het afkeurt. Het tegenovergestelde is waar: een SoA waar alles toepasselijk is, is ongeloofwaardig. Een cloud-only bedrijf zonder fysieke serverruimte dat A.7.1 (fysieke beveiligingsperimeters) op toepasselijk zet, roept juist vragen op.
2. Geen koppeling met de risicoanalyse De SoA zonder verwijzing naar specifieke risico's is een papieren tijger. Auditors zoeken de rode draad: risico → control → implementatie. Zonder die lijn is je SoA onvoldoende onderbouwd.
3. Copy-paste van een template zonder aanpassing We komen het regelmatig tegen: een SoA die duidelijk is overgenomen van een template of ander bedrijf. Inclusief risico's die niet van toepassing zijn op de eigen organisatie. Auditors herkennen dit direct.
4. Implementatiestatus niet bijwerken De SoA van vorig jaar met dezelfde statussen als dit jaar? Dat suggereert dat er niets is verbeterd — of dat niemand het document heeft bijgewerkt. Beide zijn problematisch.
5. Rechtvaardiging te vaag Formuleringen als "op basis van risicobeoordeling" of "conform beleid" zeggen niets. Verwijs naar het specifieke risico-ID of de concrete bedrijfscontext.
Van 114 naar 93 controls: de overgang ISO 27002:2013 naar 2022
Als jouw organisatie al een SoA had op basis van de oude ISO 27002:2013, dan moet je deze omzetten naar de nieuwe structuur. De belangrijkste veranderingen:
- 114 controls zijn teruggebracht naar 93 — niet omdat er minder beveiligd hoeft te worden, maar door samenvoeging en herstructurering
- 14 domeinen zijn vervangen door 4 categorieën — organisatorisch, menselijk, fysiek en technologisch
- 11 nieuwe controls zijn toegevoegd, waaronder threat intelligence (A.5.7), informatiebeveiliging bij cloudgebruik (A.5.23), ICT-gereedheid voor bedrijfscontinuïteit (A.8.14) en data masking (A.8.11)
- Elke control heeft nu attributen zoals controltype (preventief, detectief, correctief), beveiligingseigenschappen en operationele mogelijkheden
Voor je SoA betekent dit concreet dat je een mapping moet maken van je oude controls naar de nieuwe nummering. De ISO 27001 checklist kan hierbij helpen. Let er ook op dat de 11 nieuwe controls beoordeeld moeten worden — deze stonden niet in je oude SoA en worden bij audits specifiek gecontroleerd.
De deadline voor de overgang naar de 2022-versie is inmiddels verstreken. Werk je nog met de oude structuur? Dan is het nu tijd om actie te ondernemen.
Checklist: is jouw SoA audit-proof?
Gebruik deze checklist om te controleren of jouw SoA klaar is voor de audit:
- Alle 93 controls staan in de SoA — geen enkele control mag ontbreken, ook niet als deze niet toepasselijk is
- Elke toepasselijke control verwijst naar een specifiek risico uit je risicoanalyse
- Niet-toepasselijke controls hebben een concrete rechtvaardiging — niet alleen "niet relevant"
- Implementatiestatus is actueel en weerspiegelt de werkelijke situatie
- De SoA is afgestemd op het risicobehandelingsplan — acties komen overeen
- De 11 nieuwe controls uit ISO 27002:2022 zijn beoordeeld, inclusief threat intelligence en cloud security
- Het document is goedgekeurd door de CISO of verantwoordelijke directie
- De SoA is in het afgelopen jaar gereviewed en bijgewerkt waar nodig
- Wettelijke en contractuele eisen (AVG, NIS2, klantcontracten) zijn meegenomen als input
- Het document is versie-beheerd met datum, auteur en wijzigingshistorie
Loop deze punten langs vóór je audit. In onze ervaring voorkomt dit 80% van de bevindingen op de SoA.
Conclusie
De Verklaring van Toepasselijkheid is meer dan een verplicht ISO 27001-document. Het is het document dat jouw complete informatiebeveiligingsaanpak in kaart brengt, van risicoanalyse tot implementatie. Een goed opgestelde SoA maakt het verschil tussen een soepele audit en wekenlange herstelacties.
Begin altijd vanuit je risicoanalyse, wees eerlijk over je implementatiestatus, en onderbouw elke keuze concreet. Gebruik de voorbeeld-tabel en checklist uit dit artikel als startpunt.
Wil je sparren over jouw SoA of heb je hulp nodig bij het opstellen ervan? Neem contact op met MaasISO — we kijken graag met je mee. Met onze ervaring bij tientallen ISO 27001-trajecten weten we precies waar auditors op letten en hoe je een SoA opstelt die niet alleen compliant is, maar ook echt werkt voor jouw organisatie.