Kort förklarat är en Statement of Applicability (SoA) din organisations egna innehållsförteckning för säkerhet. Det är det dokument där ni listar vilka säkerhetsåtgärder ni har valt att använda och förklarar varför de behövs – eller varför vissa har valts bort.
En välskriven SoA fungerar som en brygga mellan teknisk IT-säkerhet och företagets affärsrisker.
Vad är ett Statement of Applicability?
I praktiken är en SoA en förteckning över de 93 kontrollerna i ISO 27001:2022 Annex A. För varje kontroll ska ni dokumentera:
- Applicerbarhet: Är kontrollen relevant för er verksamhet? (Ja/Nej).
- Motivering: Varför har ni valt att inkludera eller exkludera kontrollen?
- Implementationsstatus: Är den införd, planerad eller delvis införd?
- Referens: Hänvisning till den policy, process eller det tekniska system som beskriver hur kontrollen efterlevs.
Varför är dessa fyra punkter så viktiga?
Denna struktur är inte bara en byråkratisk övning. Den fungerar som organisationens officiella säkerhetsdeklaration. Genom att svara på dessa punkter skapar ni:
- Revisionstrygghet: När revisorn frågar "Hur hanterar ni kryptering?", pekar ni direkt på rad 8.24 i er SoA. Referensen leder direkt till relevant dokumentation, och motiveringen förklarar varför nivån är rimlig för just er.
- Gap-analys i realtid: Genom att markera kontroller som "planerade" ser ledningen direkt var de största säkerhetshålen finns och var resurser behöver prioriteras.
- Tydlig ansvarsfördelning: När ni kopplar en referens till en kontroll blir det tydligt vem i organisationen som äger processen. Det förvandlar SoA från ett statiskt IT-dokument till ett aktivt verktyg för governance.
ISO 27001:2022 – Från 114 till 93 kontroller
Den senaste versionen av standarden (2022) har bantat ner antalet kontroller från 114 till 93 genom att slå samman överlappande krav. Kontrollerna delas nu in i fyra huvudkategorier för att göra dem mer lätthanterliga:
- Organisatoriska (37): Policyer, leverantörshantering och incidenthantering.
- Personsäkerhet (8): Utbildning och bakgrundskontroller.
- Fysiska (14): Skalskydd, utrustningssäkerhet och tillträde.
- Tekniska (34): Kryptering, loggning och nätverkssäkerhet.
Konkreta exempel på motiveringar
Revisorer ogillar svepande formuleringar som "Vi följer detta". Här är skillnaden mellan en svag och en stark motivering i en SoA:
| Kontroll (exempel) | Svag motivering | Stark motivering |
|---|---|---|
| 5.17 Autentiseringsinformation | "Vi har lösenord." | "System X använder SSO med MFA. Policy för hantering av hemligheter [Dok ID] tillämpas konsekvent." |
| 8.1 Användarenheter | "IT sköter detta." | "Alla enheter hanteras via MDM-systemet Y. Diskkryptering och antivirus tvingas via profiler." |
| 7.4 Fysiskt tillträde | "Dörren är låst." | "Exkluderad: Vi har ingen egen fysisk infrastruktur; allt driftas i AWS (se deras SOC2-rapport)." |
Så skapar du en effektiv SoA
1. Basera på riskbedömning
ISO 27001 kräver att urvalet av kontroller i er SoA baseras direkt på resultatet från din riskbedömning. Det innebär att ni först måste identifiera organisationens specifika hot och sårbarheter innan ni kan avgöra vilka säkerhetsåtgärder som faktiskt krävs.
Om ni exempelvis har identifierat en hög risk för dataläckage via externa enheter, blir kontroller kring kryptering (8.24) och hantering av lagringsmedia helt kritiska för er efterlevnad. Utan en tydlig koppling till era faktiska risker framstår er SoA mer som en godtycklig checklista än ett strategiskt säkerhetsverktyg.
2. Koppla till bevisen
En SoA som bara innehåller "Ja" eller "Nej" saknar trovärdighet vid en revision. Ni behöver referera direkt till de styrdokument, processbeskrivningar eller tekniska konfigurationer som faktiskt implementerar varje enskild kontroll.
Genom att inkludera tydliga referenser till era informationssäkerhetspolicyer eller specifika systeminställningar underlättar ni arbetet enormt för både interna och externa revisorer. Det visar att kontrollen inte bara existerar som ett teoretiskt koncept, utan att den är en integrerad del av verksamhetens vardag.
3. Håll det levande
Många organisationer gör misstaget att se sin SoA som en statisk engångsuppgift för att uppnå certifiering. Men i en föränderlig hotbild måste dokumentet kontinuerligt spegla organisationens nuvarande IT-miljö och de utmaningar ni möter.
Dokumentet bör därför utvärderas löpande, särskilt vid implementering av nya molntjänster, förändringar i leverantörskedjan eller när nya regulatoriska krav som NIS2 träder i kraft. Genom att göra SoA till en naturlig del av ert ordinarie säkerhetsarbete säkerställer ni att er skyddsnivå förblir relevant.
Vanliga frågor om SoA
Vilket format bör en SoA ha?
Det finns inga strikta krav på format från ISO-standarden, men det vanligaste för mindre bolag är ett strukturerat Excel-ark eller Google Sheets. Större organisationer väljer ofta att hantera sin SoA direkt i en GRC-plattform för att få automatisk versionshantering och koppling till riskregister och kontroller.
Huvudsaken är att formatet tillåter enkel filtrering och att det går att länka eller referera till bevis på ett tydligt sätt.
Vem ansvarar för att godkänna dokumentet?
Eftersom en SoA definierar organisationens säkerhetsnivå och acceptans av kvarvarande risker, bör den formellt godkännas av högsta ledningen eller en utsedd säkerhetsnämnd. Detta är ett krav i ISO 27001 och visar på ledningens engagemang för informationssäkerheten.
Är en SoA ett offentligt dokument?
Nej, en SoA innehåller ofta känslig information om organisationens tekniska kontroller och eventuella säkerhetsgap. Dokumentet klassas nästan alltid som konfidentiellt och delas endast med externa revisorer eller under strikta sekretessavtal med kunder som kräver bevis på efterlevnad.
Kan vi ha olika SoA för olika delar av verksamheten?
Ja, om er certifiering (scope) endast omfattar en specifik avdelning eller tjänst kan ni ha en SoA som är begränsad till just den delen. Det är dock viktigt att gränssnitten mot resten av organisationen dokumenteras tydligt så att inga säkerhetsrisker faller mellan stolarna.
Sammanfattning
En bra Statement of Applicability handlar inte om att bocka av så många rutor som möjligt. Det handlar om att visa att ni har gjort medvetna val kring er säkerhetsnivå baserat på era faktiska risker och er affärsnytta.
Genom att använda tydliga referenser och genomtänkta motiveringar förvandlas er SoA från ett kravdokument till ett kraftfullt verktyg för att styra och förbättra organisationens säkerhet över tid.
