Veel organisaties die met ISO 27001 starten, kijken al snel naar Annex A. Daar staan de informatiebeveiligingsmaatregelen. De reflex is begrijpelijk: controleren wat al geregeld is, aanvinken wat bekend voorkomt en daarna de openstaande punten oppakken.
Maar ISO 27001 werkt niet als een simpele afvinklijst. De echte vraag is niet: hebben we deze maatregel? De vraag is: waarom is deze maatregel voor ons relevant, hoe hebben we hem ingericht en kunnen we die keuze uitleggen?
Daar begint de Statement of Applicability.
De Statement of Applicability, vaak afgekort als SoA, is een verplicht onderdeel van het ISMS binnen ISO 27001. Niet omdat de norm om extra papierwerk vraagt, maar omdat de SoA zichtbaar maakt hoe je van risico’s naar maatregelen komt.
Welke maatregelen zijn passend? Welke maatregelen zijn niet van toepassing? Welke risico’s accepteer je bewust? En waar is verbetering nodig?
Wie de SoA goed gebruikt, maakt informatiebeveiliging bestuurbaar. Wie de SoA alleen invult voor de audit, mist juist de waarde ervan.
Wat is een Statement of Applicability?
Een Statement of Applicability is het overzicht waarin je vastlegt welke informatiebeveiligingsmaatregelen je hebt geselecteerd, welke Annex A-maatregelen van toepassing zijn en waarom bepaalde maatregelen eventueel niet van toepassing zijn.
In de praktijk kijk je daarbij naar Annex A van ISO 27001. Daarin staan de referentiemaatregelen die helpen om breed naar informatiebeveiliging te kijken. Annex A is daarbij het referentiekader, maar niet de grens van je beveiligingsaanpak. Als uit je risicoanalyse aanvullende maatregelen nodig blijken, moeten die ook logisch in je ISMS terugkomen.
In de SoA leg je vast welke maatregelen je toepast, welke nog aandacht vragen en welke niet van toepassing zijn. Minstens zo belangrijk is dat je vastlegt waarom.
Daarmee is de SoA meer dan een statusoverzicht. Het is de plek waar je keuzes onderbouwt. Een checklist zegt vooral wat je hebt aangevinkt. Een goede SoA laat zien waarom een maatregel wel of niet past bij jouw risico’s, systemen, processen, leveranciers, klanten en verplichtingen.
De SoA vormt zo de verbinding tussen risicoanalyse, maatregelen en bewijsvoering. Dat maakt het document belangrijk voor auditors, maar ook voor management en klanten die willen begrijpen hoe informatiebeveiliging is ingericht.
Annex A is geen afvinklijst
Een veelgemaakt misverstand is dat Annex A een lijst is die je van boven naar beneden moet afwerken. Dat lijkt overzichtelijk, maar leidt vaak tot verkeerde keuzes.
Soms worden maatregelen ingevoerd omdat ze in de norm staan, terwijl ze weinig bijdragen aan het beheersen van de werkelijke risico’s. Soms worden maatregelen juist overgeslagen omdat ze niet direct herkenbaar lijken, zonder dat goed is onderbouwd waarom ze niet nodig zijn.
Annex A is beter te zien als een referentieset. De maatregelen helpen je om niets belangrijks over het hoofd te zien. Denk aan toegangsbeheer, leveranciersrelaties, logging, fysieke beveiliging, incidentmanagement en bewustwording.
Maar de keuze voor maatregelen blijft afhankelijk van jouw context en risicoanalyse. Een organisatie die volledig remote werkt, heeft andere fysieke beveiligingsrisico’s dan een productiebedrijf met een magazijn, bezoekersstromen en technische installaties. Dat betekent niet dat fysieke beveiliging genegeerd mag worden. Het betekent wel dat je moet uitleggen welke risico’s er zijn en welke maatregelen daarbij passen.
Annex A helpt je breed te kijken. De SoA helpt je gericht te kiezen.
Wat moet er in een goede SoA staan?
Een goede SoA hoeft geen dik verhaal te zijn, maar moet wel per maatregel voldoende duidelijk maken waarom deze wel of niet van toepassing is.
Een goede SoA maakt per maatregel duidelijk:
- of de maatregel van toepassing is;
- waarom die keuze logisch is;
- wat de implementatiestatus is;
- welk risico of welke verplichting erbij hoort;
- wie eigenaar is;
- welk bewijs beschikbaar is.
De kern zit vooral in de onderbouwing.
Een maatregel met de status “geïmplementeerd” zegt weinig als niet duidelijk is waarop dat oordeel is gebaseerd. Is er beleid? Wordt het proces uitgevoerd? Is er bewijs? Is iemand verantwoordelijk? Wordt de werking periodiek beoordeeld?
Andersom is een maatregel met de status “niet van toepassing” kwetsbaar als de toelichting niet verder komt dan “niet relevant”. Dat roept bij een auditor bijna automatisch vervolgvragen op. Waarom niet relevant? Valt het buiten scope? Bestaat het proces niet? Is het risico op een andere manier beheerst? Of is er simpelweg niet goed genoeg naar gekeken?
Een goede SoA is daarom precies genoeg. Niet te mager, want dan is hij niet verdedigbaar. Niet te uitgebreid, want dan wordt hij onbruikbaar.
De koppeling tussen risicoanalyse en SoA
ISO 27001 draait om een risicogebaseerde aanpak. Dat betekent dat je niet begint met maatregelen, maar met risico’s. Welke informatie wil je beschermen? Welke bedreigingen zijn relevant? Welke kwetsbaarheden bestaan er? Wat is de impact als het misgaat?
De risicoanalyse brengt in kaart wat er kan gebeuren en hoe ernstig dat is. De SoA laat vervolgens zien welke maatregelen je kiest om daarmee om te gaan.
Stel dat een organisatie het risico identificeert dat medewerkers slachtoffer worden van phishing. Dat risico raakt niet één maatregel, maar meerdere onderdelen van informatiebeveiliging. Je kunt denken aan bewustwording, toegangsbeheer, multi-factor authenticatie, logging, incidentrespons en e-mailbeveiliging.
In de risicoanalyse staat dan: dit kan misgaan en dit is de mogelijke impact. In de SoA staat: daarom zijn deze maatregelen relevant, zo hebben we ze ingericht en dit is de status.
Dat onderscheid is belangrijk. Zonder risicoanalyse wordt de SoA al snel een checklist. Zonder SoA blijven maatregelen losse keuzes zonder duidelijke samenhang.
Juist de koppeling tussen beide maakt je ISMS uitlegbaar. Je kunt laten zien dat maatregelen niet willekeurig gekozen zijn, maar voortkomen uit risico’s, verplichtingen, klantverwachtingen en de context van je organisatie.
Waarom uitsluitingen extra aandacht vragen
Toegepaste maatregelen zijn vaak makkelijker bespreekbaar, omdat er meestal beleid, inrichting of bewijs tegenover staat. Je kunt laten zien wat is geregeld en hoe dat werkt.
Spannender zijn de maatregelen die je niet toepast.
Een uitsluiting is geen vrijstelling. Het is een keuze. En die keuze moet je kunnen uitleggen.
Zwakke onderbouwingen klinken vaak als: “niet relevant voor ons”, “doen wij niet” of “zijn we te klein voor”. Op zichzelf zeggen die zinnen weinig. Ze maken niet duidelijk waarom een maatregel niet past bij de scope, risico’s, processen, assets of technologie van de organisatie.
Een sterke onderbouwing legt uit waarom het risico niet bestaat, waarom het proces buiten scope valt, waarom de technologie niet wordt gebruikt of waarom het risico op een andere manier wordt beheerst.
Neem een organisatie die geen eigen software ontwikkelt. Bepaalde secure development-maatregelen kunnen dan beperkt of niet van toepassing zijn. Maar als dezelfde organisatie wel maatwerk laat bouwen door een leverancier, verdwijnt het onderwerp niet. De aandacht verschuift dan naar leveranciersbeheer, contractuele eisen, acceptatietesten en wijzigingsbeheer.
Dat is precies het soort nuance dat een goede SoA zichtbaar maakt.
De SoA als gesprek met management
De SoA wordt vaak gezien als iets van de security- of complianceverantwoordelijke. Dat is begrijpelijk, maar te beperkt. De keuzes in de SoA raken namelijk de hele organisatie.
Management hoeft niet ieder technisch detail te kennen, maar moet wel begrijpen welke risico’s bewust worden geaccepteerd, welke maatregelen investering vragen en waar afhankelijkheden bestaan.
Een goede SoA helpt bij vragen als: welke beveiligingsmaatregelen zijn voor ons echt kritisch? Waar accepteren we restrisico? Welke maatregelen zijn nog niet volwassen genoeg? Waar zijn we afhankelijk van leveranciers? Welke verbeteringen zijn nodig voordat certificering realistisch is?
Daarmee wordt de SoA meer dan een auditdocument. Het wordt een hulpmiddel om informatiebeveiliging bestuurbaar te maken.
Dat past ook bij wat ISO 27001 vraagt. De norm draait niet alleen om beveiligingsmaatregelen, maar om een managementsysteem. Een manier om informatiebeveiliging structureel te organiseren, te beoordelen en te verbeteren.
Juist wanneer informatiebeveiliging naast andere verantwoordelijkheden wordt opgepakt, helpt de SoA om te voorkomen dat keuzes alleen in hoofden of losse documenten blijven zitten.
Veelgemaakte fouten bij de SoA
De eerste fout is Annex A behandelen als afvinklijst. Dan ontstaat een document dat formeel compleet lijkt, maar weinig zegt over de werkelijke relevantie van maatregelen.
De tweede fout is het ontbreken van een duidelijke koppeling met risico’s. Maatregelen worden dan losse acties. Je ziet wel wat is ingericht, maar niet welk risico ermee wordt beheerst.
De derde fout is uitsluitingen onvoldoende onderbouwen. “Niet van toepassing” zonder toelichting leidt bijna altijd tot vragen. Zeker wanneer de maatregel op het eerste gezicht wel relevant lijkt.
De vierde fout is de SoA niet actueel houden. Nieuwe systemen, leveranciers, klantvragen, incidenten of wijzigingen in processen kunnen allemaal betekenen dat maatregelen opnieuw beoordeeld moeten worden.
Het onderliggende probleem is vaak hetzelfde: de SoA wordt gezien als document voor de audit, niet als onderdeel van het ISMS. Daardoor ontstaat vlak voor de audit alsnog druk. Keuzes moeten worden gereconstrueerd, bewijs moet worden gezocht en toelichtingen moeten achteraf worden bedacht.
Een sterke SoA voorkomt dat. Niet door alles zwaarder te maken, maar door keuzes vast te houden op het moment dat ze worden gemaakt.
Hoe houd je de SoA praktisch en actueel?
Een SoA hoeft geen zwaar of ingewikkeld document te zijn. Hij moet vooral bruikbaar blijven.
Begin met een duidelijke scope. Waar geldt het ISMS voor? Welke processen, systemen, locaties, diensten en informatie vallen binnen de afbakening? Zonder heldere scope wordt het lastig om te bepalen of een maatregel wel of niet van toepassing is.
Zorg daarna voor een actuele risicoanalyse. De SoA moet niet losstaan van de risico’s die je hebt geïdentificeerd. Als maatregelen en risico’s niet met elkaar verbonden zijn, ontstaat precies het soort papieren werkelijkheid waar niemand iets aan heeft.
Werk vervolgens met eenvoudige statussen. Bijvoorbeeld: van toepassing en ingericht, van toepassing maar verbetering nodig, niet van toepassing met onderbouwing, of gepland en in uitvoering.
De onderbouwing hoeft niet lang te zijn. Een korte, concrete toelichting is vaak sterker dan een algemene alinea. Niet: “niet relevant”. Wel: “niet van toepassing omdat deze activiteit buiten de ISMS-scope valt” of “risico wordt beheerst via contractuele leverancierseisen en periodieke leveranciersbeoordeling”.
De SoA moet daarnaast meebewegen met je organisatie. Een herziening is logisch wanneer je nieuwe systemen of applicaties introduceert, wanneer leveranciers of processen veranderen, wanneer zich een beveiligingsincident voordoet of wanneer interne auditbevindingen laten zien dat maatregelen opnieuw beoordeeld moeten worden.
Ook nieuwe klant- of contracteisen, een gewijzigde scope, een nieuwe risicoanalyse of de voorbereiding op een externe audit kunnen aanleiding zijn om de SoA bij te werken.
Dat betekent niet dat je de SoA continu volledig opnieuw moet opbouwen. Het betekent wel dat hij betrouwbaar moet blijven. Een SoA die niet wordt bijgewerkt, verliest langzaam zijn waarde. Niet omdat het document direct fout is, maar omdat de context verandert. En juist context bepaalt of keuzes nog logisch zijn.
Lichtgewicht betekent niet oppervlakkig. Het betekent dat je precies genoeg structuur gebruikt om keuzes te kunnen uitleggen.
Waar CompliTrack helpt
De uitdaging bij een Statement of Applicability zit zelden alleen in het invullen van een document. De echte uitdaging is samenhang vasthouden.
Als informatie over risico’s, maatregelen, acties, eigenaren, auditbevindingen en bewijs verspreid staat over Excelbestanden, losse documenten, e-mails en mappen, wordt de SoA al snel een momentopname. Vlak voor de audit moet dan worden gereconstrueerd wat eigenlijk doorlopend zichtbaar had moeten zijn.
CompliTrack helpt om die samenhang vast te houden. Maatregelen, risico’s, acties, eigenaren, auditbevindingen en bewijs staan niet los van elkaar, maar worden op één plek verbonden. Daardoor wordt de SoA geen document dat vlak voor de audit wordt bijgewerkt, maar onderdeel van de dagelijkse ISMS-structuur.
Dat maakt het makkelijker om keuzes te onderbouwen. Niet omdat het systeem de keuzes voor je maakt, maar omdat het helpt om onderbouwing, opvolging en bewijsvoering overzichtelijk te bewaren.
Verder lezen
Wil je verder lezen over onderwerpen die direct raken aan de Statement of Applicability?
Lees dan ook Effectieve risicoanalyse: van risico-inventarisatie tot mitigerende maatregelen, waarin wordt uitgelegd hoe je risico’s vertaalt naar beheersmaatregelen.
Ook relevant zijn:
- ISO 27001 Veelgemaakte fouten: 5 valkuilen en hoe je ze voorkomt
- ISO 27001 is geen eindpunt: zo blijf je compliant zonder gedoe
- Wat auditors feitelijk testen, ook als ze het niet zo noemen
Conclusie: ISO 27001 draait om verdedigbare keuzes
De Statement of Applicability is geen administratieve bijlage bij ISO 27001. Het is een van de belangrijkste onderdelen van je ISMS, omdat het laat zien hoe je van risico’s naar maatregelen komt.
Een sterke SoA laat niet alleen zien wat je hebt ingericht, maar vooral waarom. Welke maatregelen zijn relevant? Welke niet? Welke risico’s accepteer je bewust? Waar is verbetering nodig? En hoe weet je dat maatregelen werken?
ISO 27001 gaat niet om zoveel mogelijk maatregelen aanvinken. Het gaat om informatiebeveiliging beheersbaar maken. Dat lukt alleen wanneer je keuzes kunt onderbouwen.
Wil je jouw Statement of Applicability niet als los auditdocument beheren, maar als onderdeel van een praktisch ISMS? Met CompliTrack koppel je ISO 27001-maatregelen aan risico’s, acties, eigenaren en bewijs. Zo kun je keuzes onderbouwen zonder zware of dure tooling. Plan een vrijblijvende demo en ontdek hoe je ISO 27001 beheersbaar houdt.
Geef een reactie