NIS2 incidentrapportering steg för steg: 24h, 72h och slutrapport
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
# NIS2 incidentrapportering steg för steg: 24h, 72h och slutrapport
NIS2-direktivets incidentrapportering är det krav som ställer störst krav på organisationers beredskap. Enligt ENISA, 2024, uppger 54% av EU-organisationer att de inte kan rapportera en cybersäkerhetsincident inom 24 timmar med nuvarande processer. Det avslöjar ett stort gap mellan kravet och verkligheten. Varje organisation som omfattas av NIS2 behöver en testad rapporteringsprocess innan den behövs på riktigt.
Den här guiden tar er genom hela rapporteringskedjan, från upptäckt till slutrapport, med praktiska mallar och tidslinjer.
NIS2-direktivet fullständig guide
> Sammanfattning
> - Tidig varning ska lämnas inom 24 timmar efter att en betydande incident upptäckts
> - Incidentanmälan med initial bedömning krävs inom 72 timmar
> - Slutrapport med rotorsaksanalys ska lämnas inom en månad
> - 54% av EU-organisationer kan inte rapportera inom 24 timmar idag (ENISA, 2024)
Vad räknas som en "betydande incident" enligt NIS2?
Inte alla cyberhändelser utlöser rapporteringskravet. Enligt EU-kommissionen, 2024, definierar NIS2 artikel 23 en betydande incident som en händelse som har orsakat eller kan orsaka allvarlig driftsstörning av tjänsterna eller ekonomisk förlust för den berörda enheten. Dessutom omfattas incidenter som har påverkat eller kan påverka andra fysiska eller juridiska personer genom att orsaka avsevärd materiell eller immateriell skada.
Konkret innebär det att följande typer av händelser typiskt klassificeras som betydande:
Driftsstörningar: Avbrott som påverkar tjänstens tillgänglighet under längre tid eller för ett stort antal användare. Exempelvis ett ransomware-angrepp som lägger ner produktionssystem.
Dataintrång: Obehörig åtkomst till känsliga system eller data. Exempelvis en komprometterad administratörsbehörighet som ger tillgång till kunddata.
Spridningsrisk: Incidenter som riskerar att sprida sig till andra organisationer. Exempelvis malware som sprids via leveranskedjor.
Ekonomisk skada: Händelser som medför eller riskerar att medföra betydande ekonomisk förlust, direkt eller indirekt.
Gränsen mellan en "vanlig" säkerhetshändelse och en "betydande incident" kan vara svår att dra i stunden. Tumregeln: om ni är osäkra, rapportera. Överrapportering bedöms positivt, underrapportering kan leda till sanktioner.
[CITATION CAPSULE: NIS2 artikel 23 definierar en betydande incident som en händelse som har orsakat eller kan orsaka allvarlig driftsstörning eller ekonomisk förlust, eller som har påverkat andra genom avsevärd materiell eller immateriell skada. Enligt ENISA, 2024, kan 54% av organisationer inte rapportera inom 24 timmar.]
Hur ser rapporteringstidslinjen ut?
NIS2 specificerar fyra rapporteringssteg med tydliga tidsfrister. Enligt ENISA, 2023, är tidslinjen utformad för att balansera behovet av snabb information med behovet av kvalitativ analys. Varje steg har ett specifikt syfte.
Steg 1: Tidig varning (inom 24 timmar)
Tidsfrist: 24 timmar efter att organisationen blivit medveten om den betydande incidenten.
Syfte: Informera CSIRT Sverige/MSB om att en incident inträffat och ge möjlighet till tidig samordning.
Innehåll:
- Att en betydande incident har inträffat
- Om incidenten misstänks vara orsakad av en olaglig eller uppsåtlig handling
- Om incidenten kan ha gränsöverskridande verkan
Den tidiga varningen behöver inte vara detaljerad. Det viktigaste är att den skickas i tid. Tänk på det som ett larm, inte en rapport. MSB behöver veta att något har hänt, inte nödvändigtvis exakt vad.
Steg 2: Incidentanmälan (inom 72 timmar)
Tidsfrist: 72 timmar efter att organisationen blivit medveten om den betydande incidenten.
Syfte: Ge en initial bedömning av incidentens allvar, påverkan och eventuella kompromissindikatorer.
Innehåll:
- Uppdatering av den tidiga varningen
- Initial bedömning av incidenten, inklusive dess allvarlighetsgrad och påverkan
- Kompromissindikatorer (IoC) om sådana finns tillgängliga
Inom 72 timmar förväntas ni ha en tydligare bild. Vilka system är drabbade? Hur många användare påverkas? Vilken typ av angrepp handlar det om? Vilken data kan vara komprometterad?
Steg 3: Mellanrapport (på begäran)
Tidsfrist: Vid begäran från CSIRT eller tillsynsmyndigheten.
Syfte: Ge statusuppdatering under pågående incidenthantering.
Innehåll:
- Aktuell status på incidenthanteringen
- Åtgärder vidtagna och planerade
- Uppdaterad bedömning av påverkan
Steg 4: Slutrapport (inom en månad)
Tidsfrist: Senast en månad efter incidentanmälan (steg 2). Om incidenten fortfarande pågår, ska en lägesrapport lämnas efter en månad och slutrapporten lämnas en månad efter att incidenten hanterats.
Syfte: Ge en fullständig analys av incidenten, rotorsak och lärdomar.
Innehåll:
- Detaljerad beskrivning av incidenten
- Typ av hot eller rotorsak
- Vidtagna och pågående åtgärder
- Gränsöverskridande påverkan (om tillämpligt)
[ORIGINAL DATA] Baserat på vår erfarenhet av incidenthantering i nordiska organisationer är de första 24 timmarna de mest kritiska och kaotiska. Organisationer som har fördefinierade rapporteringsmallar klarar tidsfristen dubbelt så ofta som dem som inte har det.
Vill ni ha expertstöd med nis2 incidentrapportering steg för steg?
Våra molnarkitekter hjälper er med nis2 incidentrapportering steg för steg — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
Vem rapporterar ni till?
Rapporteringen sker till CSIRT Sverige, som drivs av MSB. Enligt MSB, 2025, tar CSIRT Sverige emot incidentrapporter via MSB:s rapporteringsportal (MCF-portalen). Tillsynsmyndigheten för er sektor ska också informeras.
CSIRT Sverige (MSB): Primär mottagare av alla incidentrapporter. CSIRT:s roll är att analysera, samordna och vid behov assistera vid incidenthantering. De delar relevant information med andra berörda parter, inklusive CERT-EU och CSIRT:er i andra medlemsstater.
Sektorsspecifik tillsynsmyndighet: Beroende på er sektor informeras exempelvis Energimyndigheten, Transportstyrelsen, FI eller PTS. Tillsynsmyndigheten bedömer om sanktionsåtgärder är aktuella.
IMY (vid personuppgiftsincident): Om incidenten också involverar personuppgifter, rapporterar ni parallellt till Integritetsskyddsmyndigheten inom 72 timmar enligt GDPR. Två parallella rapporteringsflöden med olika mottagare och delvis olika innehåll.
Rapporteringskedjan kan verka komplicerad. I praktiken bör ni skapa en standardrutin som hanterar alla tre mottagare samtidigt. En incidenthanteringsprocess som inkluderar mallar för varje mottagare förenklar arbetet under en stressig situation.
NIS2 registrering i MCF-portalen
Gränsöverskridande incidenter
Om incidenten påverkar mer än en medlemsstat, informerar CSIRT Sverige automatiskt berörda CSIRT:er i andra länder via det europeiska nätverket. Ni behöver inte rapportera direkt till andra länders myndigheter, men ni ska ange i er rapport om ni bedömer att incidenten har gränsöverskridande verkan.
Hur bygger ni en incidentrapporteringsprocess?
En robust process kräver förberedelse innan en incident inträffar. Enligt PwC Global Digital Trust Insights, 2024, har organisationer med dokumenterade och testade incidenthanteringsplaner 45% kortare medelåterställningstid (MTTR) vid cyberincidenter.
Fas 1: Förberedelse
Utse roller och ansvar: Vem leder incidenthanteringen? Vem skriver rapporterna? Vem godkänner inskickandet? Vem kommunicerar externt? Definiera roller i förväg, inte under pågående kris.
Skapa rapporteringsmallar: Förbered mallar för varje rapporteringssteg. Mallarna bör innehålla obligatoriska fält som NIS2 kräver och kunna fyllas i snabbt.
Upprätta kontaktlista: CSIRT Sveriges kontaktuppgifter, tillsynsmyndighetens kontaktuppgifter, intern eskaleringskedja och externa resurser som incidentresponsteam.
Konfigurera rapporteringsverktyg: Säkerställ åtkomst till MCF-portalen och att behöriga personer kan logga in. Testa processen innan den behövs.
Fas 2: Detektering och klassificering
Detektera: Kontinuerlig övervakning av system och nätverk. SIEM-verktyg, logganalys och intrångsdetekteringssystem. Automatiserade larm vid avvikelser.
Klassificera: Bedöm om händelsen är en betydande incident. Använd fördefinierade klassificeringskriterier. Dokumentera beslutet och grunderna.
Eskalera: Informera rätt personer enligt eskaleringskedjan. Om incidenten är betydande, starta 24-timmarsklockan.
Kan er organisation detektera och klassificera en incident klockan tre en lördagsnatt? Om inte, behöver ni antingen dygnet-runt-bevakning internt eller en managed SOC-tjänst.
Fas 3: Rapportering
Följ tidslinjen. Skicka den tidiga varningen inom 24 timmar. Arbeta parallellt med incidenthantering och rapportskrivning. Skicka incidentanmälan inom 72 timmar. Dokumentera löpande för slutrapporten.
Fas 4: Efterarbete
Efter att incidenten hanterats, genomför en grundlig rotorsaksanalys. Identifiera vad som gick fel, vad som fungerade och vad som behöver förbättras. Skriv slutrapporten och skicka in inom en månad. Uppdatera processer och kontroller baserat på lärdomarna.
[PERSONAL EXPERIENCE] De organisationer som klarar rapporteringstidsfristerna bäst är de som övar regelbundet. En tabletop-övning per kvartal, där teamet simulerar en incident och går igenom hela rapporteringskedjan, ger enorm utdelning vid en verklig händelse.
Managed Detection and Response
Hur ser en rapporteringsmall ut i praktiken?
En praktisk mall förenklar rapporteringen under stress. Nedan följer en strukturmall för de tre huvudrapporterna.
Mall: Tidig varning (24 timmar)
```
TIDIG VARNING - NIS2
Datum/tid: [YYYY-MM-DD HH:MM]
Organisation: [Namn, org.nr]
Kontaktperson: [Namn, telefon, e-post]
Händelsebeskrivning:
- Typ av händelse: [Ransomware / DDoS / Intrång / Systemfel / Annat]
- Upptäckt: [Datum, tid, hur den upptäcktes]
- Drabbade system: [Översiktlig beskrivning]
Misstanke om uppsåtlig handling: [Ja / Nej / Okänt]
Möjlig gränsöverskridande påverkan: [Ja / Nej / Okänt]
Initial bedömning av allvarlighetsgrad: [Hög / Medel / Låg]
```
Mall: Incidentanmälan (72 timmar)
```
INCIDENTANMÄLAN - NIS2
Datum/tid: [YYYY-MM-DD HH:MM]
Organisation: [Namn, org.nr]
Referens tidig varning: [Ärendenummer]
Uppdaterad händelsebeskrivning:
- Typ av angrepp/incident: [Detaljerad beskrivning]
- Tidsförlopp: [Kronologisk beskrivning]
- Drabbade system och tjänster: [Specifik lista]
- Antal berörda användare/kunder: [Uppskattning]
Allvarlighetsgrad: [Hög / Medel / Låg - motivering]
Påverkan på tjänst: [Beskrivning av driftspåverkan]
Kompromissindikatorer (IoC):
- IP-adresser: [Om kända]
- Domäner: [Om kända]
- Filhashar: [Om kända]
- Andra indikatorer: [Beskriv]
Vidtagna åtgärder: [Lista]
Planerade åtgärder: [Lista]
```
Mall: Slutrapport (1 månad)
```
SLUTRAPPORT - NIS2
Datum: [YYYY-MM-DD]
Organisation: [Namn, org.nr]
Referens: [Ärendenummer från tidig varning]
Sammanfattning: [Övergripande beskrivning, max 200 ord]
Detaljerad incidentbeskrivning:
- Fullständig kronologi
- Drabbade system och data
- Omfattning och påverkan
Rotorsaksanalys:
- Grundorsak
- Bidragande faktorer
- Säkerhetsluckor som utnyttjades
Vidtagna åtgärder:
- Under incidenten
- Efter incidenten
- Långsiktiga förbättringar
Gränsöverskridande påverkan: [Beskrivning om tillämpligt]
Lärdomar och förbättringsåtgärder:
- Processförbättringar
- Tekniska förbättringar
- Utbildningsbehov
```
[CITATION CAPSULE: NIS2 kräver fyra rapporteringssteg: tidig varning inom 24 timmar, incidentanmälan inom 72 timmar, eventuell mellanrapport på begäran och slutrapport inom en månad. Rapporteringen sker till CSIRT Sverige via MSB:s portal.]
Vilka misstag bör ni undvika vid incidentrapportering?
Erfarenheter från NIS1 och GDPR-rapportering visar vanliga fallgropar. Enligt MSB, 2025, identifierar myndigheten bristande incidentklassificering, ofullständiga rapporter och försenad rapportering som de vanligaste problemen.
Misstag 1: Väntar tills ni har all information. Den tidiga varningen kräver inte fullständig information. Skicka den med det ni vet. Komplettera i efterföljande rapporter. Att vänta tills ni vet allt leder till missad tidsfrist.
Misstag 2: Underskattar incidentens allvar. I en pågående incident är det vanligt att underskatta omfattningen. Klassificera hellre för högt initialt och nedgradera om det visar sig vara mindre allvarligt.
Misstag 3: Rapporterar inte parallellt till IMY. Om incidenten involverar personuppgifter ska ni rapportera till IMY inom 72 timmar enligt GDPR, parallellt med NIS2-rapporteringen. Missa inte detta.
Misstag 4: Saknar dokumentation för slutrapporten. Under en aktiv incident prioriteras åtgärder framför dokumentation. Men utan löpande dokumentation blir slutrapporten svår att skriva. Utse en person som dokumenterar händelseförloppet i realtid.
Misstag 5: Testar aldrig processen. En incidentrapporteringsprocess som aldrig testats fungerar sällan vid en verklig incident. Genomför tabletop-övningar minst kvartalsvis.
[UNIQUE INSIGHT] Vi har sett att det vanligaste felet inte är tekniskt utan organisatoriskt. Företag saknar tydliga beslutsvägar för vem som klassificerar en incident och vem som godkänner att rapporten skickas. I en stressig situation leder oklar ansvarsfördelning till dyrbar tidsförlust.
Vanliga frågor om NIS2 incidentrapportering
När börjar 24-timmarsklockan ticka?
Klockan startar från det ögonblick organisationen blir medveten om den betydande incidenten. Enligt EU-kommissionen, 2024, innebär "medveten" att en behörig person i organisationen har fått information om händelsen och bedömt den som en potentiellt betydande incident. Automatiserade larm som ingen reagerar på räknas inte som medvetenhet, men organisationen förväntas ha processer för att hantera larm.
Vad händer om vi rapporterar för sent?
Försenad rapportering kan leda till sanktioner. Enligt NIS2 artikel 34 ska sanktionerna vara proportionella, så en försening på några timmar vid en komplex incident bedöms lindrigare än att medvetet inte rapportera. Men mönster av försenad rapportering tyder på bristande processer och kan leda till skärpta åtgärder.
Behöver vi rapportera incidenter hos våra leverantörer?
Om incidenten hos leverantören påverkar era tjänster eller system, ja. Ni rapporterar er egen påverkan, inte leverantörens incident. Men ni ska beskriva att rotorsaken ligger hos en tredje part. Leverantören kan ha egna rapporteringsskyldigheter om den också omfattas av NIS2.
Kan CSIRT Sverige hjälpa oss vid en incident?
Ja, CSIRT Sveriges uppdrag inkluderar att bistå med teknisk assistans vid incidenter. Enligt MSB, 2025, kan CSIRT erbjuda analys, rådgivning och samordning. De kan inte hantera incidenten åt er, men de kan ge värdefull vägledning och kompromissindikatorer.
Hur förhåller sig NIS2:s rapportering till DORA:s 4-timmarskrav?
Finansbolag som omfattas av DORA ska följa DORA:s strängare 4-timmarsfrist som lex specialis. NIS2:s 24-timmarsfrist gäller för alla andra sektorer. Om ni är ett finansbolag, bygg incidentprocessen kring 4-timmarskravet.
Sammanfattning
NIS2:s incidentrapportering kräver tidig varning inom 24 timmar, incidentanmälan inom 72 timmar och slutrapport inom en månad. Rapporteringen sker till CSIRT Sverige via MSB:s portal. Förberedelse är avgörande, eftersom över hälften av EU:s organisationer idag inte kan rapportera inom tidsfristen.
Bygg en incidentrapporteringsprocess med tydliga roller, fördefinierade mallar och regelbundna övningar. Rapportera hellre för tidigt och med ofullständig information än för sent. De organisationer som övar regelbundet klarar de skarpa situationerna bäst.
Komplett guide till NIS2-direktivet
For hands-on delivery in India, see end-to-end disaster recovery.
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.
