Vad är Statement of Applicability?
Statement of Applicability (SoA), på svenska ofta kallat tillämpbarhetsförklaring, är ett centralt dokument i ISO 27001. Det listar alla kontroller i Annex A och anger för varje kontroll:
- Om den är tillämplig eller inte
- Motivering för beslutet
- Implementeringsstatus
Insikten: SoA är inte en checklista att bocka av. Det är ett strategiskt dokument som visar att organisationen gjort medvetna, riskbaserade val om sitt säkerhetsarbete.
Varför är SoA viktigt?
SoA fyller flera funktioner:
- Certifieringskrav: Obligatoriskt enligt ISO 27001 klausul 6.1.3
- Kommunikation: Visar intressenter vilka kontroller ni implementerat
- Referens: Utgångspunkt för internrevision och kontrolluppföljning
- Spårbarhet: Kopplar riskbedömning till konkreta åtgärder
- Transparens: Dokumenterar medvetna val och prioriteringar
Utan SoA:
- Ingen ISO 27001-certifiering möjlig
- Svårt att visa systematiskt säkerhetsarbete
- Risk för godtyckliga kontrollval
ISO 27001:2022 Annex A struktur
De 93 kontrollerna är organiserade i fyra teman:
| Tema | Antal kontroller | Fokus |
|---|---|---|
| A.5 Organisatoriska | 37 | Policyer, roller, leverantörer |
| A.6 Personrelaterade | 8 | Anställning, utbildning, avslut |
| A.7 Fysiska | 14 | Lokaler, utrustning, miljö |
| A.8 Tekniska | 34 | System, nätverk, kryptering |
SoA-processen steg för steg
- Genomför riskbedömning först SoA baseras på er riskbedömning. Identifiera vilka risker som finns, vilka tillgångar som behöver skyddas och vilka hot som är relevanta. Utan riskbedömning blir SoA godtycklig.
- Lista alla Annex A-kontroller Skapa en tabell med alla 93 kontroller. Inkludera kontrollnummer, namn och beskrivning. Detta blir grunden för er SoA.
- Bedöm tillämpbarhet För varje kontroll: Är den relevant för er verksamhet och riskbild? Svara ja eller nej. Tänk på att "inte tillämplig" kräver stark motivering.
- Motivera varje beslut Oavsett om kontrollen är tillämplig eller inte, dokumentera varför. Koppla till riskbedömningen. "Implementerar för att hantera risk X" eller "Ej tillämplig då vi inte har Y".
- Dokumentera implementeringsstatus För tillämpliga kontroller: Är den implementerad? Delvis? Planerad? Ange status och eventuell deadline.
- Länka till dokumentation Koppla varje kontroll till relevant policy, procedur eller teknisk implementation. Detta underlättar revision.
- Granska och godkänn SoA ska godkännas av ledningen. Det visar ägarskap och ansvar för säkerhetsvalen.
Exempel på SoA-struktur
| Kontroll | Beskrivning | Tillämplig | Motivering | Status | Dokumentation |
|---|---|---|---|---|---|
| A.5.1 | Policies for information security | Ja | Grundläggande styrning krävs | Implementerad | POL-001 |
| A.5.9 | Inventory of information assets | Ja | Risk: Oidentifierade tillgångar | Implementerad | PROC-012 |
| A.7.3 | Securing offices and facilities | Ja | Fysiska kontorsplatser finns | Implementerad | POL-015 |
| A.7.4 | Physical security monitoring | Nej | Hanteras av fastighetsägare, avtal finns | Ej tillämplig | AVT-023 |
| A.8.20 | Networks security | Ja | Kritisk infrastruktur | Delvis | PROJ-007 |
Giltiga och ogiltiga motiveringar
• Risken existerar inte (t.ex. ingen fysisk server = ingen fysisk serversäkerhet)
• Hanteras av annan kontroll
• Outsourcad till leverantör med avtal
• Verksamheten saknar relevant process (t.ex. ingen systemutveckling)
• "Vi har inte råd"
• "Vi har inte tid"
• "Det är för komplicerat"
• "Ingen har frågat efter det"
• Ingen motivering alls
Vanliga kontroller som ofta undantas
Kontroller som ofta (legitimt) undantas:
| Kontroll | Vanlig motivering |
|---|---|
| A.5.23 Information security for cloud services | Ingen molnanvändning |
| A.7.4 Physical security monitoring | Hanteras av fastighetsägare |
| A.8.25 Secure development life cycle | Ingen egen utveckling |
| A.8.26 Application security requirements | Ingen egen utveckling |
| A.8.28 Secure coding | Ingen egen utveckling |
| A.8.31 Separation of development environments | Ingen egen utveckling |
Viktigt: Även om ni inte utvecklar internt, kan ni använda mjukvara som kräver säker konfiguration. Tänk igenom noggrant.
Revisorns perspektiv
Vad revisorn tittar på:
- Fullständighet: Alla 93 kontroller måste vara med
- Konsekvens: Motiveringar måste vara logiska och konsekventa
- Koppling till risk: Beslut ska kopplas till riskbedömningen
- Implementation: Tillämpliga kontroller ska faktiskt finnas
- Dokumentation: Hänvisningar ska leda till rätt dokument
- Aktualitet: SoA ska vara uppdaterad
Vanliga avvikelser:
- Saknade kontroller
- Bristfälliga motiveringar
- Tillämpliga kontroller som inte är implementerade
- Gammal SoA som inte speglar nuläget
SoA och NIS2-krav
SoA kan utökas för att täcka NIS2-krav som går utöver ISO 27001:
| NIS2-krav | Relevanta ISO 27001 kontroller | SoA-notering |
|---|---|---|
| Incidentrapportering 24h | A.5.24-A.5.28 | Utökad procedur för tidskrav |
| Leverantörskedjans säkerhet | A.5.19-A.5.22 | Förstärkt due diligence |
| Affärskontinuitet | A.5.29-A.5.30 | Testfrekvens enligt NIS2 |
| Ledningens utbildning | A.6.3 | Specifikt innehåll för ledning |
Underhåll av SoA
- Årlig genomgång Gå igenom hela SoA minst årligen. Stämmer kontrollstatusen? Har verksamheten förändrats? Finns nya risker?
- Uppdatera vid förändringar Ny verksamhet, nya system, organisationsförändringar, alla kan påverka SoA. Uppdatera proaktivt.
- Koppla till internrevision Internrevision ska verifiera att SoA speglar verkligheten. Avvikelser leder till uppdatering.
- Versionskontroll Håll koll på ändringar. Vem ändrade vad och varför? Spara historik.
Checklista för SoA
Före certifieringsrevision:
- Alla 93 Annex A-kontroller listade
- Tillämpbarhet angiven för varje kontroll
- Motivering dokumenterad för varje beslut
- Undantag har giltiga skäl
- Implementeringsstatus uppdaterad
- Hänvisningar till policy/procedur finns
- Koppling till riskbedömning tydlig
- Godkänd av ledningen
- Versionskontroll på plats
- Senast uppdaterad datum angivet
Så kan Securapilot hjälpa
Securapilot förenklar SoA-hantering:
- Förbyggd struktur: Alla 93 kontroller fördefinierade
- Motiveringsmallar: Exempel och vägledning
- Statusspårning: Se implementeringsprogress
- Dokumentkoppling: Länka till policyer och procedurer
- Versionshistorik: Full spårbarhet över ändringar
- Revisionsrapporter: Exportera för extern revision
Boka en demo och se hur vi förenklar ert SoA-arbete.
Vanliga frågor
Måste alla 93 kontroller finnas i SoA?
Ja, alla 93 kontroller i Annex A måste listas i SoA. För varje kontroll måste du ange om den är tillämplig eller inte, och motivera beslutet.
Kan jag undanta kontroller?
Ja, men varje undantag måste motiveras. Giltiga skäl inkluderar att risken inte finns (t.ex. ingen mobilarbetsplats) eller att den hanteras av annan kontroll. 'Vi har inte råd' är inte en giltig motivering.
Hur ofta ska SoA uppdateras?
SoA ska vara ett levande dokument som uppdateras vid förändringar i verksamheten, riskbilden eller kontrollimplementationen. Minst årligen bör den granskas.
Vad tittar revisorn på i SoA?
Revisorn kontrollerar: 1) Att alla kontroller är listade, 2) Att motiveringar är rimliga, 3) Att tillämpliga kontroller faktiskt är implementerade, 4) Koppling till riskbedömningen.
