Annex A i ISO/IEC 27001:2022 listar 93 kontroller fördelade på fyra teman: organisatoriska, personrelaterade, fysiska och tekniska. Varje organisation som vill certifiera sig måste bedöma samtliga 93 mot sin egen riskbild och dokumentera beslutet i en Statement of Applicability, förkortat SoA. Det är kärnkravet, och det är här de flesta implementeringar antingen lyckas eller fastnar.
Standarden ställer inget krav på att alla kontroller ska implementeras. Den ställer krav på att alla ska bedömas, med en motivering som håller för granskning.
- Fyra teman: organisatoriskt (A.5), personer (A.6), fysiskt (A.7), tekniskt (A.8)
- Totalt antal kontroller: 93, en minskning från 114 i 2013 års version
- Huvudåtgärd: bedöm tillämplighet för varje kontroll och dokumentera i SoA enligt klausul 6.1.3d
Proffstips: Räkna inte kontroller för sakens skull. Bedöm dem mot faktiska risker i din verksamhet, annars blir SoA ett pappersarbete utan verkligt värde.
Enligt Annex A i ISO/IEC 27001:2022 är kontrollerna organiserade just i dessa fyra teman, medan ISO/IEC 27002 fungerar som den praktiska tolkningsguiden för hur varje kontroll kan implementeras i verkligheten.
Viktiga insikter
Annex A-arbetet lyckas när varje kontroll kopplas till en identifierad risk och dokumenteras i SoA med en motivering som håller för granskning.
| Punkt | Detaljer |
|---|---|
| 93 kontroller, fyra teman | Bedöm samtliga kontroller i organisatoriskt, personer, fysiskt och tekniskt tema mot er riskbild. |
| SoA kräver motivering | Varje rad ska ange tillämplighet, motivering, status och referens till bevis, aldrig ett ensamt “N/A”. |
| Börja med governance | Policyer, roller och ansvar lägger grunden för att övriga kontroller ska bli meningsfulla. |
| Planera för 2022-nyheterna | DLP, datamaskning och secure coding kräver ofta tekniska investeringar i en andra implementeringsfas. |
| Verifiera löpande | Granska kontroller i roterande cykler och komplettera med minst en årlig ledningsgenomgång. |
Innehållsförteckning
- Vad ändrades i Annex A mellan 2013 och 2022?
- Organisatoriska kontroller: styrning, ansvar och leverantörer
- Personrelaterade kontroller: från screening till incidentrapportering
- Fysiska kontroller: vad revisorn brukar fråga efter
- Tekniska kontroller: autentisering, kryptering och de nya 2022-kraven
- Hur väljer du vilka Annex A-kontroller som är tillämpliga?
- Prioriteringsordning: snabbvinster först, 2022-nyheter i fas två
- Effektivitet och uppföljning: hur ofta ska kontrollerna granskas?
- Så stödjer ett compliance-verktyg arbetet med Annex A
- Kom igång med er Statement of Applicability
- Varför kontrollräkning är fel utgångspunkt
- Källor
Vad ändrades i Annex A mellan 2013 och 2022?
Antalet kontroller minskade från 114 till 93 när ISO konsoliderade flera överlappande poster till bredare, tydligare kategorier. Strukturen gick samtidigt från fjorton kapitel till fyra tydliga teman, vilket gör Annex A betydligt lättare att navigera för den som bygger sitt ledningssystem från grunden.
Förändringen var mer än kosmetisk. ISO 27001:2022 konsoliderade kontroller och lade till nya områden som speglar hur hotbilden såg ut vid revideringen, inte 2013.
De elva nya kontrollerna omfattar bland annat:
- Hotinformation (threat intelligence) för att proaktivt identifiera risker
- Informationssäkerhet vid molntjänster (cloud security)
- Beredskap för IKT vid avbrott (ICT readiness for business continuity)
- Konfigurationshantering av system och nätverk
- Radering av information när den inte längre behövs
- Datamaskning för att skydda känsliga uppgifter
- Förhindrande av dataläckage (DLP)
- Övervakning av aktiviteter i realtid
- Webbfiltrering mot skadliga webbplatser
- Säker kodning vid systemutveckling
För organisationer som redan certifierats enligt 2013 års version innebär övergången att befintlig SoA måste mappas om mot de nya 93 kontrollerna. Många upptäcker då att de redan uppfyller flera av nyheterna informellt, men saknar dokumentation som håller för en revisor.
Organisatoriska kontroller: styrning, ansvar och leverantörer
Tema A.5 omfattar 37 kontroller och utgör ryggraden i hela ledningssystemet. Det handlar om policyer, roller och ansvar, klassificering av information och hur du styr relationer med leverantörer. Det är också det tema flest organisationer bör börja med, eftersom nästan alla andra kontroller förutsätter att governance-strukturen redan finns på plats.
Tre områden bär mest tyngd i praktiken:
- Informationssäkerhetspolicyer som är godkända av ledningen och faktiskt kända av personalen, inte bara arkiverade i ett dokumentsystem.
- Roller och ansvar som är tydligt tilldelade, inklusive vem som äger vilken risk och vem som godkänner undantag.
- Leverantörsstyrning, där avtal innehåller säkerhetskrav och du har en process för att bedöma leverantörers risknivå innan kontrakt tecknas.
När du motiverar tillämplighet i SoA för dessa kontroller räcker det sällan att skriva “tillämplig”. Revisorn vill se kopplingen till en identifierad risk: varför just den här policyn behövs, vilken risk den mildrar, och vem som är ansvarig för att den efterlevs. En kontrollista för riskhantering kan hjälpa dig strukturera den kopplingen innan du fyller i SoA.
Proffstips: Skriv aldrig “N/A” utan en fullständig mening som förklarar varför. En rad som “Ej tillämpligt, verksamheten har ingen fysisk serverhall” håller för granskning. Ett ensamt “N/A” gör det inte.
Klassificering av information hör också hit, och det är en kontroll som ofta underskattas. Utan en tydlig klassificeringsmodell blir det svårt att motivera senare tekniska kontroller som kryptering eller åtkomstbegränsning, eftersom du inte har definierat vad som faktiskt behöver skyddas mest.
Personrelaterade kontroller: från screening till incidentrapportering
Tema A.6 omfattar åtta kontroller och handlar om människorna i organisationen snarare än systemen. Det spänner från bakgrundskontroller vid rekrytering till vad som händer när en anställd slutar.
Nyckelområdena du behöver täcka är:
- Bakgrundskontroll (screening) innan anställning, anpassad efter rollens känslighet
- Tydliga anställningsvillkor som inkluderar sekretess och säkerhetsansvar
- Återkommande utbildning och medvetandehöjande insatser för hela personalen
- En känd process för att rapportera säkerhetsincidenter, utan rädsla för repressalier
- Policyer för distansarbete som täcker allt från hemnätverk till skärmlås på kaféer
Dokumentationen behöver vara spårbar snarare än omfattande. Utbildningsbevis, deltagarlistor och en logg över incidentrapporter räcker långt om de uppdateras löpande. Ett vanligt undantag i SoA gäller distansarbetspolicyer för organisationer utan anställda som arbetar utanför kontoret, men det kravet blir alltmer sällsynt i takt med att hybridarbete blivit norm snarare än undantag.
Fysiska kontroller: vad revisorn brukar fråga efter
Tema A.7 innehåller fjorton kontroller kring fysisk säkerhet: perimeterskydd, fysisk åtkomstkontroll, säker förvaring av utrustning och korrekt avfallshantering av dokument och hårddiskar. För organisationer med egna kontor eller serverrum är dessa kontroller självklara att implementera.
För renodlade molnbaserade verksamheter ser bilden annorlunda ut. Att utesluta poster som “säkerhet i serverrum” är ofta rimligt, men uteslutningen måste stödjas av bevis, till exempel avtal med molnleverantören som visar att den fysiska säkerheten hanteras där.
Typiska bevis revisorn vill se inkluderar:
- Rutiner för besökare och tillträdeskontroll till kontorslokaler
- Loggar över vem som haft fysisk åtkomst till känsliga utrymmen
- Servicerapporter för utrustning som destrueras eller återvinns
- Avtal med tredje part där fysisk säkerhet är dennes ansvar
Om din organisation hanterar egen backup-infrastruktur lokalt är det värt att se över rutiner för snabb dataåterställning som en del av bevisningen för både fysiska och tekniska kontroller.
Tekniska kontroller: autentisering, kryptering och de nya 2022-kraven
Tema A.8 är det största temat med 34 kontroller och omfattar det mesta läsaren förknippar med informationssäkerhet i vardagen: autentisering, kryptering, loggning och övervakning, patchhantering och sårbarhetshantering. Det är också temat där flest av de nya 2022-kontrollerna hamnar.
Fem tekniska områden bär störst tyngd i en normal implementering:
- Åtkomstkontroll och autentisering, inklusive multifaktorautentisering för kritiska system.
- Kryptering av data i vila och under överföring, kopplad till den klassificeringsmodell du satte upp under A.5.
- Loggning och övervakning, gärna centraliserad genom ett SIEM-verktyg för att upptäcka avvikelser i tid.
- Sårbarhetshantering och patchning, med en dokumenterad tidsram för hur snabbt kritiska sårbarheter ska åtgärdas.
- Skydd mot dataläckage (DLP), en av de kontroller som tillkom 2022 och som många organisationer fortfarande saknar formell process för.
Utöver DLP behöver du planera för konfigurationshantering, säker radering av information, datamaskning, webbfiltrering och säker kodning vid egen systemutveckling. Dessa nya kontroller kräver ofta tekniska investeringar snarare än enbart policyuppdateringar, vilket gör att fas 2 i en implementeringsplan bör budgeteras med både tid och pengar.
Proffstips: Bevisa tekniska kontroller med konkreta artefakter, inte beskrivningar. Konfigurationsexport från brandväggen, ett utdrag ur loggsystemet och ett testprotokoll från senaste sårbarhetsskanningen väger tyngre än ett policydokument som säger att kontrollen “finns”.
För molnbaserade tjänster är A.8 ofta det tema där flest kontroller är tillämpliga, medan vissa poster i A.7 kan uteslutas med rätt motivering, enligt praktisk vägledning för SaaS-organisationer.
Hur väljer du vilka Annex A-kontroller som är tillämpliga?
Processen börjar alltid i riskbedömningen, aldrig i kontrollistan. Det är den vanligaste missuppfattningen: att arbeta sig igenom Annex A som en checklista uppifrån och ner, istället för att låta identifierade risker styra vilka kontroller som behövs.
Rätt ordning ser ut så här:
- Identifiera risker kopplade till dina informationstillgångar, hot och sårbarheter.
- Värdera riskerna utifrån sannolikhet och konsekvens för att avgöra vilka som kräver åtgärd.
- Välj kontroller från Annex A som mildrar de identifierade riskerna till en acceptabel nivå.
- Motivera i SoA varför varje kontroll är tillämplig eller inte, med tydlig koppling till risken.
- Implementera och verifiera att kontrollen faktiskt fungerar som avsett, inte bara finns på pappret.
Varje rad i SoA måste innehålla fyra delar: om kontrollen är tillämplig eller inte, en motivering för beslutet, aktuell implementeringsstatus och en referens till relevant dokumentation eller bevis. Kravet att dokumentera detta finns direkt i klausul 6.1.3d, och revisorer granskar just motiveringarna hårdare än själva urvalet.
Vanliga misstag att undvika:
- Att skriva “ej tillämpligt” utan förklaring, vilket nästan garanterat leder till en revisionsanmärkning
- Att kopiera en mall rakt av utan att anpassa motiveringarna till den egna verksamheten
- Att glömma uppdatera SoA när nya system eller leverantörer tillkommer
- Att bedöma kontroller isolerat från den riskbedömning som redan gjorts
Prioriteringsordning: snabbvinster först, 2022-nyheter i fas två
En rimlig implementeringsordning för ett medelstort företag sträcker sig över sex till tolv månader och följer en tydlig logik: bygg grunden innan du lägger till det avancerade.
- Governance och grundkontroller (policyer, roller, ansvar) under de första fyra till sex veckorna.
- Snabbvinster som åtkomstkontroll, skydd mot skadlig kod och backup-rutiner, ofta klara inom en till två månader.
- Moln och leverantörer, inklusive avtal och leverantörsbedömningar, parallellt under månad två till tre.
- Teknisk grund som nätverkssegmentering och centraliserad loggning, ungefär månad tre till fem.
- Sårbarhetshantering och patchrutiner, etablerat som löpande process från månad fyra.
- 2022-nyheterna som DLP, datamaskning och säker kodning i en andra fas, ofta månad sex och framåt.
En fasindelad prioritering enligt denna modell ger ledningen synliga framsteg tidigt, vilket underlättar fortsatt budget och stöd för resten av arbetet. Mät framgång genom andelen kontroller med fullständig SoA-dokumentation snarare än enbart hur många som är “klara” i teorin.
| Fas | Fokus | Tidsram |
|---|---|---|
| 1 | Governance och snabbvinster | Månad 1–2 |
| 2 | Moln, leverantörer och teknisk grund | Månad 2–5 |
| 3 | Sårbarhetshantering och 2022-nyheter | Månad 4–6 |
Effektivitet och uppföljning: hur ofta ska kontrollerna granskas?
Att implementera en kontroll är inte slutpunkten. Regelbunden verifiering rekommenderas, ofta i cykler mellan ett och tre år beroende på hur kritisk kontrollen är för organisationens riskbild.
En rullande internrevisionsplan där olika kontrollgrupper granskas i tur och ordning fungerar bättre än att försöka täcka alla 93 samtidigt varje år. Kombinera det med minst en årlig ledningens genomgång (management review) där avvikelser, incidenter och förändringar i riskbilden vägs in. Effektiviteten mäts bäst genom konkreta indikatorer: andelen system med aktuell patchnivå, tid till åtgärd vid incidenter, eller andelen personal som genomfört säkerhetsutbildning senaste året.
Så stödjer ett compliance-verktyg arbetet med Annex A
Att hålla 93 kontroller, motiveringar och bevis samlade i kalkylark blir snabbt ohanterligt när organisationen växer eller när revisionen närmar sig. Ett verktyg som Trustview samlar SoA-mallar, åtgärdsspårning och leverantörsbedömningar på samma plats, vilket gör det enklare att visa spårbarhet inför en internrevision.
Konkret innebär det:
- Färdiga mallar för att strukturera SoA per kontroll och tema
- Spårning av åtgärder med tydligt ansvar och deadline
- Bedömning och uppföljning av leverantörer kopplat till relevanta A.5-kontroller
- Automatiserade rapporter som underlättar inför både internrevision och den externa certifieringsrevisionen
Proffstips: Ett verktyg löser dokumentation och spårbarhet, inte den juridiska bedömningen av komplexa risker. Ta in extern rådgivning när riskbilden är ovanligt komplicerad eller när ni certifieras för första gången.
Kom igång med er Statement of Applicability
Annex A blir hanterbart när arbetet utgår från risk snarare än från att bocka av en lista, och det är precis den ordningen en fungerande SoA-process bygger på. Trustview hjälper säkerhetsansvariga och compliance-team att strukturera det arbetet, från riskkoppling till färdig dokumentation som håller för revision. Läs mer om varför en svensk plattform gör skillnad för organisationer som vill effektivisera sitt Annex A-arbete utan att tumma på kvaliteten i dokumentationen.
Varför kontrollräkning är fel utgångspunkt
Den vanligaste missuppfattningen om Annex A är att implementeringen mäts i hur många av de 93 kontrollerna som är “klara”. Det är fel mått. En organisation kan ha fyrtio välmotiverade, riskkopplade kontroller och klara en revision utan anmärkning, medan en annan med sjuttio ytligt implementerade kontroller fastnar på första SoA-genomgången.
Konventionella guider lägger för mycket vikt vid att räkna och för lite vid motiveringen bakom varje beslut. Revisorer läser inte Annex A som en checklista, de läser SoA som ett resonemang. Det är skillnaden mellan att skriva “tillämplig” och att skriva varför, kopplat till en specifik risk och ett specifikt ansvar.
Det jag tycker säkerhetsansvariga underskattar mest är hur mycket tid som sparas genom att bygga SoA parallellt med riskbedömningen, inte efteråt. De organisationer som gör dem sekventiellt hamnar nästan alltid i efterhandskonstruerade motiveringar som känns tunna för en erfaren revisor. Börja med riskerna, låt kontrollerna följa, och SoA skriver nästan sig själv.
— Jesper
