ISMS Copilot Docs

Wat is een Verklaring van Toepasselijkheid (SoA)?

De Verklaring van Toepasselijkheid (SoA) is een verplicht ISO 27001-document dat alle 93 bijlage A-controles opsomt en uitlegt of elke controle is opgenomen in…

Overzicht

De Verklaring van Toepasselijkheid (SoA) is een verplicht ISO 27001-document dat alle 93 bijlage A-controles opsomt en uitlegt of elke controle is opgenomen in uw ISMS of is uitgesloten. Voor opgenomen controles wordt beschreven hoe deze worden geïmplementeerd. Voor uitgesloten controles wordt een rechtvaardiging voor uitsluiting gegeven.

Wat het in de praktijk betekent

De SoA is uw blauwdruk voor controlekeuze - het verbindt de resultaten van uw risicobeoordeling met de specifieke beveiligingscontroles die u hebt gekozen om te implementeren. Auditors gebruiken het als hun routekaart om te verifiëren dat uw ISMS de geïdentificeerde risico's op de juiste manier aanpakt.

Praktijkvoorbeeld: Uw risicobeoordeling identificeert ransomware als een kritieke dreiging. Uw SoA zou controle A.8.7 (Bescherming tegen malware) als "Opgenomen" tonen met implementatiedetails zoals "Endpoint detection and response-software geïmplementeerd op alle apparaten met gecentraliseerd beheer," terwijl controle A.7.4 (Fysieke beveiligingsmonitoring) mogelijk "Uitgesloten - organisatie is volledig cloudgebaseerd zonder fysiek datacenter" is.

Waarom de SoA belangrijk is voor ISO 27001

Verplichte vereiste

ISO 27001 Clause 6.1.3(d) vereist expliciet het onderhouden van "een Verklaring van Toepasselijkheid die de noodzakelijke controles en rechtvaardiging voor opname en uitsluiting bevat." U kunt geen certificering behalen zonder een complete, nauwkeurige SoA.

Toont een risicogebaseerde aanpak

De SoA bewijst dat u niet willekeurig controles implementeert of blindelings sjablonen toepast. Het laat zien hoe elke controlebeslissing terug te voeren is op uw risicobeoordeling.

Auditroutekaart

Auditors gebruiken uw SoA om te plannen wat ze zullen verifiëren tijdens certificeringsaudits. Opgenomen controles moeten bewijs van implementatie en effectiviteit hebben. Uitsluitingen moeten worden gerechtvaardigd op basis van risicobeoordeling of bedrijfscontext.

Wijzigingsbeheer

Naarmate risico's evolueren, moet uw SoA worden bijgewerkt om nieuwe controlevereisten weer te geven of eerder uitgesloten controles te verwijderen als risico's afnemen.

Veelvoorkomende auditbevinding: SoA-rechtvaardigingen die niet overeenkomen met de resultaten van de risicobeoordeling. Het uitsluiten van back-upcontroles (A.8.13) terwijl uw risicobeoordeling gegevensverlies als een hoog risico identificeert, zal bijvoorbeeld leiden tot een non-conformiteit.

Wat de SoA moet bevatten

Volledige controlelijst

Alle 93 bijlage A-controles uit ISO 27001:2022 moeten in uw SoA voorkomen, georganiseerd per thema:

  • Organisatorische controles: A.5.1 tot en met A.5.37 (37 controles)
  • Personeelscontroles: A.6.1 tot en met A.6.8 (8 controles)
  • Fysieke controles: A.7.1 tot en met A.7.14 (14 controles)
  • Technologische controles: A.8.1 tot en met A.8.34 (34 controles)

Opname-/uitsluitingsstatus

Geef voor elke controle duidelijk aan of deze is opgenomen in uw ISMS of is uitgesloten. Vermijd dubbelzinnige statussen zoals "gedeeltelijk van toepassing" - controles zijn ofwel inbegrepen of uitgesloten.

Implementatiebeschrijving (voor opgenomen controles)

Beschrijf kort hoe u elke opgenomen controle implementeert. Neem op:

  • Specifieke beleidsregels, procedures of gebruikte technologieën
  • Wie verantwoordelijk is voor de controle
  • Waar bewijs van implementatie te vinden is
  • Hoe de controle de geïdentificeerde risico's aanpakt

Uitsluitingsrechtvaardiging (voor uitgesloten controles)

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

  • Risicogebaseerd: "Geen risico's in onze beoordeling vereisen deze controle"
  • Contextgebaseerd: "Niet van toepassing - we zijn volledig cloudgebaseerd zonder fysieke infrastructuur"
  • Wettelijk/regulatoir: "Verboden door wetten inzake gegevensresidentie in onze rechtsgebied"

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

SoA-structuur en -indeling

Tabelindeling (meest gebruikelijk)

Een tabel met kolommen voor:

  • Controlenummer (bijv. A.5.1)
  • Controlenaam (bijv. "Beleid voor informatiebeveiliging")
  • Status (Opgenomen / Uitgesloten)
  • Implementatiebeschrijving of uitsluitingsrechtvaardiging
  • Risicoreferentie (koppeling naar risicoregister)
  • Locatie van bewijs (optioneel maar nuttig)

Narratieve indeling

Sommige organisaties geven de voorkeur aan een narratief document dat de controle-implementatie per thema beschrijft. Minder gebruikelijk maar acceptabel als het alle 93 controles duidelijk behandelt.

Op tools gebaseerde indeling

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

Voorkeur van auditors: De meeste auditors geven de voorkeur aan tabelvormige SoA's omdat ze gemakkelijk te scannen en te vergelijken zijn. Houd implementatiebeschrijvingen beknopt (2-3 zinnen per controle) - gedetailleerde procedures horen in aparte proceduredocumenten, niet in de SoA.

Het opstellen van uw SoA

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 controles moeten worden geïmplementeerd.

Stap 2: Koppel controles aan risico's

Identificeer voor elk risico dat behandeling vereist welke bijlage A-controles het tot een acceptabel niveau zouden verminderen. Eén risico kan meerdere controles vereisen; één controle kan meerdere risico's aanpakken.

Stap 3: Bepaal opname/uitsluiting

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

Stap 4: Beschrijf de implementatie

Documenteer voor opgenomen controles hoe u deze implementeert. Wees specifiek genoeg zodat auditors uw aanpak begrijpen zonder volledige procedures te dupliceren.

Stap 5: Rechtvaardig uitsluitingen

Leg voor uitgesloten controles uit waarom, gebaseerd op uw risicobeoordeling of organisatorische context. Verwijs waar mogelijk naar specifieke bevindingen uit uw risicoregister.

Stap 6: Beoordeling en goedkeuring

Het management moet de SoA formeel beoordelen en goedkeuren, waarbij de controlekeuzes en eventuele restrisico's worden erkend.

Versiebeheer: De SoA is een levend document dat moet worden bijgewerkt wanneer risico's veranderen, controles worden toegevoegd of gewijzigd, of uitsluitingen worden heroverwogen. Houd een versiegeschiedenis bij die laat zien wanneer en waarom wijzigingen zijn aangebracht.

Veelvoorkomende SoA-fouten

Te veel controles uitsluiten

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

Generieke implementatiebeschrijvingen

Het kopiëren van controlebeschrijvingen uit ISO 27002 zonder uw daadwerkelijke implementatie te beschrijven. Auditors moeten begrijpen wat u doet, niet wat de standaard zegt.

Ontbrekende risicoverbindingen

Het niet koppelen van controles aan specifieke risico's in uw risicobeoordeling. Dit verbreekt de traceerbaarheid en suggereert dat controles willekeurig zijn geselecteerd.

Onvolledige dekking

Vergeten alle 93 controles te behandelen. Zelfs als een controle duidelijk niet van toepassing lijkt, moet deze in de SoA voorkomen met een uitsluitingsrechtvaardiging.

Geen beoordelingscyclus

Het eenmalig opstellen van de SoA tijdens de initiële 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 resultaten van de risicobeoordeling en context.

SoA versus andere ISO 27001-documenten

SoA versus Risicobehandelingsplan

Het Risicobehandelingsplan beschrijft hoe u geselecteerde controles implementeert (tijdlijnen, verantwoordelijkheden, middelen). De SoA verklaart welke controles zijn geïmplementeerd en waarom. De twee documenten vullen elkaar aan.

SoA versus Controlebewijs

De SoA beschrijft welke controles u implementeert. Bewijs toont aan dat de controles daadwerkelijk effectief werken. Tijdens audits nemen auditors steekproeven van controles uit uw SoA en vragen om het bijbehorende bewijs.

SoA versus Beleid en Procedures

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

Hoe auditors de SoA gebruiken

Fase 1-audit (documentatiebeoordeling)

Auditors verifiëren of uw SoA compleet is (alle 93 controles behandeld), logisch gestructureerd is en overeenkomt met uw risicobeoordeling. Ze controleren of de rechtvaardigingen voor uitsluitingen zinvol zijn.

Fase 2-audit (verificatie van implementatie)

Auditors nemen steekproeven van controles uit uw SoA en vragen om bewijs dat deze zijn geïmplementeerd zoals beschreven. Ze zullen controles testen in alle vier de thema's en organisatorische gebieden binnen de scope.

Oorzaken van non-conformiteit

Veelvoorkomende redenen waarom auditors non-conformiteiten met betrekking tot de SoA vaststellen:

  • Controles gemarkeerd als "opgenomen" maar niet daadwerkelijk geïmplementeerd
  • Uitsluitingen zonder geldige rechtvaardiging
  • SoA weerspiegelt niet de werkelijke resultaten van de risicobeoordeling
  • Ontbrekende controles (minder dan 93 vermeld)
  • Implementatiebeschrijvingen te vaag om te verifiëren

Voorbereiding op audit: Controleer vóór de certificeringsaudit elke "opgenomen" controle in uw SoA en verzamel het bijbehorende bewijs. Als u geen bewijs voor een controle kunt vinden, implementeer deze dan correct of werk de SoA bij om deze uit te sluiten met rechtvaardiging.

Het onderhouden van de SoA in de loop van de tijd

Jaarlijkse updates van de risicobeoordeling

Wanneer u geplande risicobeoordelingen uitvoert, controleer dan de SoA om te bepalen of de controlekeuzes nog steeds geschikt zijn. Nieuwe risico's kunnen eerder uitgesloten controles vereisen.

Organisatorische wijzigingen

Werk de SoA bij wanneer:

  • Nieuwe technologie wordt geïmplementeerd (kan nieuwe technische controles vereisen)
  • Het bedrijfsmodel verandert (bijv. overstappen naar de cloud verandert fysieke controles)
  • Geografische uitbreiding nieuwe regelgevende vereisten introduceert
  • Fusies of overnames het risicoprofiel veranderen

Incidentgestuurde beoordelingen

Na significante beveiligingsincidenten, beoordeel dan of bestaande controles effectief waren of dat aanvullende controles (eerder uitgesloten) moeten worden geïmplementeerd.

Toezichtaudits

Auditors zullen tijdens jaarlijkse toezichtaudits controleren of de SoA actueel is gehouden. Bewijs van regelmatige beoordeling toont aan dat uw ISMS actief is, en niet na certificering is verlaten.

SoA en controleaanpassing

Standaard staat maatwerk toe

ISO 27001 staat organisaties toe om controles anders te implementeren op basis van grootte, complexiteit en risico. Uw SoA moet uw specifieke implementatie weerspiegelen, niet een generiek sjabloon.

Aanvullende controles buiten bijlage A

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

Proportionaliteit is belangrijk

De implementatie van "A.6.3 Bewustmakingsopleiding voor informatiebeveiliging" door een startup met 10 personen zal verschillen van die van een onderneming met 10.000 medewerkers. Beide kunnen compliant zijn als ze passen bij de context en effectief zijn in het verminderen van risico's.

Voorbeeld van proportionele implementatie: Een kleine, volledig cloudgebaseerde SaaS-organisatie kan A.7.1-A.7.14 (fysieke controles) uitsluiten door te rechtvaardigen: "Geen fysieke infrastructuur - alle systemen draaien in AWS met beveiliging 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 opstellen 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 controles correct worden behandeld.

On this page