Tiden börjar ticka vid upptäckt
När en betydande säkerhetsincident upptäcks startar klockan. NIS2 ger er 24 timmar, inte 24 arbetstimmar, inte “nästa vardag”, utan 24 faktiska timmar, att skicka en tidig varning till CSIRT.
Det betyder att en incident som upptäcks lördag kväll kräver en rapport söndag kväll. Är er organisation förberedd på det?
Kritisk fråga: Har ni dokumenterade kontaktvägar till CSIRT som fungerar även utanför kontorstid? Om svaret är nej, är det första att åtgärda.
Vad är en “betydande incident”?
Inte alla incidenter behöver rapporteras. NIS2 fokuserar på betydande incidenter: de som har verklig påverkan på tjänsten eller andra.
En incident räknas som betydande om den:
- Har orsakat eller kan orsaka allvarlig driftsstörning för tjänsten
- Har orsakat eller kan orsaka ekonomisk förlust för organisationen
- Har påverkat eller kan påverka andra fysiska eller juridiska personer genom materiell eller immateriell skada
Exempel på betydande incidenter:
- Ransomware som krypterar produktionssystem
- Dataintrång med läckage av personuppgifter
- DDoS-attack som gör tjänster otillgängliga för kunder
- Komprometterad leverantör med tillgång till era system
Tidslinjen: Tre rapporter, tre deadlines
- Tidig varning: inom 24 timmar Den första rapporten är en snabb avisering om att något har hänt. Den behöver inte vara komplett. Syftet är att varna. Inkludera: att en incident har inträffat, initial bedömning av omfattning, och om incidenten misstänks vara gränsöverskridande eller påverka andra EU-länder.
- Incidentmeddelande: inom 72 timmar Nu förväntas mer substans. Uppdatera med bedömning av incidentens allvarlighetsgrad och påverkan, beskrivning av vad som hänt (så långt ni vet), och eventuella kompromissindikatorer (IOC) som kan hjälpa andra.
- Slutrapport: inom 1 månad Den fullständiga analysen. Innehåller detaljerad beskrivning av incidenten, rotorsaksanalys, vidtagna och planerade åtgärder, samt lärdomar och förbättringsåtgärder.
Detaljerat innehåll per rapport
Tidig varning (24 timmar)
| Fält | Beskrivning | Obligatoriskt |
|---|---|---|
| Tidpunkt för upptäckt | När incidenten upptäcktes | Ja |
| Typ av incident | Preliminär klassificering | Ja |
| Påverkade tjänster | Vilka tjänster som berörs | Ja |
| Initial omfattning | Uppskattning av påverkan | Ja |
| Gränsöverskridande | Misstänkt påverkan i andra länder | Ja |
| Kontaktperson | Vem CSIRT kan kontakta | Ja |
Incidentmeddelande (72 timmar)
| Fält | Beskrivning | Obligatoriskt |
|---|---|---|
| Uppdaterad status | Nuläge och utveckling | Ja |
| Allvarlighetsgrad | Bedömning av svårighetsgrad | Ja |
| Teknisk beskrivning | Vad som hänt tekniskt | Ja |
| Påverkan | Antal drabbade, tjänsteförlust | Ja |
| IOC | Kompromissindikatorer | Om tillgängligt |
| Vidtagna åtgärder | Vad ni gjort hittills | Ja |
Slutrapport (1 månad)
| Fält | Beskrivning | Obligatoriskt |
|---|---|---|
| Fullständig tidslinje | Kronologi från start till slut | Ja |
| Rotorsaksanalys | Grundorsaken till incidenten | Ja |
| Påverkan (slutlig) | Faktisk påverkan, drabbade | Ja |
| Alla vidtagna åtgärder | Komplett lista | Ja |
| Lärdomar | Vad ni lärt er | Ja |
| Förbättringsplan | Hur ni förebygger återupprepning | Ja |
Vem rapporterar ni till?
Alla betydande incidenter rapporteras till Cert-SE vid MCF (tidigare MSB, numera Myndigheten för civilt försvar från 1 januari 2026). De koordinerar den tekniska hanteringen och kan bistå med analys och rekommendationer.
Beroende på sektor rapporterar ni även till er sektorsmyndighet. Energimyndigheten för energi, Transportstyrelsen för transport, Finansinspektionen för bank, etc.
Praktiskt: MCF (Myndigheten för civilt försvar, tidigare MSB) arbetar med att etablera enhetliga rapporteringskanaler. Håll er uppdaterade via mcf.se för aktuell information om hur rapportering ska ske.
Vanliga fallgropar att undvika
24 timmar gäller även helger och nätter. Utan fungerande jourberedskap och tydliga kontaktvägar blir det omöjligt att uppfylla tidskraven när det verkligen gäller.
Under en pågående incident är det sista ni vill göra att fundera på format och formuleringar. Ha färdiga mallar för alla tre rapporttyperna redo att fylla i.
Vem beslutar att rapportera? Vem skriver? Vem godkänner? Oklara roller leder till förseningar. Dokumentera ansvarsfördelningen nu.
Rapporten till CSIRT är inte allt. Glöm inte intern eskalering till ledning, eventuell GDPR-rapport till IMY vid personuppgiftsincidenter, och kommunikation med kunder.
Checklista: Är ni förberedda?
Använd denna checklista för att bedöma er beredskap:
Processer och dokumentation:
- Tydlig definition av vad som utgör en betydande incident
- Dokumenterad incidenthanteringsprocess
- Eskaleringsrutiner och beslutsgångar
- Mallar för alla tre rapporttyperna
- Kontaktuppgifter till CSIRT och tillsynsmyndighet
Organisation och resurser:
- Jourberedskap eller motsvarande för snabb respons
- Utsedd incidentansvarig med mandat
- Utbildad personal som kan agera
- Kommunikationskanaler som fungerar dygnet runt
Teknisk förmåga:
- Detektionsförmåga för att upptäcka incidenter
- Loggning för att utreda vad som hänt
- Möjlighet att samla kompromissindikatorer (IOC)
- Backup och återställningsförmåga
Praktiska tips
Bygg en incidenthanteringsövning
Genomför regelbundna övningar där ni simulerar en betydande incident. Fokusera på:
- Kan ni producera en tidig varning inom 24 timmar?
- Fungerar kontaktvägarna till CSIRT?
- Vet alla inblandade vad de ska göra?
Skapa mallar nu
Vänta inte till incidenten. Skapa mallar för:
- Tidig varning: Standardformulär med förifyllda fält
- Incidentmeddelande: Struktur för djupare analys
- Slutrapport: Mall för fullständig dokumentation
Etablera kontaktvägarna
- Registrera er hos MCF/Cert-SE om ni inte redan gjort det
- Testa rapporteringskanalen innan det blir skarpt läge
- Ha backup-kontaktvägar (telefon, inte bara e-post)
Vill du veta mer om NIS2:s övriga krav? Läs vår NIS2-ramverksöversikt för en komplett bild av direktivet, eller kontrollera om ni omfattas av NIS2 med vårt klassificeringsverktyg.
Så kan Securapilot hjälpa
Securapilots incidenthanteringsmodul är byggd med NIS2:s tidskrav i åtanke:
- Incidentklassificering: Automatisk bedömning mot NIS2:s definition av betydande incident
- Tidskontroll: Spårning av deadlines med varningar innan de löper ut
- Mallgenerering: Automatisk generering av rapporter baserat på incidentdata
- Eskalering: Inbyggda arbetsflöden för godkännande och eskalering
- Dokumentation: Komplett spårbarhet för slutrapporten
Boka en demo och se hur vi kan hjälpa er vara förberedda när det verkligen gäller.
Vanliga frågor
Vad är en 'betydande incident' enligt NIS2?
En incident räknas som betydande om den har orsakat eller kan orsaka allvarlig driftsstörning för tjänsten, ekonomisk förlust för organisationen, eller påverkat eller kan påverka andra fysiska eller juridiska personer genom materiell eller immateriell skada.
Vem rapporterar jag till?
I Sverige rapporteras incidenter till CSIRT (Cert-SE vid MCF, tidigare MSB) och till er sektorspecifika tillsynsmyndighet. Exakt rapporteringsväg beror på vilken sektor ni tillhör. MCF (Myndigheten för civilt försvar) tillhandahåller rapporteringskanaler via mcf.se.
Vad händer om jag missar 24-timmarsfristen?
Att missa rapporteringsfrister kan leda till sanktioner. Det viktigaste är dock att rapportera så snart som möjligt, även om fristen passerats. Att inte rapportera alls är betydligt allvarligare än att rapportera sent.
Måste jag rapportera incidenter hos leverantörer?
Om en incident hos en leverantör påverkar er förmåga att leverera era tjänster kan det bli en rapporteringspliktig incident för er. Ni behöver ha avtal och processer som säkerställer att leverantörer snabbt informerar er om incidenter.
