Gå till innehållet
Legiscope
Meny
Cybersäkerhet

NIS2 i Sverige: cybersäkerhetslagen och kraven 2026

Sveriges cybersäkerhetslag gäller sedan januari 2026. Läs vilka verksamheter som omfattas, hur incidenter rapporteras och vad ledningen behöver göra.

Cybersäkerhetslagen (2025:1506) gäller sedan den 15 januari 2026. Den genomför delar av NIS2-direktivet i Sverige och ställer krav på riskhantering, incidentrapportering och ledningens utbildning hos verksamheter som omfattas. Den här guiden hjälper dig att avgöra om lagen berör din organisation och hur du omsätter kraven i en arbetsordning. Utgångspunkten är lagens aktuella lydelse hos riksdagen och den svenska regeringens information om ikraftträdandet.

Det äldre NIS-regelverket upphävdes när lagen trädde i kraft, även om äldre bestämmelser fortfarande gäller för överträdelser som inträffade före dess. EU:s tidsfrist för införande var oktober 2024; förseningen är därför historisk bakgrund, inte en anledning att vänta med efterlevnaden. En verksamhet behöver bedöma svensk lag, relevanta föreskrifter och sin egen sektor. En allmän hänvisning till direktivet räcker inte för att avgöra en viss organisations anmälningsskyldighet eller tillsynsmyndighet.

Börja med att pröva om lagen gäller er

Lagens första kapitel anger vilka privata och offentliga verksamhetsutövare som omfattas. Den vanliga vägen för en privat aktör är att verksamheten finns i någon av direktivets angivna sektorer, är etablerad i Sverige och storleksmässigt motsvarar minst ett medelstort företag. Men det finns viktiga undantag från den förenklade tumregeln: bland annat vissa tillhandahållare av betrodda tjänster, elektronisk kommunikation, domännamn och DNS samt verksamheter som har särskild betydelse för samhällsviktiga funktioner kan omfattas på andra grunder. Vissa digitala aktörers anknytning bedöms också enligt särskilda regler om huvudsakligt etableringsställe eller företrädare.

Gör bedömningen på den juridiska personen och den tjänst som faktiskt tillhandahålls. Ett företag som tillverkar livsmedel och driver en e-handelsplats kan behöva undersöka mer än en sektor. Koncernförhållanden kan påverka storleksbedömningen, och antalet anställda ensamt avgör inte alltid saken. Dokumentera branschklassificering, tjänst, etablering, storlek och eventuella särskilda bestämmelser. Om ni landar i att ni står utanför lagen, notera också varför; bedömningen bör omprövas när verksamheten växer eller tjänsterna ändras.

En liten leverantör kan dessutom vara viktig för en kund som omfattas, även om leverantören själv inte träffas av lagen. Kunden måste hantera risker i leveranskedjan och kan därför kräva säkerhetsinformation, incidentvägar och kontinuitetsåtaganden i avtalet. Det är en avtals- och riskfråga, inte samma sak som att den lilla leverantören automatiskt får egna skyldigheter enligt cybersäkerhetslagen. Den skillnaden gör det lättare att besvara kundförfrågningar utan att felaktigt klassificera verksamheten.

Väsentlig eller viktig verksamhetsutövare?

När tillämpningsområdet är klart ska ni pröva klassificeringen i 1 kap. 9 §. Lagen pekar särskilt ut bland annat statliga myndigheter, vissa större aktörer i bilaga 1-sektorerna, vissa kommuner och regioner, större aktörer inom allmän elektronisk kommunikation, DNS och toppdomänverksamhet samt kvalificerade tillhandahållare av betrodda tjänster som väsentliga. Övriga verksamhetsutövare som omfattas är viktiga. Det är alltså för grovt att kalla alla energiföretag väsentliga eller alla tillverkare viktiga utan att pröva storlek och särskilda rekvisit.

Båda kategorierna måste arbeta med säkerhetsåtgärder och rapportera betydande incidenter. Skillnaden märks bland annat i tillsyn och högsta sanktionsavgift. För vissa tillsynsåtgärder mot viktiga verksamhetsutövare krävs enligt 3 kap. 2 § anledning att anta bristande efterlevnad, medan väsentliga aktörer kan bli föremål för regelbundna säkerhetsrevisioner. Detta betyder inte att viktiga aktörer saknar krav före en incident. De bör kunna visa ett fungerande riskarbete från den dag lagen gäller för dem.

DORA skapar en särskild gränsdragning för finanssektorn. Enligt 1 kap. 11 § gäller inte cybersäkerhetslagens skyldigheter i 2 kap. 3–10 §§ för verksamhetsutövare som omfattas av DORA. Ta därför inte för givet att en bank behöver parallella och identiska åtgärds- och incidentprocesser enligt båda regelverken. Kontrollera vilken verksamhet som omfattas av DORA:s regler om digital operativ motståndskraft och hur koncernens olika enheter och tjänster är organiserade. Den svenska guiden om DORA-stöd ger vidare orientering, men rättskällorna avgör skyldigheterna.

Anmäl verksamheten och hitta rätt myndighet

Den som omfattas ska enligt 2 kap. 2 § anmäla sin verksamhet så snart det kan ske till den myndighet regeringen bestämmer. Ändrade uppgifter ska anmälas så snart som möjligt, dock senast 14 dagar efter förändringen. Börja därför med att identifiera vilka uppgifter som krävs, vem som ansvarar för dem och hur ni följer upp nya tjänster, organisationsnummer eller kontaktpersoner. Ett internt register över verksamhetens sektorer och kontaktvägar är användbart även för incidenthantering.

Skriv inte rutintexten med en föråldrad myndighetsförkortning. MSB blev Myndigheten för civilt försvar (MCF) den 1 januari 2026. Från den 1 juli 2026 fördes cybersäkerhetsuppgifter till Nationellt cybersäkerhetscenter vid FRA, vilket MCF beskriver i sin aktuella vägledning. Lagtexten använder ofta formuleringen ”den myndighet som regeringen bestämmer”; de konkreta mottagarna och tillsynsmyndigheterna följer också av förordningar och föreskrifter. Kontrollera därför aktuell rapporteringskanal för just er sektor innan ett skarpt ärende inträffar.

Utse en intern ägare för anmälan och en ersättare. Registrera hur kvittens sparas och när uppgifterna senast granskades. Detta är inte administrativt finlir: om organisationen står registrerad med gamla kontaktuppgifter kan en myndighetsförfrågan eller krisvarning nå fel person. Samma ägare bör delta när incidentrutinen övas så att juridisk klassificering och teknisk kontaktkedja fungerar tillsammans.

Riskhantering som går att visa i drift

Enligt 2 kap. 3 § ska verksamhetsutövaren vidta lämpliga och proportionella tekniska, operativa och organisatoriska åtgärder. Lagen nämner bland annat riskanalys, incidenthantering, kontinuitet och krishantering, säkerhet i leveranskedjan, säker anskaffning och utveckling, metoder för att bedöma åtgärders effektivitet, utbildning, kryptografi, personalsäkerhet och åtkomstkontroll. Det är en helhet av beslut, genomförande och kontroll. En policy utan uppföljning uppfyller inte syftet; enskilda tekniska kontroller utan ansvar och återställningsförmåga gör det inte heller.

Kartlägg de nät- och informationssystem som tjänsten faktiskt beror på. Rita även in identitetsleverantör, driftpartner, betalnings- eller logistiksystem och den personal som behövs för att återställa dem. Bedöm hot och sårbarheter tillsammans med konsekvenser för tjänstens tillgänglighet, riktighet och konfidentialitet. Prioritera sådant som kan avbryta leveransen under lång tid eller ge omfattande följdskador. Följ upp beslut med ägare, tidsfrist och en kontroll som visar om åtgärden fungerar. Den metoden ger ledningen något konkret att godkänna och övervaka.

En informationssäkerhetspolicy med tydliga ansvar kan samla ramarna, medan en grundläggande plan för it-säkerhet hjälper teamet ordna åtkomst, uppdateringar och övervakning i drift. Anpassa båda till de tjänster som lagen faktiskt träffar. En kopierad mall som saknar systemägare eller uppföljning visar inte att riskerna hanteras.

Leveranskedjan kräver mer än ett frågeformulär till leverantören. Klargör vilka underleverantörer som får tillgång till kritiska system, vilka beroenden som saknar alternativ och hur snabbt ni får besked om en störning. Säkerhetskrav i avtal bör kopplas till möjlighet att kontrollera genomförandet, rätt att få relevant incidentinformation och en plan för byte eller reservlösning. Riskens storlek styr detaljerna. En mindre konsult med begränsad åtkomst behöver inte samma kontrollpaket som en leverantör som driftar hela den samhällsviktiga tjänsten.

Kontinuitet ska prövas i praktiken. Bestäm vilka tjänster som måste upprätthållas, hur länge de kan vara nere, hur säkerhetskopior återställs och vem som får besluta om prioriteringar. Öva ett scenario där både primärmiljö och vanliga kommunikationskanaler är påverkade. Anteckna om planerad återhämtningstid uppnåddes och vad som hindrade den. Den återkommande prövningen är ett sätt att bedöma åtgärdernas effektivitet, inte en garanti för att alla incidenter kan förebyggas.

Utgå gärna från en kontinuitetsplan för verksamheten, men testa alltid hela kedjan från teknisk återställning till en användbar tjänst. En server som startar utan behörigheter, personal eller uppdaterade data uppfyller inte automatiskt verksamhetens behov.

Betydande incidenter: tre tidpunkter och ett eget beslut

Rapporteringstrappan i 2 kap. 5–8 §§ gäller betydande incidenter. Lagen definierar betydande genom bland annat allvarlig driftsstörning eller ekonomisk skada för verksamhetsutövaren och betydande skada för andra. Bedömningen kan behöva göras innan alla tekniska fakta är kända. Logga därför när verksamheten fick kännedom om händelsen, vilka tjänster som påverkades, den preliminära konsekvensen och varför incidenten bedömdes rapporteringspliktig eller inte.

Först ska myndigheten upplysas så snart det kan ske, senast 24 timmar efter kännedom. Därefter ska en incidentanmälan lämnas så snart det kan ske och normalt senast 72 timmar efter kännedom. Tillhandahållare av betrodda tjänster har för denna anmälan en 24-timmarsfrist. Slutrapport lämnas senast en månad efter incidentanmälan. Om incidenten fortfarande pågår då ska en lägesrapport lämnas och slutrapporten sedan ges senast en månad efter att incidenten hanterats. Läs hela paragrafkedjan och aktuella föreskrifter när rutinen utformas; en enkel 24/72/30-dagarsrad kan missa både specialfallet och den pågående incidenten.

Den första rapporten behöver inte innehålla en färdig grundorsaksanalys. Den måste däremot vila på de uppgifter som faktiskt finns och uppdateras när bilden ändras. Sätt en intern första eskaleringsgräns som ger teamet tid att bedöma incidenten före lagens yttre frist. Låt tekniker, verksamhetsansvarig, jurist och kommunikationsfunktion arbeta i samma tidslinje. Om leverantören först meddelar er sent behöver ni kunna redovisa när er organisation fick kännedom och vad ni därefter gjorde.

En personuppgiftsincident bedöms dessutom separat enligt GDPR. IMY:s anmälan av personuppgiftsincidenter styrs av risk för fysiska personers rättigheter och friheter och har sin egen 72-timmarsregel. En betydande driftstörning kan sakna personuppgifter; ett läckage kan vara anmälningspliktigt till IMY även om tjänsten fortsätter fungera. En gemensam incidentrutin kan dela fakta och tidslinje men ska ha skilda beslut om respektive regelverks tröskel, mottagare och information till berörda.

Ledningens uppgift och möjliga ingripanden

Ledningen behöver förstå vilka risker som följer av verksamhetens tjänster, godkänna riskhanteringsåtgärder och följa upp om de genomförs. Lagens 2 kap. 4 § säger uttryckligen att personer i ledningen ska genomgå utbildning om säkerhetsåtgärder. Gör utbildningen relevant för beslut: vilka beroenden hotar leveransen, vilken risk accepteras, hur ofta får ledningen information och vem får begära extra resurser? En kort övning med beslut om återställningsordning kan vara mer lärorik än en generell presentationsbild.

Sanktionerna är övre gränser, inte normala bötesbelopp. För en privat väsentlig verksamhetsutövare är taket enligt 4 kap. 10 § det högsta av 2 procent av global årsomsättning eller motsvarande 10 miljoner euro. För en privat viktig verksamhetsutövare är det högsta av 1,4 procent eller 7 miljoner euro; för en offentlig verksamhetsutövare anger lagen ett särskilt kronbelopp. Tillsynsmyndigheten ska bedöma överträdelsens allvar och andra omständigheter. Vid vissa allvarliga överträdelser finns också möjlighet att ansöka hos domstol om ett tidsbegränsat förbud att inneha ledningsfunktion. Det är inte ett automatiskt personligt bötesansvar för varje styrelseledamot.

En bra ledningsrapport skiljer mellan kvarstående risk och färdigt arbete. Visa exempelvis andelen kritiska system med testad återställning, antal leverantörsberoenden utan reservlösning och hur länge tidigare incidenter låg oupptäckta. Lägg fram beslut som kräver mandat: finansiering, accepterat avbrott, val av leverantör eller förändrat tjänsteutbud. Protokollför beslut och uppföljning. Det gör ansvarsfördelningen begriplig även när ledamöter, leverantörer eller tekniken byts ut.

Förhållandet till GDPR och andra säkerhetskrav

NIS2 skyddar nät- och informationssystem och de tjänster samhället är beroende av. GDPR skyddar människor när deras personuppgifter behandlas. Kraven överlappar i åtkomstkontroll, säkerhet och incidenthantering men har olika trösklar. En registerförteckning enligt GDPR kan hjälpa er identifiera vissa datasystem; den är inte ett register över alla NIS2-kritiska resurser. Ett personuppgiftsbiträdesavtal reglerar behandling för annans räkning, medan NIS2-arbetet också omfattar leverantörer som inte är biträden.

Undvik därför att beskriva en leverantör som personuppgiftsbiträde enbart för att den levererar en viktig tjänst. Roller bestäms av vem som bestämmer ändamål och medel för en behandling; skillnaden mellan ansvarig och biträde kan behöva analyseras separat. Samordna där det finns gemensamma fakta, men behåll rättsliga beslut för varje regelverk. För organisationer som använder ett särskilt NIS2-arbetsstöd i Sverige är det särskilt viktigt att tillämpningsområde, ägare och myndighetsvägar uppdateras efter den svenska lagen.

En genomförbar arbetsordning

Börja med ett dokumenterat tillämpningsbeslut enligt lagens första kapitel. Bekräfta sedan om organisationen är väsentlig eller viktig, vem som är behörig tillsynsmyndighet och hur anmälan görs. Lägg därefter fram en lista över tjänster, kritiska system och leverantörer för ledningen. Inventera befintliga riskanalyser och övningar; använd dem där de faktiskt täcker den nya tjänstebilden. Ta fram en åtgärdsplan med ansvariga, resurser och kontrollpunkter.

Öva incidentkedjan innan nästa incident. Låt ett scenario starta hos en leverantör och följ det genom upptäckt, verksamhetsbedömning, tidig varning, incidentanmälan, kommunikation och slutrapport. Lägg samtidigt in ett personuppgiftsmoment och pröva om teamet kan fatta två separata anmälningsbeslut. Notera var kontaktnamn, behörigheter eller underlag saknas. Åtgärda de luckorna först. Planera sedan regelbundna omprövningar efter ändringar i verksamhet, hotbild eller föreskrifter.

Vanliga frågor

När trädde NIS2 i kraft i Sverige?

Den svenska cybersäkerhetslagen trädde i kraft den 15 januari 2026. EU-direktivets införandefrist låg tidigare, men den nu gällande svenska lagtexten är utgångspunkt för nationella skyldigheter. Särskilda föreskrifter och ansvarsfördelning bör kontrolleras i sin aktuella lydelse.

Gäller lagen alla företag med minst 50 anställda?

Nej. Sektor, tjänst, etablering och storlek måste prövas tillsammans, och vissa särskilda aktörer omfattas oavsett den vanliga storleksregeln. Vissa finansiella verksamheter har DORA som särskilt regelverk. Ett kort, skriftligt tillämpningsbeslut är bättre än en generell storleksetikett.

Ska varje säkerhetshändelse rapporteras inom 24 timmar?

Nej. Tidsfristen för tidig varning avser en betydande incident enligt lagens kriterier. Andra händelser behöver ändå hanteras och dokumenteras internt; de kan utlösa skyldigheter enligt exempelvis GDPR eller avtal. För betydande incidenter gäller dessutom senare rapporter och ett särskilt 24-timmarsfall för tillhandahållare av betrodda tjänster.

Vem tar emot rapporten efter MSB:s namnbyte?

Lagen hänvisar till den myndighet regeringen bestämmer. MSB bytte namn till MCF vid årsskiftet, och vissa cybersäkerhetsuppgifter flyttades därefter till NCSC vid FRA. Kontrollera den aktuella sektorspecifika myndigheten och rapporteringskanalen innan rutinen fastställs; använd inte automatiskt en äldre MSB-adress.

Räcker vårt GDPR-program?

Det är en användbar start för säkerhet och incidenthantering, men NIS2 omfattar även kontinuitet, leveranskedja och risker för tjänster som inte behandlar personuppgifter. Jämför därför existerande kontroller mot cybersäkerhetslagens egna krav och dokumentera luckorna.

L
Skriven av
Legiscope
Legiscope

Omsätt vägledningen i praktiken

Se hur Legiscope kopplar samman integritetsregister, källmaterial och granskningsstyrt arbete.

Boka en anpassad demo
Fortsätt läsa

Relaterade artiklar

01Cybersäkerhet

DORA-programvara 2026: guide för finanssektorn i Sverige

DORA-programvara kan hjälpa ett svenskt finansföretag att hålla ihop risker, IKT-tjänster, avtal, incidenter och åtgärder. Värdet ligger i att informationen går att använda när ett system slutar…

4 juli 2026
02Cybersäkerhet

DORA: informationsregister (mall och guide)

Informationsregistret enligt artikel 28.3 i DORA är den strukturerade förteckningen över samtliga avtal om IKT-tjänster som tillhandahålls av tredjepartsleverantörer. Det följer bindande mallar i…

29 juli 2026
03Cybersäkerhet

DORA: komplett guide för finansiella entiteter

DORA — förordning (EU) 2022/2554 — ålägger samtliga finansiella entiteter i EU ett gemensamt ramverk för digital operativ motståndskraft, tillämpligt sedan den 17 januari 2025. Förordningen vilar på…

29 juli 2026
04Cybersäkerhet

NIS2 compliance-programvara 2026: guide för svenska företag

NIS2 compliance-programvara hjälper svenska organisationer att uppfylla kraven i NIS2-direktivet (direktiv (EU) 2022/2555): riskhantering, incidentrapportering inom fastställda frister, styrning på…

4 juli 2026
05Dataskydd

Allmän handling och GDPR: pröva utlämnande och säker leverans

En begäran om en allmän handling ska inte avslås bara för att handlingen innehåller personuppgifter. Myndigheten behöver identifiera handlingen, bedöma om den är allmän, pröva eventuell sekretess och…

8 september 2026
06Dataskydd

Ändamålsbegränsning: pröva ny användning av personuppgifter

”Vi har redan uppgifterna” är inte ett tillräckligt skäl för att använda dem i ett nytt projekt. Kunduppgifter som samlats in för support kan vara praktiskt användbara för försäljning, produktanalys…

8 september 2026
07Dataskydd

Anmäla personuppgiftsincident till IMY: 72-timmarsregeln

En personuppgiftsincident ska anmälas till behörig tillsynsmyndighet utan onödigt dröjsmål och, om möjligt, senast 72 timmar efter att den personuppgiftsansvariga fått vetskap om den. Undantaget…

7 juli 2026
08Dataskydd

Anonymisering: bedöm identifierbarhet före delning

Att anonymisera personuppgifter innebär mer än att ta bort namn och personnummer. En kombination av ort, tid, befattning och ovanliga händelser kan räcka för att någon ska kunna identifieras. Bedöm…

8 september 2026