SoA står för Statement of Applicability – på svenska tillämplighetsförklaring. Kort förklarat är det er organisations egen innehållsförteckning för säkerhet: dokumentet där ni listar vilka säkerhetsåtgärder (kontroller) ni har valt att använda och förklarar varför de behövs – eller varför vissa har valts bort.
Använd dokumentet för att visa kopplingen mellan era risker, tillämpliga krav och valda skyddsåtgärder. Revisorn ska kunna följa varför en kontroll behövs och om den är införd. SoA är en del av ledningssystemet för informationssäkerhet som ISO 27001 kräver.
Vad är ett Statement of Applicability?
En SoA innehåller de kontroller ni bedömt som nödvändiga, motiveringar till att de ingår, deras införandestatus och skäl till att kontroller i Annex A utelämnats. Annex A har 93 kontroller som ni ska jämföra ert urval mot. Egna kontroller eller kontroller från andra källor kan också behövas.
En praktisk struktur är:
- 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 relevant policy, process, ansvarig och bevis. Detta är ett användbart tillägg som underlättar uppföljning och revision.
Varför är dessa fyra punkter så viktiga?
Strukturen gör dokumentet användbart för både säkerhetsansvarig och revisor:
- 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.
- Överblick över kvarstående arbete: 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.
Se även revisionsvägledningen om SoA i ISO/IEC JTC 1/SC 27:s expertjournal, sidorna 11–17. Den förklarar varför Annex A är en referens för jämförelse och inte en lista där varje kontroll automatiskt är obligatorisk.
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.2 Fysiskt tillträde | "Dörren är låst." | "Tillämplig: Driftleverantören ansvarar för datacentrets tillträde. Vi granskar relevant revisionsunderlag och skyddar egna arbetsplatser enligt [Dok ID]." |
Så skapar du en effektiv SoA
1. Basera på riskbedömning
Utgå från er riskbedömning, riskbehandling samt tillämpliga lag-, avtals- och verksamhetskrav när ni väljer kontroller. 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 risken är hög att data läcker via externa enheter behöver ni åtgärder för kryptering (8.24) och hantering av lagringsmedia. Visa hur åtgärderna möter de risker ni har hittat. Då blir er SoA ett stöd för säkerhetsarbetet, i stället för en checklista utan tydligt syfte.
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.
Hänvisa till era regler för informationssäkerhet eller till de inställningar som används i systemen. Då kan både interna och externa revisorer lättare granska arbetet. Det visar hur ni använder kontrollen i vardagen.
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 föreskrifter enligt cybersäkerhetslagen börjar gälla. Genom att göra SoA till en naturlig del av ert ordinarie säkerhetsarbete säkerställer ni att er skyddsnivå förblir relevant. Kopplar ni dessutom varje gap till en åtgärd med ansvarig och deadline blir uppdateringarna en del av det löpande arbetet i stället för en årlig punktinsats. Risker, krav och åtgärder kan hållas samlade i ChainSecs GRC-stöd.
Vanliga frågor om SoA
Vad betyder SoA?
SoA står för Statement of Applicability, ett obligatoriskt dokument enligt ISO 27001. Det innehåller nödvändiga säkerhetskontroller, motiveringar till urvalet, om kontrollerna är införda och skäl till att kontroller i Annex A uteslutits. Bevisreferenser och ansvariga är praktiska tillägg.
Kan vi exkludera många kontroller för att göra det enklare?
Urvalet ska följa era risker och tillämpliga krav, inte en önskad procentsats. Motivera varje uteslutning ur Annex A och kontrollera att nödvändiga skydd inte saknas. Outsourcing tar inte automatiskt bort behovet av en kontroll; skyddet kan behöva utföras av en leverantör och följas upp av er.
Hur ofta ska SoA uppdateras?
Granska SoA vid planerade intervall och när risker, krav, omfattning eller införandestatus ändras. Samordna granskningen med riskbedömning och ledningens genomgång, men ange ett intervall som passar verksamheten i stället för att anta ett generellt årskrav.
Måste vi använda de nya 93 kontrollerna?
Vid certifiering enligt ISO 27001:2022 ska ni jämföra era nödvändiga kontroller med de 93 i Annex A. Det betyder inte att alla måste införas. Dokumentera relevanta uteslutningar och lägg till andra kontroller om risker eller krav gör dem nödvändiga.
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. När flera personer uppdaterar underlaget behöver ni versionshistorik, tydligt ansvar och kopplingar till risker och åtgärder. Välj ett verktyg som stödjer det arbetssättet.
Vem ansvarar för att godkänna dokumentet?
Utse dokumentägare och besluta om ert godkännandeflöde. ISO 27001 kräver riskägarnas godkännande av riskbehandlingsplanen och acceptans av kvarstående informationssäkerhetsrisker. Det är inte samma sak som ett uttryckligt krav på att styrelsen ska signera varje SoA-version.
Är en SoA ett offentligt dokument?
Nej, en SoA innehåller ofta känslig information om organisationens tekniska kontroller och eventuella säkerhetsgap. Bestäm klassning och delning efter innehållets känslighet. Kunder kan få ett avgränsat utdrag eller kontrollförteckning när ni bedömt att det är lämpligt; detaljer om säkerhetsgap kan kräva starkare skydd.
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 användbart verktyg för att styra och förbättra organisationens säkerhet över tid.
