NIS2-incidentrapportering innebär att organisationer som omfattas av NIS2-direktivet är skyldiga att anmäla allvarliga cybersäkerhetsincidenter till behörig myndighet.
Syftet är tvåfaldigt: myndigheterna ska snabbt kunna koordinera hjälp och begränsa spridning, och hotinformation ska kunna delas sektorsövergripande så att andra organisationer kan skydda sig mot samma angrepp.
Skyldigheten blir verklighet den 15 januari 2026 när Sveriges Cybersäkerhetslag träder i kraft. Rapporteringskraven följer ett strikt tidsschema: 24 timmar, 72 timmar och 1 månad. Att missa dessa deadlines kan leda till höga böter och i värsta fall personligt ansvar för ledningen.
Den här artikeln går igenom vad som räknas som en rapporteringspliktig incident, exakt vad varje rapport ska innehålla, vem ni rapporterar till – och hur ni förbereder organisationen praktiskt.
Vad är en signifikant incident enligt NIS2?
Inte varje IT-problem kräver rapportering till myndigheterna. NIS2 fokuserar på allvarliga incidenter, alltså händelser som kraftigt påverkar verksamheten eller andra.
En incident räknas som allvarlig om den:
- Orsakar allvarlig driftstörning som hindrar er från att leverera kritiska tjänster
- Leder till betydande ekonomisk förlust för er organisation
- Skadar andra personer eller organisationer genom er verksamhet
- Har potential för spridning och kan påverka andra entiteter eller sektorer
Praktiska exempel på allvarliga incidenter
- Ransomware-attack som krypterar kritiska system och stoppar patientvård
- Dataintrång där kunddata eller känslig affärsinformation stjäls
- DDoS-attack som gör er tjänst otillgänglig i flera timmar
- Kritisk sårbarhet hos leverantör som påverkar era system
- Sabotage eller insider-attack som skadar it-infrastruktur
- Större systemhaveri som påverkar samhällsviktig tjänst
NIS2:s trappstegstidslinje för incidentrapportering
NIS2 använder en tre-stegs modell för rapportering enligt Artikel 23 i NIS2-direktivet. Den balanserar snabb varning med detaljerad analys. Varje steg har olika krav på innehåll och detaljer.
Steg 1: Föranmälan inom 24 timmar
Deadline: Inom 24 timmar från det att ni blev medvetna om incidenten
Till vem: Er sektorsmyndighet eller CSIRT (Computer Security Incident Response Team)
Syfte: Snabb varning för att begränsa spridning och möjliggöra tidig hjälp
Den första föranmälan är medvetet lättviktig och kräver inte djup analys. Fokus ligger på att snabbt varna myndigheterna så att de kan hjälpa er och varna andra organisationer som kan vara utsatta för samma hot. I detta skede är det okej att ha begränsad information – det viktigaste är att ni rapporterar att något har hänt.
Föranmälan ska innehålla:
- Beskrivning av vad som inträffat och när ni upptäckte det
- Om incidenten misstänks vara antagonistisk (t.ex. angrepp, sabotage)
- Om incidenten kan ha gränsöverskridande påverkan
- Initial bedömning av allvarlighetsgrad
Steg 2: Incidentrapport inom 72 timmar
Deadline: Inom 72 timmar från det att ni blev medvetna om incidenten
Syfte: Ge myndigheterna en uppdaterad bild med mer detaljer och konsekvenser
Efter tre dygn förväntas ni ha hunnit göra en initial utredning och kan ge en mer detaljerad bild av incidenten. Nu ska rapporten innehålla information om vad som faktiskt hänt, hur incidenten påverkar er verksamhet, och vilka åtgärder ni vidtagit för att hantera situationen.
Incidentrapporten ska innehålla:
- Uppdaterad beskrivning av incidenten och dess förlopp
- Bedömning av allvarlighetsgrad och verksamhetspåverkan
- Antal drabbade användare, system eller tjänster
- Eventuella indikatorer på intrång (IOC) om tillgängliga
- Vidtagna och pågående åtgärder för att begränsa skadan
Steg 3: Slutrapport inom 1 månad
Deadline: Senast 1 månad efter incidentrapporten (dvs. ca 1 månad + 72 timmar)
Om incidenten pågår: Skicka en lägesrapport efter 1 månad, sedan slutrapport inom 1 månad efter att incidenten är löst
Syfte: Dela lärdomar och fullständig analys för att förbättra sektorns förmåga att motstå hot
Slutrapporten är den mest omfattande och ska innehålla en fullständig analys av incidenten från början till slut. Nu har ni haft tid att genomföra en grundlig utredning, förstå grundorsaken, och dokumentera alla konsekvenser. Detta är det tillfälle där ni delar lärdomar som kan hjälpa andra organisationer att undvika liknande incidenter.
Slutrapporten ska innehålla:
- Fullständig beskrivning av incidentens förlopp från identifiering till avslut
- Fastställd eller trolig grundorsak
- Fullständig konsekvensanalys – teknisk, operationell och ekonomisk påverkan
- Alla vidtagna åtgärder och deras effekt
- Lärdomar och planerade förbättringar för att förhindra upprepning
Särskilt snabbare krav för betrodda tjänsteleverantörer
Om ni är betrodd tjänsteleverantör (t.ex. certifieringstjänster, e-signatur, tidsstämpling) gäller ännu snabbare deadlines i Sverige:
- Steg 2-rapporten måste lämnas inom 24 timmar (inte 72)
- Detta beror på den kritiska roll dessa tjänster har för digitalt förtroende
Vem kontaktar ni för NIS2 incidentrapportering?
I Sverige är ansvaret för NIS2-tillsyn uppdelat mellan flera myndigheter beroende på sektor. Myndigheten för civilt försvar (MCF) samordnar implementeringen av NIS2 i Sverige.
Sektorsmyndigheter:
- Energimarknadsinspektionen - energisektor
- Post- och telestyrelsen (PTS) - digitala tjänster och telekom
- Transportstyrelsen - transport
- Finansinspektionen - finans och bank
- E-hälsomyndigheten - hälso- och sjukvård
- Livsmedelsverket - livsmedelsproduktion
Tänk på att:
- Kontrollera vilken myndighet som ansvarar för er sektor
- Registrera er organisation hos rätt myndighet
- Spara kontaktuppgifter för snabb rapportering
Skillnad mellan NIS2 incidentrapportering och GDPR
Många organisationer måste rapportera enligt både NIS2 och GDPR. Här är skillnaderna:
| Aspekt | NIS2 | GDPR |
|---|---|---|
| Vad rapporteras | Signifikanta IT-säkerhetsincidenter | Personuppgiftsincidenter |
| Till vem | Sektorsmyndighet/CSIRT | Datainspektionen (IMY) |
| Tidsgräns | 24h, 72h, 1 månad | 72h till myndighet, utan dröjsmål till registrerade |
| Omfattning | Verksamhetspåverkan, säkerhet | Personuppgiftshantering |
| Böter | Upp till 2% av omsättning | Upp till 4% av omsättning |
Viktigt: En incident kan kräva rapportering enligt båda regelverken. Exempel:
- Dataintrång där kunddata stjäls = GDPR + NIS2
- Ransomware som krypterar personuppgifter = GDPR + NIS2
Hur förbereder ni organisationen praktiskt?
En fungerande incidentrapporteringsprocess byggs innan incidenten inträffar. Organisationer som saknar förberedda rutiner riskerar att missa 24-timmarsfristen i kaoset som följer ett angrepp.
Intern rapportering till ledningen
NIS2 kräver inte bara extern rapportering till myndigheter – ledningsorgan (styrelse och VD) ska löpande informeras om incidenter och deras hantering. Det innebär att ni behöver interna eskaleringsvägar som aktiveras parallellt med den externa rapporteringen.
Checklista för förberedelse:
- Utse ett incidenthanteringsteam med tydliga roller och ansvar
- Ta fram färdiga rapportmallar för varje steg (24h, 72h, 1 månad)
- Spara kontaktuppgifter till er sektorsmyndighet och CSIRT lättillgängligt
- Klargör i leverantörsavtal att leverantören är skyldig att omedelbart rapportera incidenter till er
- Öva med tabletop-övningar så att teamet vet vad som ska göras när larmet går
- Bygg en gemensam process som täcker både NIS2 och GDPR om ni hanterar personuppgifter
Vanliga frågor om NIS2-incidentrapportering
Vad händer om vi missar 24-timmarsfristen?
Att missa rapporteringsfristen kan leda till böter och i värsta fall personligt ansvar för ledningen. Myndigheterna bedömer varje fall individuellt. Det viktigaste är att aldrig helt undvika att rapportera - sent är bättre än aldrig.
Måste vi rapportera incidenter hos våra leverantörer?
Ja, om leverantörsincidenten påverkar era kritiska system kan den behöva rapporteras. Se till att era leverantörsavtal kräver att leverantören informerar er omedelbart om incidenter.
Kan samma incident kräva rapportering enligt både NIS2 och GDPR?
Ja. Om incidenten involverar personuppgifter kan ni behöva rapportera enligt båda regelverken. Bygg en gemensam incidenthanteringsprocess som täcker båda kraven.
