Hva er Statement of Applicability?
Statement of Applicability (SoA) — på norsk ofte kalt anvendbarhetserklæring — er et sentralt dokument i ISO 27001. Det lister alle kontroller i Annex A og angir for hver kontroll:
- Om den er anvendelig eller ikke
- Begrunnelse for beslutningen
- Implementeringsstatus
Innsikten: SoA er ikke en sjekkliste å krysse av. Det er et strategisk dokument som viser at organisasjonen har gjort bevisste, risikobaserte valg om sitt sikkerhetsarbeid.
Hvorfor er SoA viktig?
SoA fyller flere funksjoner:
- Sertifiseringskrav — Obligatorisk i henhold til ISO 27001 klausul 6.1.3
- Kommunikasjon — Viser interessenter hvilke kontroller dere har implementert
- Referanse — Utgangspunkt for internrevisjon og kontrolloppfølging
- Sporbarhet — Kobler risikovurdering til konkrete tiltak
- Transparens — Dokumenterer bevisste valg og prioriteringer
Uten SoA:
- Ingen ISO 27001-sertifisering mulig
- Vanskelig å vise systematisk sikkerhetsarbeid
- Risiko for vilkårlige kontrollvalg
ISO 27001:2022 Annex A struktur
De 93 kontrollene er organisert i fire temaer:
| Tema | Antall kontroller | Fokus |
|---|---|---|
| A.5 Organisatoriske | 37 | Policyer, roller, leverandører |
| A.6 Personrelaterte | 8 | Ansettelse, opplæring, avslutning |
| A.7 Fysiske | 14 | Lokaler, utstyr, miljø |
| A.8 Tekniske | 34 | Systemer, nettverk, kryptering |
SoA-prosessen steg for steg
- Gjennomfør risikovurdering først SoA baseres på deres risikovurdering. Identifiser hvilke risikoer som finnes, hvilke aktiva som trenger beskyttelse og hvilke trusler som er relevante. Uten risikovurdering blir SoA vilkårlig.
- List alle Annex A-kontroller Lag en tabell med alle 93 kontroller. Inkluder kontrollnummer, navn og beskrivelse. Dette blir grunnlaget for deres SoA.
- Vurder anvendelighet For hver kontroll: Er den relevant for deres virksomhet og risikobilde? Svar ja eller nei. Tenk på at "ikke anvendelig" krever sterk begrunnelse.
- Begrunne hver beslutning Uavhengig av om kontrollen er anvendelig eller ikke — dokumenter hvorfor. Koble til risikovurderingen. "Implementerer for å håndtere risiko X" eller "Ikke anvendelig da vi ikke har Y".
- Dokumenter implementeringsstatus For anvendelige kontroller: Er den implementert? Delvis? Planlagt? Angi status og eventuell frist.
- Lenke til dokumentasjon Koble hver kontroll til relevant policy, prosedyre eller teknisk implementasjon. Dette letter revisjon.
- Gjennomgå og godkjenn SoA skal godkjennes av ledelsen. Det viser eierskap og ansvar for sikkerhetsvalgene.
Eksempel på SoA-struktur
| Kontroll | Beskrivelse | Anvendelig | Begrunnelse | Status | Dokumentasjon |
|---|---|---|---|---|---|
| A.5.1 | Policies for information security | Ja | Grunnleggende styring kreves | Implementert | POL-001 |
| A.5.9 | Inventory of information assets | Ja | Risiko: Uidentifiserte aktiva | Implementert | PROC-012 |
| A.7.3 | Securing offices and facilities | Ja | Fysiske kontorplasser finnes | Implementert | POL-015 |
| A.7.4 | Physical security monitoring | Nei | Håndteres av eiendomseier, avtale finnes | Ikke anvendelig | AVT-023 |
| A.8.20 | Networks security | Ja | Kritisk infrastruktur | Delvis | PROJ-007 |
Gyldige og ugyldige begrunnelser
• Risikoen eksisterer ikke (f.eks. ingen fysisk server = ingen fysisk serversikkerhet)
• Håndteres av annen kontroll
• Outsourcet til leverandør med avtale
• Virksomheten mangler relevant prosess (f.eks. ingen systemutvikling)
• "Vi har ikke råd"
• "Vi har ikke tid"
• "Det er for komplisert"
• "Ingen har spurt etter det"
• Ingen begrunnelse i det hele tatt
Vanlige kontroller som ofte unntas
Kontroller som ofte (legitimt) unntas:
| Kontroll | Vanlig begrunnelse |
|---|---|
| A.5.23 Information security for cloud services | Ingen skybruk |
| A.7.4 Physical security monitoring | Håndteres av eiendomseier |
| A.8.25 Secure development life cycle | Ingen egen utvikling |
| A.8.26 Application security requirements | Ingen egen utvikling |
| A.8.28 Secure coding | Ingen egen utvikling |
| A.8.31 Separation of development environments | Ingen egen utvikling |
Viktig: Selv om dere ikke utvikler internt, kan dere bruke programvare som krever sikker konfigurering. Tenk grundig igjennom.
Revisorens perspektiv
Hva revisoren ser på:
- Fullstendighet — Alle 93 kontroller må være med
- Konsistens — Begrunnelser må være logiske og konsekvente
- Kobling til risiko — Beslutninger skal kobles til risikovurderingen
- Implementasjon — Anvendelige kontroller skal faktisk finnes
- Dokumentasjon — Henvisninger skal lede til riktig dokument
- Aktualitet — SoA skal være oppdatert
Vanlige avvik:
- Manglende kontroller
- Mangelfulle begrunnelser
- Anvendelige kontroller som ikke er implementert
- Gammel SoA som ikke reflekterer nåsituasjonen
SoA og NIS2-krav
SoA kan utvides for å dekke NIS2-krav som går utover ISO 27001. Norge har implementert NIS2 gjennom lov om digital sikkerhet (digitalsikkerhetsloven) med frist 17. oktober 2024, og NSM er tilsynsmyndighet:
| NIS2-krav | Relevante ISO 27001 kontroller | SoA-notering |
|---|---|---|
| Hendelsesrapportering 24t | A.5.24-A.5.28 | Utvidet prosedyre for tidskrav |
| Leverandørkjedens sikkerhet | A.5.19-A.5.22 | Forsterket due diligence |
| Virksomhetskontinuitet | A.5.29-A.5.30 | Testfrekvens i henhold til NIS2 |
| Ledelsens opplæring | A.6.3 | Spesifikt innhold for ledelse |
Vedlikehold av SoA
- Årlig gjennomgang Gå gjennom hele SoA minst årlig. Stemmer kontrollstatusen? Har virksomheten endret seg? Finnes det nye risikoer?
- Oppdater ved endringer Ny virksomhet, nye systemer, organisasjonsendringer — alle kan påvirke SoA. Oppdater proaktivt.
- Koble til internrevisjon Internrevisjon skal verifisere at SoA reflekterer virkeligheten. Avvik fører til oppdatering.
- Versjonskontroll Hold oversikt over endringer. Hvem endret hva og hvorfor? Lagre historikk.
Sjekkliste for SoA
Før sertifiseringsrevisjon:
- Alle 93 Annex A-kontroller listet
- Anvendelighet angitt for hver kontroll
- Begrunnelse dokumentert for hver beslutning
- Unntak har gyldige årsaker
- Implementeringsstatus oppdatert
- Henvisninger til policy/prosedyre finnes
- Kobling til risikovurdering tydelig
- Godkjent av ledelsen
- Versjonskontroll på plass
- Sist oppdatert dato angitt
Slik kan Securapilot hjelpe
Securapilot forenkler SoA-håndtering:
- Ferdigbygd struktur — Alle 93 kontroller forhåndsdefinert
- Begrunnelsesmaler — Eksempler og veiledning
- Statussporing — Se implementeringsframgang
- Dokumentkobling — Lenk til policyer og prosedyrer
- Versjonshistorikk — Full sporbarhet over endringer
- Revisjonsrapporter — Eksporter for ekstern revisjon
Bestill en demo og se hvordan vi forenkler deres SoA-arbeid.
Ofte stilte spørsmål
Må alle 93 kontroller finnes i SoA?
Ja, alle 93 kontroller i Annex A må listes i SoA. For hver kontroll må du angi om den er anvendelig eller ikke, og begrunne beslutningen.
Kan jeg unnta kontroller?
Ja, men hvert unntak må begrunnes. Gyldige årsaker inkluderer at risikoen ikke finnes (f.eks. ingen mobil arbeidsplass) eller at den håndteres av annen kontroll. 'Vi har ikke råd' er ikke en gyldig begrunnelse.
Hvor ofte skal SoA oppdateres?
SoA skal være et levende dokument som oppdateres ved endringer i virksomheten, risikobildet eller kontrollimplementasjonen. Minst årlig bør den gjennomgås.
Hva ser revisoren på i SoA?
Revisoren kontrollerer: 1) At alle kontroller er listet, 2) At begrunnelser er rimelige, 3) At anvendelige kontroller faktisk er implementert, 4) Kobling til risikovurderingen.
