Sårbarhetshantering enligt NIS2 betyder att din verksamhet systematiskt hittar, bedömer, åtgärdar och följer upp svagheter i nätverks- och informationssystem, och att du kan visa hur det går till. I Sverige genomförs kraven genom cybersäkerhetslagen och föreskrifter från Myndigheten för civilt försvar (MCF). Lagen kräver inget visst skanningsverktyg. Den kräver ett riskbaserat arbete med säkerhetsåtgärder som är förankrat i ledningen, omfattar leverantörerna och följs upp över tid. Den här guiden går igenom vad det innebär i praktiken: processen steg för steg, hur du hanterar system som inte går att patcha, och vilken dokumentation som håller vid en tillsyn.
Kort sagt
- Sårbarhetshantering är en del av de säkerhetsåtgärder som cybersäkerhetslagen kräver. Den ska vara riskbaserad, dokumenterad och följas upp.
- Prioritera efter verksamhetspåverkan och inte bara efter teknisk allvarlighetsgrad. En medelallvarlig brist i ett kritiskt system kan väga tyngre än en kritisk brist i en isolerad testmiljö.
- När patchning inte är möjlig, till exempel i äldre system och OT-miljöer, krävs kompenserande åtgärder som segmentering, begränsade anslutningar och utökad loggning.
- Leverantörer och öppen källkod räknas in i din attackyta. Avtal, SBOM och bevakning av kända sårbarheter hör till hanteringen.
- Ledningen bär ansvaret. Utan beslutade tidsramar, utsedda ägare och regelbunden rapportering blir det svårt att visa efterlevnad.
Innehållsförteckning
- Vad kraven på sårbarhetshantering innebär
- Vem som omfattas och vem som ansvarar
- Sårbarhetshantering i sex steg
- Leverantörer, molntjänster och öppen källkod
- OT och äldre system
- När en sårbarhet blir en incident
- Dokumentation som visar efterlevnad
- Vanliga misstag
- Så ser vi på sårbarhetshantering under NIS2
- Samla sårbarhetsarbetet i en plattform
- Vanliga frågor
- Källor
Vad kraven på sårbarhetshantering innebär
NIS2-direktivet räknar upp ett antal minimiåtgärder för cybersäkerhet. En av dem gäller säkerhet vid anskaffning, utveckling och underhåll av nätverks- och informationssystem, och där ingår uttryckligen hantering och offentliggörande av sårbarheter. I svensk rätt har kraven förts in i cybersäkerhetslagen och preciserats i MCF:s föreskrifter.
NCSC beskriver kärnan så här: verksamhetsutövaren ska arbeta systematiskt och riskbaserat med åtgärder mot de risker som hotar nätverks- och informationssystemen, följa upp skyddet och ställa cybersäkerhetskrav på leverantörer. Valet av åtgärder ska utgå från verksamhetens identifierade risker och behov. Risker ska identifieras, analyseras och bedömas.
För sårbarhetshanteringen får det tre konsekvenser:
- Den är inte ett fristående IT-projekt. Den ska ingå i verksamhetens ledning och styrning, på samma sätt som övrigt cybersäkerhetsarbete.
- Den ska vara proportionerlig. Kraven är inte lika för alla. Nivån bestäms av riskerna, verksamhetens storlek och hur kritiska tjänsterna är.
- Den ska gå att visa. Tillsynsmyndigheten ser till processen, besluten och uppföljningen, inte bara till hur många sårbarheter som har stängts.
En bredare genomgång av samtliga skyldigheter finns i vår guide till NIS2-kraven i Sverige.
Vem som omfattas och vem som ansvarar
Enligt Energimyndighetens svar på vanliga frågor ska verksamheter som omfattas bland annat anmäla sig, bedriva systematiskt och riskbaserat informationssäkerhetsarbete, vidta tekniska, organisatoriska och driftsrelaterade åtgärder, se till att ledningen och vid behov berörd personal är utbildad, samt rapportera betydande incidenter. Sårbarhetshanteringen berör alla delar: den är teknisk i utförandet, organisatorisk i ansvarsfördelningen och driftsrelaterad i det dagliga arbetet.
Är du osäker på om din organisation omfattas? Läs först vår genomgång av vilka företag som omfattas av NIS2.
Ansvarsfördelningen ser i regel ut så här:
- Ledningen beslutar om riskaptit, tidsramar och resurser och tar emot rapportering. Den behöver tillräcklig kunskap för att kunna fatta besluten. Läs mer om utbildningskraven för ledningen.
- CISO eller säkerhetsansvarig äger processen, sätter metoden och följer upp resultatet.
- System- och tillgångsägare ansvarar för att åtgärder genomförs i just deras system.
- IT-drift och utveckling genomför patchning, konfigurationsändringar och tester.
- Juridik och inköp ser till att leverantörsavtalen innehåller krav på sårbarhetsinformation.
Sårbarhetshantering i sex steg
En process som håller vid tillsyn behöver inte vara komplicerad, men varje steg ska ha en ägare, ett resultat och ett spår i dokumentationen.
1. Inventera tillgångarna
Du kan inte hantera sårbarheter i system du inte känner till. Börja med en förteckning över hårdvara, mjukvara, molntjänster, nätverkskomponenter och OT-enheter. Ange för varje tillgång:
- vilken verksamhetsprocess eller tjänst den stödjer
- vem som äger den
- hur kritisk den är för leveransen av samhällsviktiga eller digitala tjänster
- om den är exponerad mot internet eller andra nät
- vilken leverantör som ansvarar för underhåll och uppdateringar
Kritikalitetsklassningen är det som senare gör prioriteringen möjlig.
2. Identifiera sårbarheter
MSB, vars uppgifter inom området i dag ligger hos MCF, har rekommenderat att organisationer aktivt samlar hotunderrättelser, undersöker och testar sina informationssystem och övervakar tidigare förändringar. I praktiken handlar det om flera källor samtidigt:
- regelbunden sårbarhetsskanning av interna och externa system
- bevakning av leverantörers säkerhetsmeddelanden och nationella varningar
- penetrationstester av kritiska system, i den takt riskerna motiverar
- granskning av konfigurationer efter ändringar
- en kanal där medarbetare, kunder och externa forskare kan rapportera brister
Den sista punkten kopplar till direktivets krav på offentliggörande. Ha en tydlig väg för den som hittar en brist hos er och en rutin för hur rapporten tas om hand.
3. Bedöm och prioritera
Här skiljer sig en mogen process från en omogen. En teknisk allvarlighetsgrad, till exempel en CVSS-poäng, säger hur farlig en sårbarhet kan vara i allmänhet. Den säger inget om vad den betyder för just din verksamhet. Väg därför samman:
- Teknisk allvarlighetsgrad: hur svår sårbarheten är att utnyttja och vad den ger en angripare.
- Exponering: är systemet nåbart från internet, från andra nät eller bara lokalt?
- Aktivt utnyttjande: finns det uppgifter om att sårbarheten redan utnyttjas?
- Verksamhetspåverkan: vad händer med tjänsten, informationen och kunderna om sårbarheten utnyttjas?
För att bedöma verksamhetspåverkan kan du låna logiken från incidentföreskrifterna. Där anges att ekonomisk skada vid bedömning av betydande incidenter omfattar bland annat kostnader för återställning, utbyte av system, externa experttjänster och uteblivna intäkter. Samma faktorer fungerar bra som underlag när ni ska avgöra hur bråttom en åtgärd är.
Exempel på en intern prioriteringsmodell (tidsramarna är exempel som ledningen själv behöver besluta om, inte lagkrav):
| Prioritet | Typisk situation | Exempel på tidsram för åtgärd |
|---|---|---|
| Akut | Aktivt utnyttjad sårbarhet i internetexponerat, kritiskt system | Inom dygn |
| Hög | Allvarlig sårbarhet i kritiskt system, begränsad exponering | Inom ett par veckor |
| Medel | Allvarlig sårbarhet i icke-kritiskt system | Nästa planerade underhållsfönster |
| Låg | Låg allvarlighetsgrad, ingen exponering | Vid ordinarie uppdatering eller riskaccept |
Det viktiga är inte exakt vilka tidsramar ni väljer. Det viktiga är att de är beslutade, motiverade utifrån er riskbedömning och följs upp.
4. Åtgärda
Den vanligaste åtgärden är att uppdatera eller patcha. Andra alternativ är konfigurationsändringar, att stänga av tjänster som inte behövs eller att byta ut komponenter. Alla ingrepp i produktionsmiljön är förändringar, och MSB har konstaterat att felaktigt hanterade förändringar ökar risken för incidenter. Därför bör patchning gå via en dokumenterad ändringshantering med test, riskbedömning och möjlighet att backa.
5. Hantera det som inte kan patchas
I många verksamheter finns system som inte kan uppdateras: leverantören har slutat ge support, uppdateringen kräver ett produktionsstopp eller systemet är certifierat i ett visst utförande. Då ska risken ändå hanteras, genom kompenserande åtgärder:
- separera systemet från övriga nät och bygg in det i en skyddad zon, det som MSB kallar en safety box för äldre system
- begränsa vilka som kan nå systemet och från vilka nät
- inför stark autentisering där det är tekniskt möjligt
- utöka loggning och övervakning runt systemet
- dokumentera ett formellt riskaccept med ägare, motivering och datum för omprövning
Ett riskaccept utan slutdatum och utan namngiven beslutsfattare är i praktiken ett glömt problem.
6. Verifiera och följ upp
En åtgärd är inte klar förrän den är verifierad. Skanna om, kontrollera versionsnummer eller testa att sårbarheten faktiskt är stängd. Följ sedan upp på aggregerad nivå. NCSC betonar att verksamheten ska följa upp och utvärdera säkerhetsåtgärderna. Lämpliga mått för ledningsrapporteringen är:
- antal öppna sårbarheter per prioritetsnivå
- andel åtgärdade inom beslutad tidsram
- antal aktiva riskaccept och hur många som passerat omprövningsdatum
- trend över tid för kritiska system
Leverantörer, molntjänster och öppen källkod
En betydande del av dina sårbarheter finns i kod och tjänster som du inte själv utvecklar. NCSC framhåller att leveranskedjan, inklusive molntjänster och öppen källkod, i praktiken är en del av organisationens egen attackyta. De rekommenderar att beroenden av öppen källkod hanteras aktivt, till exempel genom att kartlägga komponenter i en SBOM och bevaka kända sårbarheter i paketen.
Avtalen är nästa nivå. Enligt MCF:s allmänna råd bör avtal reglera att leverantörer kontrollerar hård- och mjukvara för skadlig kod och andra brister samt informerar om hot, sårbarheter och hur risker från underleverantörer hanteras. Konkret innebär det att avtalet bör innehålla:
- skyldighet att meddela kända sårbarheter inom en avtalad tid
- hur och när säkerhetsuppdateringar levereras, och hur länge produkten får support
- rätt att begära en SBOM eller motsvarande komponentförteckning
- krav på hur leverantören i sin tur ställer krav på sina underleverantörer
En svag länk hos en leverantör blir snabbt din egen incident. Vi går igenom avtalsdelen mer utförligt i guiden om NIS2-krav på leverantörskedjan och i vår plan för att hantera tredjepartsrisk på 90 dagar.
OT och äldre system
I industri, energi, vatten och transport finns ofta styrsystem som har varit i drift i decennier. NCSC:s råd för OT-miljöer utgår från en realistisk hållning: OT-relaterade enheter bör betraktas som icke uppdaterade och sårbara och skyddas utifrån det. Det innebär begränsade anslutningar mellan IT och OT och stark autentisering där det är möjligt.
NCSC pekar också på loggningen. Äldre OT-enheter loggar ofta dåligt eller inte alls, och då bör bristen kompenseras med utökad loggning i närliggande system, till exempel brandväggar, hoppservrar och nätverksövervakning.
För sårbarhetshanteringen i OT betyder det i praktiken:
- Var försiktig med aktiv skanning. Den kan störa känsliga styrsystem. Passiv övervakning och inventering via leverantörsdokumentation är ofta säkrare.
- Planera patchning tillsammans med driften. Uppdateringar läggs i planerade stopp och testas i en referensmiljö när det är möjligt.
- Låt nätverksskyddet bära en större del av risken. Segmentering och kontrollerade övergångar mellan IT och OT är ofta den mest effektiva åtgärden.
När en sårbarhet blir en incident
En sårbarhet som utnyttjas är inte längre bara en sårbarhet. Då gäller reglerna om incidentrapportering. MCF:s föreskrifter innehåller också begreppet betydande sårbarhet, som definieras med hänvisning till cyberresiliensförordningen som en sårbarhet som har inneburit en betydande cybersäkerhetsrisk.
Se till att processen har en tydlig övergång: om en skanning, ett larm eller ett leverantörsmeddelande visar att en sårbarhet har utnyttjats ska ärendet direkt gå över till incidenthanteringen, med de tidsfrister som gäller där. Vår guide till NIS2-incidentrapportering går igenom bedömning och rapporteringsflöde.
Dokumentation som visar efterlevnad
Vid en tillsyn räcker det inte att säga att ni patchar regelbundet. Du behöver kunna visa underlag. Följande dokumentation brukar utgöra stommen:
| Dokument | Innehåll | Ägare |
|---|---|---|
| Policy eller riktlinje för sårbarhetshantering | Omfattning, roller, prioriteringsmodell och tidsramar | CISO, fastställd av ledningen |
| Tillgångsförteckning | System, ägare, kritikalitet och exponering | IT och systemägare |
| Sårbarhetslogg | Upptäckt, bedömning, beslut, åtgärd och verifiering per ärende | Säkerhetsfunktionen |
| Riskaccept | Motivering, kompenserande åtgärder och omprövningsdatum | Beslutsfattare med mandat |
| Ändringslogg | Patchar och konfigurationsändringar med test och godkännande | IT-drift |
| Leverantörsunderlag | Avtalskrav, säkerhetsmeddelanden och SBOM | Inköp och juridik |
| Ledningsrapport | Mått, trender och avvikelser, med ledningens beslut | CISO till ledningen |
Spårbarheten är det viktiga: från upptäckt till beslut till verifierad åtgärd, med datum och ansvarig i varje led.
Vanliga misstag
- Skanning förväxlas med hantering. En rapport med tusentals fynd som ingen prioriterar visar snarare att processen saknas.
- Allt prioriteras efter CVSS. Utan koppling till verksamhetens kritiska tjänster läggs resurserna på fel saker.
- Riskaccept saknar slutdatum. Undantag som aldrig omprövas blir permanenta.
- Leverantörerna lämnas utanför. Molntjänster och inbyggda komponenter syns inte i den egna skanningen.
- Ledningen får bara en siffra. Rapporteringen behöver ge beslutsunderlag, inte bara statistik.
Så ser vi på sårbarhetshantering under NIS2
Vi möter ofta organisationer som har bra tekniska verktyg för att hitta sårbarheter men svårt att visa hur besluten fattas. Skanningen sköts av IT, riskacceptet ligger i ett mejl, leverantörskraven finns i ett avtal hos inköp och ledningen får en kvartalsrapport i ett kalkylark. Var för sig fungerar delarna. Tillsammans går de inte att följa.
Vår erfarenhet är att sårbarhetshantering under NIS2 till lika stor del är en styrningsfråga som en teknisk fråga. Lagen frågar inte efter ett visst verktyg. Den frågar om arbetet är riskbaserat, om ansvar är fördelat och om ni följer upp. Därför rekommenderar vi att ni samlar policyn, riskbedömningarna, besluten, leverantörsbedömningarna och uppföljningen på ett ställe, med tydliga ägare och påminnelser. De tekniska verktygen gör sitt jobb, men det är kopplingen till risk och ansvar som gör arbetet möjligt att försvara.
Vi rekommenderar också att juridik och säkerhet arbetar ihop från början. Leverantörsavtalen, definitionerna i föreskrifterna och gränsen mellan sårbarhet och rapporteringspliktig incident är juridiska frågor lika mycket som tekniska.
— Jesper
Samla sårbarhetsarbetet i en plattform
Trustview är en svenskutvecklad plattform för compliance och informationssäkerhet, byggd av jurister. I plattformen hanterar du riskbedömningar, incidentloggning, leverantörsbedömningar, delegering av ansvar och uppföljning av åtgärder. Du får också en realtidsöversikt över efterlevnaden och automatiska rapporter till ledningen. Plattformen stödjer NIS2, ISO 27000-serien, GDPR och AI-förordningen, och du kan bygga egna ramverk. Behöver du stöd i tolkningen kan du lägga till juridisk rådgivning. Se priser och kom igång, från 2 500 kr per månad, eller läs mer om NIS2-efterlevnad i Trustview.
Vanliga frågor
Kräver NIS2 att vi patchar inom en viss tid?
Lagen anger inga generella tidsfrister för patchning. Kravet är att åtgärderna ska vara riskbaserade och följas upp. Ledningen behöver därför själv besluta om tidsramar utifrån er riskbedömning och kunna motivera dem.
Räcker det med en sårbarhetsskanner för att uppfylla kraven?
Nej. En skanner hjälper er att identifiera sårbarheter, men kraven omfattar också prioritering, åtgärd, verifiering, leverantörer och ledningens uppföljning. Ni behöver dokumentation som visar hela kedjan från upptäckt till verifierad åtgärd.
Hur hanterar vi system som leverantören inte längre uppdaterar?
Skydda systemet med kompenserande åtgärder: separera det från övriga nät, begränsa åtkomsten och utöka loggningen runt det. Dokumentera ett riskaccept med ansvarig beslutsfattare och ett datum för omprövning, och planera en ersättning.
Ska leverantörernas sårbarheter ingå i vår process?
Ja. Leveranskedjan, molntjänster och öppen källkod räknas i praktiken till er attackyta. Ställ krav i avtalen på att leverantören informerar om sårbarheter och levererar uppdateringar, och bevaka komponenterna i era system, gärna med hjälp av en SBOM.
Hur hänger sårbarhetshantering ihop med ISO 27001?
ISO 27001 och den tillhörande vägledningen i ISO 27002 innehåller åtgärder för hantering av tekniska sårbarheter som ligger nära NIS2-kraven. Har ni redan ett ledningssystem enligt standarden kan ni bygga vidare på det. Läs mer om vårt verktyg för ISO 27001.
Källor
- NCSC: Säkerhetsåtgärder enligt cybersäkerhetslagen
- Energimyndigheten: Cybersäkerhetslagen, vanliga frågor och svar
- MSB: Threats and opportunities in change management
- MCFFS 2026:8, föreskrifter om incidentrapportering (NCSC)
- MCFFS 2026:8 (MCF)
- MCFFS 2026:11, föreskrifter och allmänna råd om säkerhetsåtgärder
- NCSC: Fördjupade råd och rekommendationer för skydd av OT-miljöer
- NCSC: Skydd mot AI-förstärkta angrepp
