Hvad er Statement of Applicability?
Statement of Applicability (SoA) — på dansk ofte kaldet anvendelighedserklæring — er et centralt dokument i ISO 27001. Det opfører alle kontroller i Annex A og angiver for hver kontrol:
- Om den er anvendelig eller ej
- Begrundelse for beslutningen
- Implementeringsstatus
Indsigt: SoA er ikke en tjekliste at afkrydse. Det er et strategisk dokument, der viser at organisationen har foretaget bevidste, risikobaserede valg omkring sit sikkerhedsarbejde.
Hvorfor er SoA vigtigt?
SoA opfylder flere funktioner:
- Certificeringskrav — Obligatorisk ifølge ISO 27001 klausul 6.1.3
- Kommunikation — Viser interessenter hvilke kontroller I har implementeret
- Reference — Udgangspunkt for intern revision og kontrolopfølgning
- Sporbarhed — Kobler risikovurdering til konkrete tiltag
- Transparens — Dokumenterer bevidste valg og prioriteringer
Uden SoA:
- Ingen ISO 27001-certificering mulig
- Svært at vise systematisk sikkerhedsarbejde
- Risiko for vilkårlige kontrolvalg
ISO 27001:2022 Annex A struktur
De 93 kontroller er organiseret i fire temaer:
| Tema | Antal kontroller | Fokus |
|---|---|---|
| A.5 Organisatoriske | 37 | Politikker, roller, leverandører |
| A.6 Personalerelaterede | 8 | Ansættelse, uddannelse, fratrædelse |
| A.7 Fysiske | 14 | Lokaler, udstyr, miljø |
| A.8 Tekniske | 34 | Systemer, netværk, kryptering |
SoA-processen trin for trin
- Gennemfør risikovurdering først SoA baseres på jeres risikovurdering. Identificer hvilke risici der findes, hvilke aktiver der skal beskyttes og hvilke trusler der er relevante. Uden risikovurdering bliver SoA vilkårlig.
- Opfør alle Annex A-kontroller Opret en tabel med alle 93 kontroller. Inkluder kontrolnummer, navn og beskrivelse. Dette bliver grundlaget for jeres SoA.
- Vurder anvendelighed For hver kontrol: Er den relevant for jeres virksomhed og risikobillede? Svar ja eller nej. Husk at "ikke anvendelig" kræver stærk begrundelse.
- Begrund hver beslutning Uanset om kontrollen er anvendelig eller ej — dokumenter hvorfor. Kob til risikovurderingen. "Implementerer for at håndtere risiko X" eller "Ikke anvendelig da vi ikke har Y".
- Dokumenter implementeringsstatus For anvendelige kontroller: Er den implementeret? Delvist? Planlagt? Angiv status og eventuel deadline.
- Link til dokumentation Kob hver kontrol til relevant politik, procedure eller teknisk implementering. Dette letter revisionen.
- Gennemgå og godkend SoA skal godkendes af ledelsen. Det viser ejerskab og ansvar for sikkerhedsvalgene.
Eksempel på SoA-struktur
| Kontrol | Beskrivelse | Anvendelig | Begrundelse | Status | Dokumentation |
|---|---|---|---|---|---|
| A.5.1 | Policies for information security | Ja | Grundlæggende styring kræves | Implementeret | POL-001 |
| A.5.9 | Inventory of information assets | Ja | Risiko: Uidentificerede aktiver | Implementeret | PROC-012 |
| A.7.3 | Securing offices and facilities | Ja | Fysiske kontorpladser findes | Implementeret | POL-015 |
| A.7.4 | Physical security monitoring | Nej | Håndteres af ejendomsejer, kontrakt findes | Ikke anvendelig | KON-023 |
| A.8.20 | Networks security | Ja | Kritisk infrastruktur | Delvist | PROJ-007 |
Gyldige og ugyldige begrundelser
• Risikoen eksisterer ikke (f.eks. ingen fysisk server = ingen fysisk serversikkerhed)
• Håndteres af anden kontrol
• Outsourcet til leverandør med kontrakt
• Virksomheden mangler relevant proces (f.eks. ingen systemudvikling)
• "Vi har ikke råd"
• "Vi har ikke tid"
• "Det er for kompliceret"
• "Ingen har spurgt om det"
• Ingen begrundelse overhovedet
Almindelige kontroller som ofte undtages
Kontroller som ofte (legitimt) undtages:
| Kontrol | Almindelig begrundelse |
|---|---|
| A.5.23 Information security for cloud services | Ingen cloudanvendelse |
| A.7.4 Physical security monitoring | Håndteres af ejendomsejer |
| A.8.25 Secure development life cycle | Ingen egen udvikling |
| A.8.26 Application security requirements | Ingen egen udvikling |
| A.8.28 Secure coding | Ingen egen udvikling |
| A.8.31 Separation of development environments | Ingen egen udvikling |
Vigtigt: Selvom I ikke udvikler internt, kan I anvende software som kræver sikker konfiguration. Overvej det nøje.
Revisors perspektiv
Hvad revisor fokuserer på:
- Fuldstændighed — Alle 93 kontroller skal være med
- Konsekvens — Begrundelser skal være logiske og konsekvente
- Kobling til risiko — Beslutninger skal kobles til risikovurderingen
- Implementering — Anvendelige kontroller skal faktisk findes
- Dokumentation — Henvisninger skal føre til rette dokumenter
- Aktualitet — SoA skal være opdateret
Almindelige afvigelser:
- Manglende kontroller
- Mangelfulde begrundelser
- Anvendelige kontroller som ikke er implementeret
- Gammel SoA som ikke afspejler nuværende situation
SoA og NIS2-krav
SoA kan udvides til at dække NIS2-krav som går udover ISO 27001:
| NIS2-krav | Relevante ISO 27001 kontroller | SoA-bemærkning |
|---|---|---|
| Hændelsesrapportering 24t | A.5.24-A.5.28 | Udvidet procedure for tidskrav |
| Leverandørkædens sikkerhed | A.5.19-A.5.22 | Forstærket due diligence |
| Forretningskontinuitet | A.5.29-A.5.30 | Testfrekvens iht. NIS2 |
| Ledelsens uddannelse | A.6.3 | Specifikt indhold for ledelse |
Vedligeholdelse af SoA
- Årlig gennemgang Gennemgå hele SoA mindst årligt. Stemmer kontrolstatus? Er virksomheden ændret? Findes der nye risici?
- Opdater ved ændringer Ny virksomhed, nye systemer, organisationsændringer — alle kan påvirke SoA. Opdater proaktivt.
- Kob til intern revision Intern revision skal verificere at SoA afspejler virkeligheden. Afvigelser fører til opdatering.
- Versionskontrol Hold styr på ændringer. Hvem ændrede hvad og hvorfor? Gem historik.
Tjekliste for SoA
Før certificeringsrevision:
- Alle 93 Annex A-kontroller opført
- Anvendelighed angivet for hver kontrol
- Begrundelse dokumenteret for hver beslutning
- Undtagelser har gyldige grunde
- Implementeringsstatus opdateret
- Referencer til politik/procedure findes
- Kobling til risikovurdering tydelig
- Godkendt af ledelsen
- Versionskontrol på plads
- Senest opdateret dato angivet
Sådan kan Securapilot hjælpe
Securapilot forenkler SoA-håndtering:
- Færdigbygget struktur — Alle 93 kontroller foruddefineret
- Begrundelsesmallar — Eksempler og vejledning
- Statussporing — Se implementeringsfremdrift
- Dokumentkobling — Link til politikker og procedurer
- Versionshistorik — Fuld sporbarhed over ændringer
- Revisionsrapporter — Eksporter til ekstern revision
Book en demo og se hvordan vi forenkler jeres SoA-arbejde.
Ofte stillede spørgsmål
Skal alle 93 kontroller være med i SoA?
Ja, alle 93 kontroller i Annex A skal være opført i SoA. For hver kontrol skal du angive om den er anvendelig eller ej, og begrunde beslutningen.
Kan jeg undtage kontroller?
Ja, men hver undtagelse skal begrundes. Gyldige grunde inkluderer at risikoen ikke eksisterer (f.eks. ingen mobile arbejdspladser) eller at den håndteres af anden kontrol. 'Vi har ikke råd' er ikke en gyldig begrundelse.
Hvor ofte skal SoA opdateres?
SoA skal være et levende dokument, der opdateres ved ændringer i virksomheden, risikobilledet eller kontrolimplementeringen. Det bør gennemgås mindst årligt.
Hvad fokuserer revisor på i SoA?
Revisor kontrollerer: 1) At alle kontroller er opført, 2) At begrundelser er rimelige, 3) At anvendelige kontroller faktisk er implementeret, 4) Kobling til risikovurderingen.
