Riskanalys för informationssäkerhet

En riskanalys för informationssäkerhet synliggör vilka informationstillgångar ni har, vilka hot och sårbarheter som finns, och vilka skyddsåtgärder som står i proportion till risken. Både GDPR, cybersäkerhetslagen (2025:1506) och ISO 27001 kräver en dokumenterad riskanalys, och formen ska spegla verksamhetens komplexitet och hotbild. För det operativa arbetet kan ni utgå från ett incidenthanteringssystem.

Det här behöver du veta:

• Riskanalys för informationssäkerhet är obligatorisk enligt cybersäkerhetslagen, art. 32 GDPR och ISO 27001.
• En användbar riskanalys görs i 6 steg: Kartlägg tillgångar, identifiera hot, identifiera sårbarheter, värdera risker, fastställ åtgärder och dokumentera.
• Riskbedömning bygger normalt på 2 dimensioner, sannolikhet och konsekvens, och resultatet styr vilka risker som ska accepteras, åtgärdas, överföras eller undvikas.
• Mallen behöver minst innehålla tillgång, hot, sårbarhet, sannolikhet, konsekvens, riskvärde, befintliga åtgärder, åtgärdsförslag, ansvar och datum.
• Riskanalysen ska uppdateras minst 1 gång per år, alltid vid större förändringar eller efter en incident.

Vad är en riskanalys för informationssäkerhet?

En riskanalys för informationssäkerhet är en strukturerad genomgång av vilka informationstillgångar verksamheten har, vilka hot och sårbarheter som finns, och vilken risk som varje kombination av tillgång, hot och sårbarhet utgör för verksamheten.

Syftet är dubbelt. För det första ska analysen ge ett underlag för att besluta om vilka tekniska och organisatoriska åtgärder som behövs, så att skyddet står i proportion till risken och inte över- eller underskjuter. För det andra ska analysen vara dokumentationen som visar att ni arbetar systematiskt, vilket är ett krav vid tillsyn enligt både GDPR och cybersäkerhetslagen.

Riskanalys är en del av det bredare området riskhantering, som även omfattar val av riskbehandling, uppföljning och löpande omprövning. I ISO 27001 är riskanalys och riskhantering kärnan i ledningssystemet för informationssäkerhet (LIS).

När och varför behöver ni göra en riskanalys för informationssäkerhet?

Du behöver göra en riskanalys för informationssäkerhet när lagen kräver det, när verksamheten genomgår större förändringar, när nya hot uppstår eller efter en allvarlig incident. För många organisationer är det dessutom ett löpande krav minst 1 gång per år.

Riskanalysen är obligatorisk enligt flera regelverk:

• Cybersäkerhetslagen (2025:1506) kräver riskanalys för nätverks- och informationssystem hos väsentliga och viktiga entiteter i 18 sektorer
• GDPR art. 32 kräver att tekniska och organisatoriska åtgärder står i proportion till risken, vilket förutsätter att risken är bedömd. Vid behandlingar med hög risk krävs dessutom en konsekvensbedömning (DPIA) enligt art. 35
• Säkerhetsskyddslagen (2018:585) kräver säkerhetsskyddsanalys för verksamheter med betydelse för Sveriges säkerhet
• DORA-förordningen (EU 2022/2554) kräver IKT-riskanalys för finansiella entiteter
• ISO 27001 kräver återkommande riskbedömning och riskhantering som kärna i ledningssystemet

Utöver lagkraven utlöses en riskanalys typiskt av:

• Större förändringar i IT-arkitektur, nya system eller migrering till molnet
• Byte av kritisk leverantör eller ny leverantörsuppföljning
• Större organisationsförändringar, fusioner eller förvärv
• Ny lagstiftning som tillkommer eller skärps
• Efter en allvarlig incident, både egen och i branschen
• Periodisk översyn enligt det egna ledningssystemet, normalt minst årligen

Så gör du en riskanalys för informationssäkerhet i 6 steg

Du gör riskanalysen i 6 steg, kartlägg informationstillgångar, identifiera hot, identifiera sårbarheter, värdera risker utifrån sannolikhet och konsekvens, fastställ riskbehandling och dokumentera resultatet.

Stegen kan utföras enklare eller mer omfattande beroende på verksamhetens komplexitet, men kärnan är densamma:

1. Kartlägg informationstillgångar. Vilken information finns i verksamheten, vilka system och processer hanterar den, vilka människor har tillgång och vilka externa parter behandlar uppgifter på ert uppdrag. Kartläggningen bör täcka både digital information och fysiska tillgångar som papper, hårddiskar och fysiska arkiv. Utan kartläggningen vet ni inte vad ni ska skydda
2. Identifiera hot. Vilka händelser kan drabba tillgångarna? Hot kan vara externa, exempelvis ransomware, phishing, intrång, eller interna, exempelvis felaktig hantering av personal eller medvetna missbruk. Naturhändelser, brand och strömavbrott bör också ingå
3. Identifiera sårbarheter. Var i tekniska, organisatoriska eller fysiska skyddet finns svagheter som ett hot skulle kunna utnyttja? Sårbarheter kan vara osäkrade konton, otillräcklig utbildning, oklar ansvarsfördelning eller bristande loggning
4. Värdera risker. Bedöm sannolikhet och konsekvens för varje kombination av tillgång, hot och sårbarhet. Värderingen ska vara reproducerbar, alltså att en annan person med samma underlag skulle komma till samma slutsats
5. Fastställ riskbehandling. Vilka risker accepteras, vilka ska åtgärdas, vilka ska överföras (exempelvis via försäkring) och vilka ska undvikas helt? Åtgärderna ska stå i proportion till risken
6. Dokumentera och kommunicera. Resultatet ska dokumenteras på ett sätt som visar hur ni resonerat, vilka åtgärder ni valt och varför. Dokumentationen är både ett styrdokument och ett bevis vid tillsyn

För personuppgiftsbehandlingar med hög risk behöver riskanalysen ofta kompletteras med en konsekvensbedömning enligt art. 35 GDPR. Mer om hur det går till finns i vår tjänst för DPIA / konsekvensbedömning.

Mall: så strukturerar du en riskanalys för informationssäkerhet

En användbar mall för riskanalys för informationssäkerhet innehåller minst 10 fält, tillgång, hot, sårbarhet, befintliga åtgärder, sannolikhet, konsekvens, riskvärde, riskbehandling, ansvarig och datum för granskning.

Mallen kan utformas som ett kalkylark, ett dokument eller en post i ett ledningssystem. Det viktiga är att samma struktur används konsekvent, så att riskerna går att jämföra över tid och mellan delar av verksamheten. Föreslagen struktur:

Två tilläggsfält som rekommenderas för organisationer med komplex behandling av personuppgifter:

• Påverkan på registrerade, så att riskanalysen kan kopplas mot DPIA-arbetet
• Hänvisning till behandling i registerförteckningen, för spårbarhet mellan dokumenten

Det här är en mall, inte en formell standard. ISO/IEC 27005 ger en mer detaljerad metodbeskrivning för organisationer som vill formalisera arbetet ytterligare.

Exempel på hur riskanalysen används i praktiken

Tre exempel som visar hur olika risker fångas och behandlas:

• "Risken att en medarbetares konto kapas via phishing fick sannolikhet 4, konsekvens 5 och riskvärde 20. Åtgärden var att införa MFA på samtliga konton inom 6 månader."
• "Risken att ett ekonomisystem blir otillgängligt vid ett ransomware-angrepp fick sannolikhet 3, konsekvens 5 och riskvärde 15. Åtgärden var att införa offline-säkerhetskopiering och årliga återställningstester."
• "Risken att en leverantör hanterar personuppgifter utanför EU utan SCC fick sannolikhet 2, konsekvens 5 och riskvärde 10. Åtgärden var en ny leverantörsuppföljning och granskning av befintliga biträdesavtal."

Riskbedömning och riskhantering: så värderar och behandlar du riskerna

Riskbedömningen värderar varje risk utifrån sannolikhet och konsekvens, och riskhanteringen bestämmer vad ni gör med risken, accepterar, åtgärdar, överför eller undviker. Båda momenten ska vara dokumenterade och beslutade på rätt nivå i organisationen.

Riskbedömningen kan göras kvalitativt eller kvantitativt:

• Kvalitativ riskbedömning använder skalor som låg, medel, hög eller siffror 1 till 5. Det är den vanligaste metoden i informationssäkerhetsarbete, eftersom konsekvenser ofta är svåra att uttrycka i kronor och hot är svåra att sannolikhetssätta exakt
• Kvantitativ riskbedömning uttrycker risk i monetära termer, exempelvis förväntad årlig förlust (ALE). Används främst i större organisationer med moget riskarbete och rika historiska data

Vid riskhanteringen finns 4 standardalternativ:

1. Acceptera risken, vilket är giltigt när riskvärdet är lågt och kostnaden för åtgärd skulle överstiga nyttan. Acceptansen ska dokumenteras och beslutas av rätt nivå
2. Åtgärda risken med tekniska eller organisatoriska åtgärder, så att sannolikhet eller konsekvens minskar
3. Överföra risken, exempelvis via försäkring, outsourcing eller avtalsvillkor som flyttar ansvaret till motpart
4. Undvika risken genom att avstå från den verksamhet, det system eller den behandling som orsakar risken

Restrisken efter åtgärd ska alltid bedömas på nytt. Om restrisken fortfarande är för hög, behövs ytterligare åtgärder eller en formell acceptans på högre nivå i organisationen. Vid behandlingar med hög risk enligt GDPR krävs dessutom en formell DPIA, mer om det i guiden till DPIA i praktiken.

Vanliga misstag i riskanalysen

De vanligaste misstagen är att riskanalysen blir ett engångsarbete, att den bara täcker IT-systemet och inte informationen, och att åtgärderna inte följs upp till slutförande.

Återkommande fallgropar i tillsynsärenden och revisioner:

• Riskanalysen blir ett engångsarbete istället för en levande del av ledningssystemet. Riskbilden förändras, och en analys från 2 år tillbaka är sällan giltig idag
• Bara IT-systemen analyseras, medan papper, muntlig informationsdelning och leverantörer faller utanför. Informationssäkerhet är bredare än IT-säkerhet
• Åtgärder fastställs men följs inte upp. När tillsynsmyndigheten frågar visar dokumentationen vad ni skulle göra, inte vad ni gjorde
• Sannolikhets- och konsekvensbedömningarna är inkonsekventa mellan riskerna, så att jämförelse och prioritering blir omöjlig
• Ledningen är inte involverad i bedömningen av allvarliga risker. När riskbeslut behöver fattas på hög nivå saknas både underlag och förankring
• Beroenden mellan risker fångas inte, exempelvis hur en leverantörsrisk även påverkar tillgängligheten av interna processer
• Riskanalys och DPIA blandas ihop. De har olika syfte och delvis olika innehåll, men kan med fördel byggas så att de kompletterar varandra

Är ni osäkra på var ni står idag är Draftits GDPR-test en snabb startpunkt för att kartlägga mognadsgraden i ert riskarbete.

Vanliga frågor om riskanalys för informationssäkerhet

Hur ofta ska en riskanalys göras?

Minst 1 gång per år är ett rimligt riktvärde för de flesta organisationer. Riskanalysen ska dessutom alltid uppdateras vid större förändringar, nya system, byte av kritisk leverantör, ny lagstiftning eller efter en allvarlig incident. För verksamheter i NIS2:s tillämpningsområde är löpande omprövning ett uttryckligt krav, inte bara en god vana.

Vad är skillnaden mellan riskanalys och konsekvensbedömning (DPIA)?

Riskanalysen är bredare och täcker hela informationssäkerheten, medan konsekvensbedömning (DPIA) enligt art. 35 GDPR är ett specifikt verktyg för behandlingar av personuppgifter med hög risk för de registrerades rättigheter och friheter. En riskanalys kan utlösa kravet på DPIA, men ersätter inte själva DPIA-arbetet. För många verksamheter är det praktiskt att samordna dokumenten så att kopplingen blir spårbar.

Måste vi använda ISO 27005 för riskanalysen?

Nej. ISO/IEC 27005 är en stödstandard som ger en strukturerad metodbeskrivning för informationssäkerhetsbaserad riskhantering, men det är inte ett krav. Ni kan använda en egen metod så länge den uppfyller de krav som ställs i ISO 27001 eller i tillämpligt regelverk, alltså att den är dokumenterad, reproducerbar och leder till motiverade beslut om åtgärder.

Vem ska delta i riskanalysen?

Riskanalysen ska involvera personer som har faktisk kunskap om verksamheten, inte bara informationssäkerhetsfunktionen. Typiskt deltar informationsägare, systemägare, IT-säkerhet, dataskyddsombud och representanter från verksamheten. Ledningen behöver vara involverad åtminstone vid acceptans av risker över en viss nivå, eftersom det rättsliga ansvaret inte kan delegeras bort.

Hur djup ska riskanalysen vara?

Djupet ska stå i proportion till verksamhetens komplexitet och hotbild. En liten verksamhet med få system och små personuppgiftsmängder behöver inte samma detaljnivå som en NIS2-omfattad energileverantör. Tumregeln är att analysen ska vara så djup att ni kan motivera valet av åtgärder, inte djupare. För djup analys i en liten verksamhet är inte god ekonomi, för ytlig analys i en stor verksamhet är inte juridiskt försvarbart.

Kan vi använda en färdig mall?

Ja, men anpassa den efter er verksamhet. Ingen färdig mall fångar er specifika hotbild eller era system. Använd mallen som utgångspunkt och fyll på med kategorier av tillgångar, hot och sårbarheter som är relevanta för just er. En generisk mall som används utan anpassning blir lätt en pappersprodukt utan praktisk styrning.

Hur dokumenteras riskanalysen för tillsyn?

Dokumentationen ska visa vilka tillgångar som omfattas, vilka hot och sårbarheter som identifierats, hur sannolikhet och konsekvens bedömts, vilka åtgärder som valts och vem som beslutat om acceptans av kvarvarande risk. Versionshistorik och datum för senaste granskning ska finnas, så att tillsynsmyndigheten kan se att arbetet är levande. För organisationer med ledningssystem enligt ISO 27001 är riskanalysen en del av den övergripande dokumentationen och granskas vid både interna och externa revisioner.