ISMS Copilot
ISO 27001-begrippenlijst

Wat is een Verklaring van Toepasselijkheid (SoA)?

Overzicht

De Verklaring van Toepasselijkheid (Statement of Applicability of SoA) is een verplicht ISO 27001-document waarin alle 93 Annex A-beheersmaatregelen worden opgesomd en waarin wordt uitgelegd of elke maatregel is opgenomen in uw ISMS of is uitgesloten. Voor opgenomen maatregelen wordt beschreven hoe ze zijn geïmplementeerd. Voor uitgesloten maatregelen wordt een rechtvaardiging voor uitsluiting gegeven.

Wat het in de praktijk betekent

De SoA is het blauwdruk voor uw selectie van beheersmaatregelen - het verbindt de resultaten van uw risicobeoordeling met de specifieke beveiligingsmaatregelen die u hebt gekozen om te implementeren. Auditoren gebruiken de SoA als hun roadmap om te verifiëren of uw ISMS de geïdentificeerde risico's op de juiste manier aanpakt.

Voorbeeld uit de praktijk: Uw risicobeoordeling identificeert ransomware als een kritieke dreiging. Uw SoA toont maatregel A.8.7 (Bescherming tegen malware) als "Opgenomen" met implementatiedetails zoals "Endpoint detection and response software geïmplementeerd op alle apparaten met gecentraliseerd beheer", terwijl maatregel A.7.4 (Fysieke beveiligingsbewaking) mogelijk wordt "Uitgesloten - organisatie werkt volledig in de cloud en heeft geen fysiek datacenter."

Waarom de SoA belangrijk is voor ISO 27001

Verplichte vereiste

ISO 27001 Clausule 6.1.3(d) vereist expliciet het bijhouden van "een Verklaring van Toepasselijkheid met de noodzakelijke beheersmaatregelen en de rechtvaardiging voor opname en uitsluiting." U kunt geen certificering behalen zonder een volledige, nauwkeurige SoA.

Aantonen van een risicogebaseerde aanpak

De SoA bewijst dat u niet lukraak maatregelen implementeert of blindelings sjablonen toepast. Het laat zien hoe elke beslissing over een beheersmaatregel terug te voeren is op uw risicobeoordeling.

Audit roadmap

Auditoren gebruiken uw SoA om te plannen wat ze tijdens certificeringsaudits zullen verifiëren. Voor opgenomen maatregelen is bewijs van implementatie en effectiviteit nodig. Uitsluitingen moeten worden gerechtvaardigd op basis van de risicobeoordeling of de bedrijfscontext.

Veranderbeheer

Naarmate risico's evolueren, moet uw SoA worden bijgewerkt om nieuwe vereisten voor beheersmaatregelen te weerspiegelen of om eerder uitgesloten maatregelen te verwijderen als de risico's afnemen.

Veelvoorkomende auditbevinding: SoA-rechtvaardigingen die niet overeenkomen met de resultaten van de risicobeoordeling. Bijvoorbeeld, het uitsluiten van back-upmaatregelen (A.8.13) terwijl uw risicobeoordeling dataverlies als een hoog risico identificeert, zal leiden tot een afwijking (non-conformity).

Wat de SoA moet bevatten

Volledige lijst met beheersmaatregelen

Alle 93 Annex A-beheersmaatregelen van ISO 27001:2022 moeten in uw SoA verschijnen, georganiseerd per thema:

  • Organisatorische maatregelen: A.5.1 tot en met A.5.37 (37 maatregelen)

  • Personeelsgerelateerde maatregelen: A.6.1 tot en met A.6.8 (8 maatregelen)

  • Fysieke maatregelen: A.7.1 tot en met A.7.14 (14 maatregelen)

  • Technologische maatregelen: A.8.1 tot en met A.8.34 (34 maatregelen)

Status van opname/uitsluiting

Vermeld voor elke maatregel duidelijk of deze is opgenomen in uw ISMS of uitgesloten. Vermijd ambigue statussen zoals "gedeeltelijk van toepassing" - maatregelen zijn ofwel in of uit.

Beschrijving van de implementatie (voor opgenomen maatregelen)

Beschrijf kort hoe u elke opgenomen maatregel implementeert. Vermeld:

  • Specifieke beleidsregels, procedures of gebruikte technologieën

  • Wie verantwoordelijk is voor de maatregel

  • Waar bewijs van implementatie kan worden gevonden

  • Hoe de maatregel de geïdentificeerde risico's aanpakt

Rechtvaardiging voor uitsluiting (voor uitgesloten maatregelen)

Leg uit waarom uitgesloten maatregelen geen deel uitmaken van uw ISMS. Geldige rechtvaardigingen zijn:

  • Op basis van risico: "Geen risico's in onze beoordeling vereisen deze maatregel"

  • Op basis van context: "Niet van toepassing - wij werken volledig in de cloud zonder fysieke infrastructuur"

  • Wettelijk/regulatorisch: "Verboden door wetgeving inzake datalocatie in ons rechtsgebied"

Kwaliteit van de rechtvaardiging: Sterke rechtvaardigingen voor uitsluiting verwijzen naar specifieke bevindingen uit de risicobeoordeling of de organisatorische context. Zwakke rechtvaardigingen zoals "niet relevant" of "nog niet geïmplementeerd" zullen door auditoren worden betwist.

SoA-structuur en formaat

Tabelvorm (meest voorkomend)

Een tabel met kolommen voor:

  • Nummer van de maatregel (bijv. A.5.1)

  • Naam van de maatregel (bijv. "Informatiebeveiligingsbeleid")

  • Status (Opgenomen / Uitgesloten)

  • Implementatiebeschrijving of rechtvaardiging voor uitsluiting

  • Risicoverwijzing (koppeling naar het risicoregister)

  • Locatie van bewijs (optioneel maar handig)

Beschrijvende vorm

Sommige organisaties geven de voorkeur aan een beschrijvend document waarin de implementatie van maatregelen per thema is gegroepeerd. Dit komt minder vaak voor, maar is acceptabel als het alle 93 maatregelen duidelijk behandelt.

Tool-gebaseerd formaat

GRC-platforms en ISMS-tools genereren SoA's vaak automatisch op basis van de selectie van maatregelen en de koppeling met risicobeoordelingen. Deze moeten nog steeds handmatig worden gevalideerd op nauwkeurigheid.

Voorkeur van de auditor: De meeste auditoren geven de voorkeur aan een SoA in tabelvorm omdat deze gemakkelijk te scannen en te kruisverwijzen is. Houd implementatiebeschrijvingen beknopt (2-3 zinnen per maatregel) - gedetailleerde procedures horen thuis in afzonderlijke proceduredocumenten, niet in de SoA.

Uw SoA opstellen

Stap 1: Voltooi de risicobeoordeling

Uw SoA is een direct resultaat van de risicobeoordeling. Identificeer alle risico's die behandeling vereisen voordat u bepaalt welke maatregelen u gaat implementeren.

Stap 2: Koppel maatregelen aan risico's

Identificeer voor elk risico dat behandeling vereist welke Annex A-maatregelen dit tot een acceptabel niveau zouden verlagen. Eén risico kan meerdere maatregelen vereisen; één maatregel kan meerdere risico's aanpakken.

Stap 3: Bepaal opname/uitsluiting

Maatregelen die geïdentificeerde risico's aanpakken, worden opgenomen. Maatregelen die geen van uw risico's aanpakken, kunnen worden uitgesloten (met rechtvaardiging).

Stap 4: Beschrijf de implementatie

Documenteer voor de opgenomen maatregelen hoe u deze implementeert. Wees specifiek genoeg zodat auditoren uw aanpak begrijpen zonder dat u volledige procedures kopieert.

Stap 5: Rechtvaardig uitsluitingen

Leg voor uitgesloten maatregelen uit waarom ze buiten beschouwing worden gelaten op basis van uw risicobeoordeling of organisatorische context. Verwijs waar mogelijk naar specifieke bevindingen in uw risicoregister.

Stap 6: Beoordelen en goedkeuren

Het management moet de SoA formeel beoordelen en goedkeuren, waarbij de beslissingen over de selectie van maatregelen en eventuele restrisico's worden erkend.

Versiebeheer: De SoA is een levend document dat moet worden bijgewerkt wanneer risico's veranderen, maatregelen worden toegevoegd of gewijzigd, of uitsluitingen worden heroverwogen. Houd een versiehistorie bij waarin staat wanneer en waarom wijzigingen zijn doorgevoerd.

Veelvoorkomende fouten bij de SoA

Te veel maatregelen uitsluiten

Organisaties sluiten soms maatregelen uit om de implementatie-inspanning te verminderen. Auditoren onderzoeken uitsluitingen zorgvuldig - als uw risicobeoordeling grondig is, moeten de meeste maatregelen worden opgenomen.

Generieke implementatiebeschrijvingen

Het kopiëren van beschrijvingen van maatregelen uit ISO 27002 zonder uw werkelijke implementatie te beschrijven. Auditoren moeten begrijpen wat u doet, niet wat de standaard zegt.

Ontbrekende risicokoppelingen

Het niet terugkoppelen van maatregelen naar specifieke risico's in uw risicobeoordeling. Dit verbreekt de traceerbaarheid en suggereert dat maatregelen willekeurig zijn geselecteerd.

Onvolledige dekking

Vergeten om alle 93 maatregelen te behandelen. Zelfs als een maatregel duidelijk niet van toepassing lijkt, moet deze in de SoA verschijnen met een rechtvaardiging voor uitsluiting.

Geen beoordelingscyclus

De SoA eenmalig opstellen tijdens de eerste implementatie en deze nooit bijwerken, ondanks organisatorische wijzigingen of nieuwe risico's.

Efficiëntietip: Gebruik ISMS Copilot om een SoA-sjabloon te genereren met veelvoorkomende implementatiebeschrijvingen voor uw branche. Pas de output aan op basis van uw specifieke risicobeoordelingsresultaten en context.

SoA vergeleken met andere ISO 27001-documenten

SoA vs. Risicobehandelplan

Het Risicobehandelplan (Risk Treatment Plan) beschrijft in detail hoe u de geselecteerde maatregelen gaat implementeren (tijdlijnen, verantwoordelijkheden, middelen). De SoA verklaart welke maatregelen zijn geïmplementeerd en waarom. De twee documenten vullen elkaar aan.

SoA vs. Bewijs van maatregelen

De SoA beschrijft welke maatregelen u implementeert. Bewijs bewijst dat de maatregelen daadwerkelijk effectief werken. Tijdens audits nemen auditoren steekproeven van maatregelen uit uw SoA en vragen zij om het bijbehorende bewijs.

SoA vs. Beleid en procedures

Beleid en procedures bieden gedetailleerde instructies voor het implementeren van maatregelen. De SoA vat op een hoog niveau samen welke maatregelen er bestaan en hoe ze werken.

Hoe auditoren de SoA gebruiken

Fase 1-audit (beoordeling documentatie)

Auditoren verifiëren of uw SoA volledig is (alle 93 maatregelen behandeld), logisch gestructureerd en in lijn met uw risicobeoordeling. Ze controleren of de rechtvaardigingen voor uitsluitingen logisch zijn.

Fase 2-audit (verificatie implementatie)

Auditoren nemen steekproeven van maatregelen uit uw SoA en vragen bewijs dat ze zijn geïmplementeerd zoals beschreven. Ze testen maatregelen in alle vier de thema's en organisatorische gebieden binnen de scope.

Aanleidingen voor afwijkingen

Veelvoorkomende redenen waarom auditoren afwijkingen (non-conformities) vaststellen met betrekking tot de SoA:

  • Maatregelen die als "opgenomen" zijn gemarkeerd, maar niet daadwerkelijk zijn geïmplementeerd

  • Uitsluitingen zonder geldige rechtvaardiging

  • De SoA weerspiegelt niet de werkelijke resultaten van de risicobeoordeling

  • Ontbrekende maatregelen (minder dan 93 vermeld)

  • Implementatiebeschrijvingen die te vaag zijn om te verifiëren

Auditvoorbereiding: Beoordeel vóór de certificeringsaudit elke "opgenomen" maatregel in uw SoA en verzamel het bijbehorende bewijs. Als u geen bewijs kunt vinden voor een maatregel, moet u deze ofwel correct implementeren of de SoA bijwerken om deze met rechtvaardiging uit te sluiten.

De SoA in de loop van de tijd onderhouden

Jaarlijkse updates van de risicobeoordeling

Wanneer u geplande risicoherbeoordelingen uitvoert, bekijk dan de SoA om te bepalen of de selectie van maatregelen passend blijft. Nieuwe risico's kunnen voorheen uitgesloten maatregelen vereisen.

Organisatorische wijzigingen

Werk de SoA bij wanneer:

  • Nieuwe technologie wordt geïmplementeerd (kan nieuwe technische maatregelen vereisen)

  • Het bedrijfsmodel verandert (bijv. de overgang naar de cloud verandert de fysieke maatregelen)

  • Geografische expansie nieuwe wettelijke vereisten met zich meebrengt

  • Fusies of overnames het risicoprofiel veranderen

Herzieningen naar aanleiding van incidenten

Beoordeel na significante beveiligingsincidenten of bestaande maatregelen effectief waren en of aanvullende maatregelen (die voorheen waren uitgesloten) moeten worden geïmplementeerd.

Surveillance-audits

Auditoren zullen tijdens jaarlijkse surveillance-audits controleren of de SoA actueel is gehouden. Bewijs van regelmatige beoordeling toont aan dat uw ISMS actief is en niet is verwaarloosd na de certificering.

SoA en aanpassing van maatregelen

De standaard staat maatwerk toe

ISO 27001 staat organisaties toe om maatregelen verschillend te implementeren op basis van omvang, complexiteit en risico. Uw SoA moet uw specifieke implementatie weerspiegelen, geen generiek sjabloon.

Aanvullende maatregelen buiten Annex A

Als uw risicobeoordeling risico's identificeert die niet voldoende worden aangepakt door de 93 standaardmaatregelen, kunt u aanvullende maatregelen implementeren. Vermeld deze in uw SoA of een aanvullend document.

Proportionaliteit is belangrijk

De implementatie van "A.6.3 Informatiebeveiligingsbewustzijn, opleiding en training" door een startup met 10 personen zal anders zijn dan die van een onderneming met 10.000 personen. Beiden kunnen compliant zijn als het passend is voor de context en effectief is in het verminderen van risico's.

Voorbeeld van proportionele implementatie: Een klein SaaS-bedrijf dat volledig in de cloud werkt, zou A.7.1-A.7.14 (fysieke maatregelen) kunnen uitsluiten met de rechtvaardiging: "Geen fysieke infrastructuur - alle systemen draaien in AWS waarbij de beveiliging wordt beheerd door de SOC 2-controles van de cloudprovider." Dit is acceptabel als hun risicobeoordeling de cloud-first-architectuur weerspiegelt.

Gerelateerde concepten

Hulp krijgen

Versnel het maken van de SoA met ISMS Copilot. Genereer aangepaste implementatiebeschrijvingen, valideer uw rechtvaardigingen aan de hand van de resultaten van de risicobeoordeling en zorg ervoor dat alle 93 maatregelen correct worden behandeld.

Was dit nuttig?