NIS2 riskanalys mall: steg-för-steg-metodik
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
NIS2 riskanalys mall: steg-för-steg-metodik
Riskanalysen är NIS2-direktivets bärande konstruktion. Alla övriga åtgärder — incidenthantering, leverantörssäkerhet, kontinuitetsplanering — dimensioneras av den. NIS2 Artikel 21(2)(a) kräver att varje väsentlig och viktig entitet genomför riskanalyser som grund för sina cybersäkerhetsåtgärder. Den här artikeln ger dig en konkret metodik, ramverksval och en steg-för-steg-process anpassad för svenska organisationer.
Viktiga slutsatser
- NIS2 Artikel 21(2)(a) kräver riskanalys som grund för samtliga cybersäkerhetsåtgärder
- Riskanalysen dimensionerar alla andra NIS2-krav via proportionalitetsprincipen
- ISO 27005 är det naturliga förstavalet för organisationer med befintligt ISO 27001-arbete
- Riskanalysen är ett löpande arbete — inte en engångsinsats utan minst årlig omvärdering
- Utan dokumenterad riskanalys kan du inte argumentera för proportionerliga åtgärder inför tillsynsmyndigheten
Vad kräver NIS2 av riskanalysen?
NIS2 Artikel 21(2)(a) listar "strategier för riskanalys och informationssystemsäkerhet" som en av de tio obligatoriska basåtgärderna. Det är ingen slump att riskanalys står först — den är navet som alla andra krav roterar kring.
ENISA rekommenderar ett riskbaserat tillvägagångssätt där åtgärdernas omfattning ska vara proportionerlig mot identifierade risker. I praktiken innebär det att riskanalysen inte bara är ett krav att bocka av, den bestämmer hur djupt ni måste gå i varje annat kravområde.
Proportionalitetsprincipen
NIS2 kräver inte att alla organisationer implementerar identiska kontroller. Åtgärderna ska vara "lämpliga och proportionerliga" med hänsyn till:
- Organisationens storlek — en kommun med 500 anställda och en storbank har olika riskprofiler
- Exponering för risker — internetexponerade OT-system kräver andra åtgärder än ett slutet kontorsnätverk
- Incidenters potentiella samhällseffekt — en driftstörning i en vattenreningsverk väger tyngre än i en konsultfirma
- Teknikens aktuella nivå och kostnaderna för genomförande
Riskanalysen är det verktyg som fastställer den proportionerliga nivån. Utan den kan ni inte argumentera för att era åtgärder är rimliga — och det är precis den argumentationen som tillsynsmyndigheter som Integritetsskyddsmyndigheten (IMY) och sektorsspecifika myndigheter förväntar sig.
Kontinuitet, inte engångsinsats
Ett vanligt missförstånd: att riskanalysen görs en gång och sedan samlar damm i en mapp. NIS2 förutsätter löpande riskhantering. Riskanalysen ska uppdateras vid:
- Väsentliga förändringar i hotlandskapet (nya angreppstyper, ändrad geopolitik)
- Organisationsförändringar (förvärv, omstruktureringar, ny affärskritisk tjänst)
- Förändringar i IT-miljön (molnmigrering, ny leverantör, arkitekturändring)
Minst en årlig fullständig omvärdering är rimlig praxis. I vår SOC ser vi att organisationer som kör kvartalsvis hotbildsuppdatering och årlig djupanalys hamnar i en betydligt bättre position — både operativt och regulatoriskt.
Vill ni ha expertstöd med nis2 riskanalys mall: steg-för-steg-metodik?
Våra molnarkitekter hjälper er med nis2 riskanalys mall: steg-för-steg-metodik — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
Hur väljer du rätt ramverk?
Flera erkända ramverk fungerar för NIS2-riskanalys. Valet beror på organisationens mognad, befintliga processer och internationella anknytning.
| Ramverk | Bäst för | Styrkor | Begränsningar |
|---|---|---|---|
| ISO 27005 | Organisationer med ISO 27001 | Direkt integration med ISO 27001 kravstruktur; brett erkänt i EU | Kan upplevas abstrakt utan praktisk erfarenhet |
| NIST SP 800-30 | Organisationer med amerikanskt dotterbolag eller detaljbehov | Detaljerade hotkataloger; systematiskt stegvist tillvägagångssätt | Mer resurskrävande; amerikansk terminologi |
| EBIOS Risk Manager | Komplexa hotlandskap, kritisk infrastruktur | Fokus på strategiska angreppsscenarier; stark i EU-kontext (ANSSI) | Överdimensionerad för mindre organisationer |
Vad rekommenderar vi?
Börja med ISO 27005 om ni redan har ett ISO 27001-relaterat arbete — det ger en naturlig integration och minskar dubbelarbete. Komplettera med NIST SP 800-30:s hotkataloger för att systematisera hotidentifieringen. Det viktigaste är att välja ett erkänt ramverk och använda det konsekvent. Tillsynsmyndigheter kräver inte ett specifikt ramverk men förväntar sig en systematisk, dokumenterad och repeterbar metodik.
Steg 1: Etablera kontext och omfång
Varje riskanalys börjar med att definiera vad som ska analyseras. Hoppa inte över det här steget — vi ser regelbundet organisationer som kastar sig direkt in i hotidentifiering utan att ha avgränsat omfånget, och resultatet blir en ohanterlig analys som inte ger beslutsunderlag.
Definiera analysens gränser
- Organisatorisk kontext: Vilka verksamhetsdelar omfattas av NIS2? Vilka tjänster klassas som väsentliga eller viktiga?
- IT-kontext: Vilka system, nätverk och dataflöden stödjer dessa tjänster? Inkludera molnmiljöer — arbetsbelastningar i AWS eu-north-1 (Stockholm) eller Azure Sweden Central omfattas fullt ut.
- Extern kontext: Vilka leverantörer, partners och tredjepartstjänster är kritiska? NIS2 Artikel 21(2)(d) kräver uttryckligen att leveranskedjan ingår.
Inventera informationstillgångar
Dokumentera alla tillgångar som stödjer de tjänster som är inom omfånget:
- Tekniska tillgångar: servrar, databaser, nätverkskomponenter, molnresurser, IoT/OT-enheter
- Informationstillgångar: kunddata, driftsdata, systemkonfigurationer, nycklar och hemligheter
- Mänskliga tillgångar: driftspersonal, administratörer med privilegierade konton, underleverantörers personal med åtkomst
En inventering som inte inkluderar molnresurser är per definition ofullständig 2026. Infrastruktur som kod (IaC) via Terraform eller Pulumi gör det möjligt att automatiskt generera tillgångsinventeringar — vi rekommenderar att koppla den processen direkt till riskanalysarbetet.
Steg 2: Identifiera hot och sårbarheter
Med omfånget definierat och tillgångarna inventerade kartlägger ni de hot som kan påverka dem.
Hotkategorier relevanta för NIS2
- Cyberhot: ransomware, phishing, DDoS, supply-chain-attacker, zero-day-exploits
- Interna hot: felkonfigurationer (den vanligaste incidentorsaken i molnmiljöer enligt Datadogs State of Cloud-rapport), obehörig åtkomst, mänskliga misstag
- Fysiska hot: strömavbrott, naturhändelser, fysiskt intrång
- Leverantörsrelaterade hot: driftstörning hos molnleverantör, komprometterad tredjepartskomponent, leverantörs konkurs
Sårbarhetskartläggning
Koppla hoten till faktiska sårbarheter i era system. Använd:
- Automatiserad sårbarhetsskanning för tekniska brister
- Konfigurationsgranskning mot CIS Benchmarks eller leverantörsspecifika ramverk (AWS Well-Architected, Azure Architecture Center)
- Processgranskning för organisatoriska sårbarheter: saknas det incidenteskaleringsrutiner? Finns det otestad backup?
Steg 3: Analysera och värdera risker
Nu kvantifierar (eller kvalificerar) ni riskerna. En risk är kombinationen av sannolikhet att ett hot utnyttjar en sårbarhet och konsekvens om det inträffar.
Riskmatris
En typisk 5×5-matris fungerar väl:
| Obetydlig | Lindrig | Måttlig | Allvarlig | Kritisk | |
|---|---|---|---|---|---|
| Mycket hög sannolikhet | Medel | Hög | Hög | Mycket hög | Mycket hög |
| Hög sannolikhet | Låg | Medel | Hög | Hög | Mycket hög |
| Medel sannolikhet | Låg | Medel | Medel | Hög | Hög |
| Låg sannolikhet | Låg | Låg | Medel | Medel | Hög |
| Mycket låg sannolikhet | Låg | Låg | Låg | Medel | Medel |
Konsekvensbedömning i NIS2-kontext
NIS2 lägger särskild vikt vid samhällseffekt. Er konsekvensbedömning bör explicit inkludera:
- Operativ konsekvens: driftstopp, dataförlust, ekonomisk skada
- Samhällskonsekvens: påverkan på medborgare, offentliga tjänster, kritisk infrastruktur
- Regulatorisk konsekvens: rapporteringskrav (24-timmarsvarning vid incident), sanktionsavgifter
- Reputationskonsekvens: förtroendeförlust, kundbortfall
Dokumentera varje riskvärdering med motivering. "Hög risk" utan förklaring håller inte vid tillsyn.
Steg 4: Behandla riskerna
Riskbehandling innebär att besluta hur varje identifierad risk ska hanteras. Det finns fyra grundalternativ:
1. Reducera — implementera kontroller som minskar sannolikhet eller konsekvens (vanligaste valet)
2. Överföra — flytta risken genom försäkring eller avtal (t.ex. cyberförsäkring, SLA med driftleverantör)
3. Undvika — avveckla den tjänst eller process som genererar risken
4. Acceptera — medvetet beslut att bära risken (kräver dokumenterat ledningsbeslut)
Koppla behandlingen till NIS2:s tio basåtgärder
Varje riskbehandlingsåtgärd bör mappas mot relevant punkt i Artikel 21(2):
- Incidenthantering (b) — hur reducerar åtgärden incidentrisken?
- Driftskontinuitet (c) — säkerställer åtgärden återställning?
- Leveranskedjans säkerhet (d) — adresserar åtgärden tredjepartsrisken?
- Kryptografi och kryptering (h) — skyddas data i transit och vila?
Den här mappningen ger er en spårbar kedja från identifierad risk till NIS2-krav till implementerad kontroll.
Steg 5: Dokumentera, kommunicera och underhåll
Dokumentationen är inte en byråkratisk formalitet — den är ert bevisunderlag vid tillsyn.
Dokumentationskrav
- Riskregister: sammanställning av alla identifierade risker med värdering, ägare och behandlingsbeslut
- Riskbehandlingsplan: åtgärder, ansvarig, tidplan och status
- Ledningsbeslut: styrelse eller ledningsgrupp ska godkänna accepterade risker och övergripande risknivå
- Uppdateringslogg: när analysen senast omvärderades och varför
Opsios perspektiv: vad vi ser i praktiken
Från vår SOC/NOC i Karlstad och Bangalore ser vi ett återkommande mönster: organisationer som behandlar riskanalysen som ett levande dokument — integrerat med sina övervakningsverktyg och incidentprocesser — har fundamentalt bättre säkerhetsläge än de som producerar ett PDF-dokument en gång om året.
Konkret rekommenderar vi:
- Koppla riskregistret till era SIEM/SOAR-plattformar så att nya hotunderrättelser automatiskt flaggar berörda risker för omvärdering
- Automatisera tillgångsinventering via IaC och cloud asset management — manuella inventeringar är föråldrade redan när de skrivs klart
- Kör tabletop-övningar kvartalsvis där ni simulerar scenarierna i riskanalysen och validerar att behandlingsåtgärderna faktiskt fungerar
Vanliga fallgropar att undvika
- För brett omfång — försöker analysera allt samtidigt och får ett ohanterligt resultat. Avgränsa, prioritera kritiska tjänster, iterera.
- Generiska hotlistor — kopierar branschrapporter utan att anpassa till er faktiska miljö. En hotbild för en bank gäller inte rakt av för en sjukvårdsregion.
- Ingen koppling till beslutsfattande — riskanalysen hamnar hos informationssäkerhetschefen men når aldrig styrelsen. NIS2 Artikel 20 kräver uttryckligen ledningens ansvar.
- Statisk analys — görs en gång 2025 och uppdateras aldrig. Hotlandskapet ändras snabbare än era policydokument.
Vanliga frågor
Måste vi använda ISO 27005 för NIS2-riskanalysen?
Nej. NIS2 anger inget specifikt ramverk. Tillsynsmyndigheter förväntar sig däremot en systematisk och erkänd metodik. ISO 27005, NIST SP 800-30 och EBIOS Risk Manager är alla godtagbara. Det viktigaste är konsekvens och spårbarhet i dokumentationen.
Hur ofta ska riskanalysen uppdateras?
NIS2 kräver löpande riskhantering. En fullständig omvärdering minst en gång per år är rimlig praxis. Därutöver ska analysen uppdateras vid väsentliga förändringar i hotlandskapet, organisationsstruktur, systemarkitektur eller leverantörskedjor.
Vad händer om vi inte har en riskanalys när NIS2 ska tillämpas?
Utan dokumenterad riskanalys saknar ni grunden för att visa att era åtgärder är proportionerliga — det är en central del av NIS2. Tillsynsmyndigheter kan utfärda förelägganden och sanktionsavgifter. Börja med en avgränsad pilotanalys av era mest kritiska tjänster.
Räcker vår befintliga ISO 27001-riskbedömning?
Den ger ett bra fundament, men NIS2 ställer krav på att riskanalysen uttryckligen adresserar alla tio basåtgärder i Artikel 21, inklusive leveranskedjor och incidenthantering. Gå igenom er befintliga analys mot NIS2:s kravlista och komplettera gapen.
Kan vi göra riskanalysen själva eller behöver vi extern hjälp?
Organisationer med mogen informationssäkerhet kan driva processen internt. Men extern granskning ger oberoende och trovärdighet — särskilt för väsentliga entiteter. En managerad säkerhetstjänst kan stötta med hotunderrättelser, teknisk inventering och löpande omvärdering.
Relaterade artiklar
Om författaren
Group COO & CISO at Opsio
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.
