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:
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).
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:
Utöver lagkraven utlöses en riskanalys typiskt av:
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:
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.
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:
| Fält | Beskrivning |
|---|---|
| ID | Unikt id för risken, för spårbarhet |
| Informationstillgång | Vilken information eller vilket system risken gäller |
| Hot | Vilken händelse som kan inträffa |
| Sårbarhet | Den brist i skyddet som hotet utnyttjar |
| Befintliga åtgärder | Vad som redan är på plats |
| Sannolikhet | Bedömning på en skala, exempelvis 1 till 5 |
| Konsekvens | Bedömning på samma skala |
| Riskvärde | Sannolikhet x konsekvens, eller annan beräkning |
| Riskbehandling | Acceptera, åtgärda, överföra eller undvika |
| Åtgärdsförslag | Konkreta åtgärder för att minska risken |
| Ansvarig | Vem som ansvarar för genomförandet |
| Tidsplan | När åtgärden ska vara klar |
| Restrisk | Risken kvar efter åtgärd |
| Datum för granskning | När risken ska omprövas |
Två tilläggsfält som rekommenderas för organisationer med komplex behandling av personuppgifter:
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.
Tre exempel som visar hur olika risker fångas och behandlas:
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:
Vid riskhanteringen finns 4 standardalternativ:
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.
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:
Ä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.
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.
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.
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.
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.
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.
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.
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.