Tillämpbarhetsförklaring i ISO 27001: så bygger du en SoA som håller

Tillämpbarhetsförklaringen, på engelska Statement of Applicability (SoA), är det dokument i ISO/IEC 27001 där organisationen redovisar vilka informationssäkerhetskontroller den behöver, varför de ingår, om de är genomförda och varför kontroller i Annex A har valts bort. Den är alltså ingen checklista att fylla i, utan slutsatsen av riskbedömningen och riskbehandlingen. I den här guiden går vi igenom vad standarden kräver, hur du motiverar dina val, hur SoA skiljer sig från övrig dokumentation och hur den används när certifieringsrevisorn kommer.

Kort sagt

• SoA ska enligt ISO/IEC 27001:2022 visa de nödvändiga kontrollerna, motiveringen för att de ingår, deras genomförandestatus och motiveringen för varje utesluten Annex A-kontroll.
• Standarden kräver ingen viss mall. Det avgörande är att det tydligt framgår vilka kontroller som valts och varför.
• Annex A är en referenslista, inte en färdig rekommendation. Urvalet ska bygga på er riskbedömning samt på lag- och avtalskrav.
• Vid certifiering anges vilken version av SoA som gäller, så dokumentet måste vara versionshanterat och hållas aktuellt.
• En SoA som lever i ett system, kopplad till risker och åtgärder, är betydligt lättare att försvara än ett fristående kalkylark.

Innehållsförteckning

• Vad är en tillämpbarhetsförklaring?
• Vad SoA måste innehålla enligt ISO 27001:2022
• Från riskbedömning till SoA: kedjan revisorn följer
• Så väljer du in och väljer bort Annex A-kontroller
• SoA, riskbedömning, riskbehandlingsplan och kontrolldokumentation
• SoA i certifieringsrevisionen
• När ska SoA uppdateras?
• Vanliga misstag i tillämpbarhetsförklaringen
• Vårt perspektiv
• Hantera SoA, risker och åtgärder i Trustview
• Vanliga frågor
• Källor

Vad är en tillämpbarhetsförklaring?

I svenskt språkbruk förekommer både tillämpbarhetsförklaring och tillämpningsförklaring, och i praktiken använder de flesta förkortningen SoA. Oavsett namn fyller dokumentet samma funktion: det samlar organisationens nödvändiga kontroller på ett ställe.

Enligt ISO:s tekniska kommittés vägledning om SoA dokumenterar SoA vilka kontroller som behövs, varför de ingår, om de är genomförda och varför kontroller i Annex A har uteslutits. Vägledningen tas fram av ISO/IEC JTC 1/SC 27, samma kommitté som ansvarar för 27000-serien, och är skriven för revisorer. Det gör den till en bra måttstock för hur din egen SoA kommer att granskas.

SoA har tre användare:

1. Ledningen, som får en samlad bild av vilket skydd organisationen har valt och vilka risker som medvetet hanteras på annat sätt.
2. Säkerhetsfunktionen och CISO, som använder dokumentet som karta över ansvar, status och kvarvarande arbete.
3. Revisorn, som utgår från SoA för att planera granskningen och kontrollera att valen hänger ihop med riskhanteringen.

Den danska myndighetsportalen Sikker Digital lyfter fram ytterligare en poäng: arbetet med SoA-dokumentet säkerställer en systematisk genomgång av samtliga valbara säkerhetsåtgärder i Annex A. Du tvingas alltså ta ställning till varje kontroll, inte bara till dem du redan har.

Vad SoA måste innehålla enligt ISO 27001:2022

Kravet finns i klausul 6.1.3 d) i ISO/IEC 27001:2022. Enligt ISO-kommitténs revisionsvägledning ska dokumentet innehålla fyra delar:

1. De nödvändiga kontrollerna, oavsett om de kommer från Annex A, från ett annat ramverk eller är egna kontroller.
2. Motiveringen för att kontrollerna ingår, alltså vilken risk, vilket lagkrav eller vilket avtalsåtagande som kontrollen svarar mot.
3. Genomförandestatus, det vill säga om kontrollen är genomförd eller inte.
4. Motiveringen för att utesluta Annex A-kontroller, för varje kontroll som organisationen bedömer inte behövs.

Standarden föreskriver ingen viss struktur. Det som krävs är att det tydligt framgår vilka kontroller som valts och varför. Många organisationer använder ändå en tabell med ungefär följande kolumner, eftersom den gör kraven lätta att kontrollera:

De två sista kolumnerna är inte krav i standarden, men de gör det betydligt enklare att visa att kontrollen faktiskt fungerar. Annex A i 2022-versionen omfattar 93 kontroller, och hur de ska tolkas går vi igenom i vår guide om Annex A i ISO 27001.

Från riskbedömning till SoA: kedjan revisorn följer

SoA är inte startpunkten. Den är resultatet av ett arbete som börjar i organisationens kontext och riskbedömning.

Enligt vägledningen från ISO/IEC JTC 1/SC 27 ska organisationen bestämma vilka kontroller som behövs för att minska exponeringen för informationssäkerhetsrisk till en acceptabel nivå. Motiveringen för valen ska återspegla organisationens kontext och dess sätt att hantera risk. Det innebär att en revisor förväntar sig kunna följa en röd tråd:

1. Kontext och omfattning: vilken verksamhet, vilken information och vilka intressenter ledningssystemet omfattar.
2. Riskbedömning: vilka risker som identifierats och hur de värderats mot organisationens riskkriterier.
3. Riskbehandling: vilket behandlingsalternativ som valts för varje risk, till exempel att reducera, undvika, dela eller acceptera.
4. Kontrollval: vilka kontroller som krävs för de risker som ska reduceras.
5. Jämförelse mot Annex A: en kontroll att inga nödvändiga kontroller förbisetts.
6. SoA: den samlade redovisningen av val, motiveringar och status.

Om kedjan bryts, till exempel när en kontroll finns i SoA men inte kan kopplas till någon risk eller något krav, uppstår frågor vid revisionen. Den som vill fördjupa sig i riskmetodiken kan läsa vår praktiska guide om ISO 27005-riskanalys, som beskriver hur risker identifieras och värderas innan kontroller väljs. Sambandet mellan SoA och riskbehandlingen syns också i branscher med hårt reglerad data, där säkerhet och regelefterlevnad i vården bygger på samma princip: skyddsåtgärderna ska gå att härleda till identifierade risker och krav.

Så väljer du in och väljer bort Annex A-kontroller

En vanlig missuppfattning är att alla 93 kontroller ska vara genomförda. Så är det inte. ISO-kommitténs vägledning beskriver Annex A som en referensuppsättning kontroller som varken är komplett eller rekommenderad. Det är organisationen som avgör vilka kontroller som behövs, utifrån riskbedömningen eller utifrån lag- och avtalskrav.

Arbeta i den här ordningen:

1. Utgå från riskbehandlingen. Lista de kontroller som riskbehandlingen pekar ut, innan du öppnar Annex A.
2. Lägg till krav utifrån. Gå igenom lagkrav, myndighetsföreskrifter och kundavtal. En kontroll kan vara nödvändig för att ett avtal kräver den, även om riskbedömningen inte pekar ut den.
3. Jämför mot Annex A. Gå igenom varje kontroll och notera om den redan täcks, behöver läggas till eller inte är tillämplig.
4. Skriv motiveringen direkt. Dokumentera skälet när beslutet fattas, inte veckan före revisionen.
5. Låt ägaren bekräfta. Den som ansvarar för kontrollen ska stå bakom status och motivering.

Steg två blir särskilt viktigt när verksamheten använder externa leverantörer. Om delar av utvecklingen eller driften är utlagd behöver kontrollerna för leverantörsrelationer spegla både avtalen och de risker som följer med, något som beskrivs närmare i genomgången av krav vid outsourcing av datasäkerhet.

Exempel: starka och svaga motiveringar

Skillnaden mellan en motivering som håller och en som inte gör det är ofta konkretion.

Utesluten kontroll, svag motivering: “A.7.6 Arbete inom säkra områden: ej relevant.”

Utesluten kontroll, stark motivering: “A.7.6 Arbete inom säkra områden: ej tillämplig. Organisationen har inga egna serverrum eller särskilt skyddade lokaler inom omfattningen. All drift sker hos molnleverantör, som hanteras genom A.5.19 till A.5.23. Omprövas vid ändrade lokaler.”

Vald kontroll, svag motivering: “A.8.13 Säkerhetskopiering: standardkrav.”

Vald kontroll, stark motivering: “A.8.13 Säkerhetskopiering: tillämplig. Reducerar risk R-07, förlust av kunddata vid ransomware. Krav i kundavtal om återställning inom avtalad tid.”

Den starka motiveringen pekar på en risk, ett krav eller ett faktiskt förhållande. Den visar också när beslutet ska omprövas.

SoA, riskbedömning, riskbehandlingsplan och kontrolldokumentation

De fyra dokumenten blandas ofta ihop, men de svarar på olika frågor. Så här skiljer de sig åt:

Enkelt uttryckt beskriver riskbedömningen problemet, riskbehandlingsplanen arbetet, SoA beslutet och kontrolldokumentationen beviset. Om dokumenten hålls separat utan kopplingar blir det snabbt motsägelser: en åtgärd stängs i planen men SoA visar fortfarande “planerad”, eller en ny risk läggs till utan att någon kontroll uppdateras. Därför är det klokt att låta dem dela samma underlag. Vill du se hur samma kontroller kan återanvändas mot flera regelverk beskriver vi det i guiden om att mappa kontroller mot GDPR, NIS2 och ISO 27001.

SoA i certifieringsrevisionen

Vid certifieringsrevisionen är SoA ett av de första dokument revisorn begär. Enligt ISO/IEC JTC 1/SC 27:s revisionsvägledning ska versionen av SoA anges i certifieringsdokumenten, och SoA kan användas för att visa överensstämmelse med klausul 6.1.3 d).

I praktiken innebär det att:

• Versionshantering är ett måste. Du behöver kunna visa vilken version som gällde vid revisionen och vad som ändrats sedan dess.
• Revisorn stickprovar. Räkna med att några kontroller väljs ut och följs bakåt till risk och framåt till bevis.
• Uteslutningar granskas särskilt. En utesluten kontroll med tunn motivering är en vanlig källa till avvikelser.
• Status måste stämma. Om SoA anger “genomförd” ska det finnas något att visa upp.

Innan certifieringen är det värt att göra en gap-analys där SoA jämförs med faktiskt läge. Vi beskriver arbetssättet i ISO 27001 gap-analys. Om din verksamhet även omfattas av NIS2 kan samma SoA bli ett viktigt underlag, vilket vi går igenom i guiden om att mappa ISO 27001 mot NIS2-kraven.

När ska SoA uppdateras?

SoA är ett levande dokument. Eftersom den ska spegla riskbehandlingen behöver den uppdateras när underlaget för riskbehandlingen förändras. Typiska tillfällen är:

• Efter en ny eller förnyad riskbedömning, både den planerade och den som görs vid väsentliga förändringar.
• När omfattningen ändras, till exempel vid nya verksamhetsområden, förvärv, nya lokaler eller nya system.
• När lag- eller avtalskrav förändras, exempelvis nya kundkrav eller ny reglering som påverkar verksamheten.
• När en kontroll byter status, från planerad till genomförd eller tvärtom.
• Efter incidenter, när utredningen visar att en kontroll saknas eller inte fungerar.
• Inför ledningens genomgång och internrevision, så att ledningen fattar beslut på aktuellt underlag.

En bra tumregel är att varje ändring i SoA ska kunna kopplas till en händelse: en ny risk, ett nytt krav eller en ändrad status. Då blir versionshistoriken i sig ett bevis på att ledningssystemet fungerar. Mer om hur SoA passar in i helheten finns i vår guide om ledningssystem för informationssäkerhet.

Vanliga misstag i tillämpbarhetsförklaringen

De brister vi oftast ser i SoA-arbete handlar sällan om okunskap om standarden. De handlar om struktur.

• SoA skrivs före riskbedömningen. Då blir urvalet en gissning och motiveringarna generiska.
• Alla kontroller markeras som tillämpliga. Det ser tryggt ut men skapar arbete och åtaganden som organisationen inte kan visa att den lever upp till.
• Motiveringar utan koppling. “Best practice” eller “krav i standarden” är ingen motivering.
• Egna kontroller saknas. Kontroller som följer av lag eller avtal men inte finns i Annex A ska också redovisas.
• Statusen är inaktuell. Ett dokument som inte uppdaterats sedan förra revisionen tappar trovärdighet.
• Ingen ägare. När ingen ansvarar för en kontroll ansvarar i praktiken ingen för att den fungerar.

Vårt perspektiv

Vi ser tillämpbarhetsförklaringen som det dokument där ett ledningssystem för informationssäkerhet antingen hänger ihop eller faller isär. I många organisationer lever riskregistret i ett kalkylark, åtgärderna i ett projektverktyg och SoA i ett Word-dokument. Varje fil kan vara korrekt för sig, men de glider isär så fort verksamheten förändras.

Därför har vi byggt Trustview så att risker, kontroller, åtgärder och ansvar hanteras på samma ställe. När en risk bedöms om eller en åtgärd följs upp ska det synas direkt i kontrollens status, och när en revisor frågar varför en kontroll valts ska svaret finnas ett klick bort. Vår plattform är byggd av jurister med erfarenhet av svensk och europeisk lagstiftning, och vi vet att motiveringarna i en SoA ofta är juridiska lika mycket som tekniska: avtal, lagkrav och ansvarsfördelning.

Vårt råd är enkelt. Behandla inte SoA som en leverans inför revisionen, utan som en vy över det arbete ni redan gör. Då blir den både lättare att underhålla och lättare att försvara.

Jesper

Hantera SoA, risker och åtgärder i Trustview

I Trustview arbetar du med ISO 27001, NIS2, GDPR och AI-förordningen i samma plattform. Du kan genomföra risk- och konsekvensbedömningar, följa upp åtgärder, delegera ansvar, bedöma leverantörer och bygga egna ramverk, med realtidsöversikt över compliance-status och automatiserade rapporter. Färdiga mallar och guider gör det enklare att komma igång.

Trustview kostar från 2 500 kr per månad. Se priser och upplägg för Trustview eller läs mer om vårt ISO 27001-verktyg för informationssäkerhet. Behöver du hjälp med motiveringar som rör avtal och lagkrav kan du även ta stöd av vår juridiska rådgivning.

Vanliga frågor

Är tillämpbarhetsförklaringen obligatorisk för ISO 27001-certifiering?

Ja. Kravet följer av klausul 6.1.3 d) i ISO/IEC 27001:2022, och versionen av SoA anges i certifieringsdokumenten. Utan en SoA går det inte att visa vilka kontroller som omfattas av certifieringen.

Måste alla 93 kontroller i Annex A genomföras?

Nej. Annex A är en referenslista som du ska jämföra ditt urval mot, inte en lista som ska genomföras i sin helhet. Kontroller som inte behövs kan uteslutas, men varje uteslutning ska motiveras.

Finns det en officiell mall för SoA?

Standarden kräver ingen viss struktur. Det som krävs är att de nödvändiga kontrollerna, motiveringarna, genomförandestatus och skälen för uteslutningar framgår tydligt. En tabell med en rad per kontroll är det vanligaste formatet.

Kan SoA innehålla kontroller som inte finns i Annex A?

Ja. Om riskbedömningen, ett lagkrav eller ett kundavtal kräver en kontroll som saknas i Annex A ska den finnas med i SoA tillsammans med sin motivering. Det visar att urvalet bygger på verksamhetens faktiska behov.

Hur ofta ska SoA ses över?

SoA bör ses över varje gång riskbedömningen uppdateras, när omfattningen eller kraven förändras och när en kontroll byter status. Många organisationer gör också en fast genomgång inför ledningens genomgång och internrevisionen.

Källor

ISO/IEC JTC 1/SC 27/WG 1 N 3298: Auditing Practices Note, Statement of Applicability

Sikker Digital: SoA-dokumentet

ClaroClaim: Security & HIPAA Compliance

Get Amazing Devs: Data Security Outsourcing

Rekommendationer

• Så mappar du ISO 27001 mot NIS2-kraven
• Annex A i ISO 27001: så tolkar du 93 kontroller rätt
• ISO 27001 gap-analys: så förbereder du certifiering rätt
• Ledningssystem för informationssäkerhet: guide för svenska organisationer