Statement of Applicability (SoA) is het document waarin je per Annex A-controle vastlegt of deze van toepassing is, hoe je hem implementeert en waarom je eventueel afwijkt. Voor auditors is de SoA het navigatiemenu door je ISMS — losse policies zonder SoA-koppeling zijn moeilijk te volgen.
De SoA is geen statische checklist: hij evolueert met scope, risico’s en nieuwe productfeatures. SaaS-organisaties koppelen SoA-regels vaak aan concrete controls in IAM, CI/CD, logging en leverancierscontracten — niet aan vage ‘we hebben een beleid’.
Wat betekent dit?
ISO 27001 Annex A bevat controledoelen en controls (2022-versie: 93 controls in 4 thema’s). De SoA selecteert welke relevant zijn, documenteert implementatiestatus en motiveert uitsluitingen. Stage 2 auditors steekproeven controls via de SoA — ’toon me A.5.15 voor jullie identity setup’.
Elke SoA-regel heeft idealiter: control-ID, van toepassing ja/nee, implementatiebeschrijving, verwijzing naar risico-ID, eigenaar en bewijslocatie. ‘N.v.t.’ vereist argument — bijvoorbeeld fysieke beveiliging datacenter niet van toepassing bij full cloud met SOC 2 host.
SoA en risicoregister zijn bidirectioneel gekoppeld: risico’s sturen selectie; SoA-gaps genereren nieuwe risico’s of acceptatiebesluiten. Management review bespreekt open SoA-acties en prioriteit.
Versiebeheer is essentieel — auditors vergelijken SoA met vorige surveillance en vragen waarom controls zijn toegevoegd of verwijderd. Wijzigingen zonder change record zijn een klassieke minor.
Sommige teams groeperen SoA per domein (IAM, development, HR) voor leesbaarheid — mits control-ID’s intact blijven en geen controls verdwijnen in samenvattingen.
Voor wie is dit relevant?
Security en compliance teams onderhouden de SoA; engineering levert implementatiedetails. MT ziet via SoA-dashboard welke controls ‘planned’ vs ‘operating’ zijn — nuttig voor budgetgesprekken vóór audit.
Sales en customer success krijgen vragen over specifieke controls (encryptie, logging, access review). Een actuele SoA voorkomt dat elke deal ad-hoc antwoorden verzint die later niet kloppen met audit.
MKB kan starten met Annex A subset en uitbreiden — mits rationale vastligt. Enterprise met meerdere BU’s worstelt met één SoA vs per-BU varianten; certificering vraagt meestal één consistente SoA binnen scope.
Interne auditors plannen steekproeven op basis van SoA-prioriteit en vorige bevindingen — hoog-risico controls en recent gewijzigde regels eerst.
Welke eisen of stappen horen erbij?
Na risicoanalyse: map bedreigingen naar Annex A controls. Markeer relevante controls; documenteer implementatie of geplande actie per control.
Schrijf implementatiebeschrijving concreet: welk systeem, welk proces, welke frequentie — bijvoorbeeld ‘quarterly access review in Okta met ticket in Jira’. Koppel bewijs: policy-versie, config export, reviewlog.
Review SoA bij scope-wijziging, nieuwe Annex A interpretatie of major release. Laat MT in management review expliciet SoA-status goedkeuren of bijsturen.
Voor certificering: align SoA-template met certificeringsinstantie verwachtingen in stage 1 — discussie over n.v.t.-argumenten voorkomt verrassingen in stage 2.
Veelgemaakte fouten
SoA invullen met ‘beleid aanwezig’ zonder operationeel bewijs — auditors openen tickets en logs, niet alleen PDF’s. Copy-paste van andere organisatie zonder stack-specifieke implementatie.
Controls als n.v.t. markeren zonder rationale — bijvoorbeeld A.8.24 cryptografie negeren terwijl TLS en database-encryptie wel bestaan. Inconsistentie tussen SoA en werkelijke configuratie.
SoA los van risicoregister — controls toegevoegd omdat ‘het moet’ zonder risico-koppeling. Geen eigenaar per control; niemand voelt zich verantwoordelijk voor updates.
Vergeten dat HR-controls (screening, awareness) en fysieke controls (clean desk) ook steekproeven krijgen — niet alleen technische maatregelen.
Praktisch stappenplan
Export Annex A 2022 als basis; kolommen: toepassing, implementatie, risico, eigenaar, bewijs. Werk top-down: identity, logging, development, leveranciers, incidenten. Koppel risicoanalyse.
Per control minstens één bewijsvoorbeeld in evidence map — screenshot, export, ticket. Dry-run: auditor rol — kies 5 willekeurige controls en verzamel bewijs binnen 2 uur.
Publiceer read-only SoA-samenvatting voor sales/legal met goedgekeurde formuleringen — geen ruwe interne notities naar klanten. Zie bewijslast en documentatie.
Plan kwartaal SoA-review na pentest, interne audit of leveranciersincident — nieuwe bevindingen moeten binnen 30 dagen in SoA of risicoregister landen.
Relatie met ISO 27001, NIS2, AVG of ISMS
SoA operationaliseert ISMS controls voor certificering. NIS2 overlap: logging, incidentmelding, keten — tag die controls in SoA voor dubbele rapportage.
AVG: privacy controls (retentie, rechten betrokkenen) mappen vaak naar A.5 en A.8 — houd één SoA, geen parallel privacy-control matrix zonder sync.
Scope bepaalt welke controls überhaupt relevant zijn. Auditvoorbereiding gebruikt SoA als steekproefindex.
Surveillance-audits vergelijken SoA met vorig jaar — behandel wijzigingen als normale change met impact op risico en klantcommunicatie.
Map SoA-controls op concrete configuratie-items waar mogelijk — bijvoorbeeld ‘A.8.24’ verwijst naar TLS-policy in load balancer en encryption-at-rest in database parameter group.
Gebruik statusvelden: planned, operating, not applicable — MT ziet dan eerlijke voortgang zonder alles op ‘implemented’ te zetten vóór audit.
Controls rond secure development (A.8.25–A.8.32) vragen om koppeling met CI/CD evidence — branch protection, SAST, dependency scanning — niet alleen een SDLC PDF.
Fysieke controls blijven relevant voor kantoor en thuiswerk: clean desk, bezoekerslog — ook hybride SaaS teams krijgen hier steekproeven.
Externe partijen (pentest, SOC) leveren bevindingen die SoA-updates triggeren — leg dat ritme vast in contract en interne procedure.
Controles rond logging en monitoring (A.8.15–A.8.16) koppelen aan concrete SIEM-regels, retentie en alert-routing — auditors volgen één alert van detectie tot ticket-afsluiting.
SoA voor cloud-native stacks benoemt shared responsibility: welke controles de hyperscaler dekt versus welke jij op applicatieniveau implementeert — voorkomt dubbele claim en gaten.
Implementatiekolom noemt concreet systeem en config object — ‘IAM via Entra ID conditional access policies X/Y, review quarterly ticket Z’ overleeft stage 2 beter dan ‘access control implemented’.
SoA-wijzigingen na pentest of klantincident binnen 30 dagen — openstaande bevindingen zonder SoA-update zijn klassieke minor bij surveillance.
SoA materiële wijziging vastgelegd in management review — delta review is surveillance focus.
Export SoA naar CSV voor CB pre-review — kolom gaps vangen vóór stage 1 planning.
Gebruik consistente control-ID’s uit Annex A 2022 — mixen van 2013- en 2022-nummers verwarrt auditors en interne teams. Houd een mapping-tabel bij als je van een oud framework migreert.
Koppel SoA-regels aan concrete configuratie-artefacten: Okta-groepen voor A.5.15, branch protection rules voor A.8.25, backup job IDs voor A.8.13 — auditors volgen graag van control naar systeem.
Plan kwartaalreview van SoA met product en engineering: nieuwe microservices, API’s of data-export features kunnen controls relevant maken die eerder ‘n.v.t.’ waren.
Documenteer compensating controls wanneer je een Annex A-control deels implementeert — bijvoorbeeld fysieke toegang uitbesteed aan cloudprovider met SOC 2 plus eigen logical access controls.
Exporteer SoA naar CSV vóór stage 1 zodat de certificeringsinstantie gaps kan signaleren — dat voorkomt verrassingen over ontbrekende implementatiebeschrijvingen in stage 2.
SoA-wijzigingen na major release documenteren in change log met impact op risico-ID — auditors vergelijken release notes met SoA-datum.
Shared responsibility in cloud: SoA beschrijft welke controls provider dekt (SOC 2) en welke jij implementeert — geen grijs gebied zonder eigenaar.
Control owners in SoA moeten real people zijn met deputy — generieke ‘IT’ eigenaar faalt in interviews wanneer auditors naar specifieke besluiten vragen.