Guider

NIS2-guide · 7 min

NIS2-incidentrapportering: 24- och 72-timmarsfristerna förklarade

När en betydande incident inträffar startar klockan omedelbart — och NIS2 sätter en rad hårda frister mätta i timmar, inte dagar. Den här guiden förklarar vad som räknas som en betydande incident, den exakta rapporteringstidslinjen enligt artikel 23 och situationen som team oftast missar: när en leverantörs incident blir din rapporteringsskyldighet.

Viktiga punkter

  • En betydande incident utlöser en stegvis rapport: tidig varning inom 24 timmar, fullständig anmälan inom 72 timmar, slutrapport inom en månad (art. 23).
  • "Betydande" innebär allvarlig driftstörning eller ekonomisk förlust, eller avsevärd skada för andra — alla incidenter når inte tröskeln.
  • En leverantörs eller tredje parts incident som stör din tjänst kan starta din 24-timmarsklocka — insyn i dem är en del av beredskapen.
  • Anmälningar går till ditt nationella CSIRT eller behörig myndighet; du kan också behöva informera mottagarna av dina tjänster.

Vad som räknas som en "betydande" incident

Alla incidenter är inte anmälningspliktiga. Enligt artikel 23 är en incident betydande om den har orsakat eller kan orsaka allvarlig driftstörning av tjänsterna eller ekonomisk förlust för aktören, eller om den har påverkat eller kan påverka andra fysiska eller juridiska personer genom att orsaka avsevärd materiell eller immateriell skada.

Kommissionen har fastställt mer konkreta tröskelvärden för vissa digitala leverantörer i en genomförandeförordning, men principen gäller över alla sektorer: bedöm efter påverkans allvar och räckvidd, inte efter angreppets tekniska nyhetsvärde. Vid tvivel, dokumentera din bedömning — beslutet att inte anmäla bör vara lika försvarbart som beslutet att anmäla.

Rapporteringstidslinjen (artikel 23)

Rapporteringen är stegvis: först en snabb signal, detaljer senare. Fristerna löper från det ögonblick du får kännedom om den betydande incidenten.

Inom 24 timmar — tidig varning

En första varning till ditt CSIRT eller behörig myndighet, med uppgift om huruvida incidenten misstänks orsakas av olagliga eller illvilliga handlingar eller kan ha gränsöverskridande effekter.

Inom 72 timmar — incidentanmälan

En uppdatering med en första bedömning: allvar och påverkan samt indikatorer på intrång där det finns.

På begäran — delrapport

Om CSIRT eller myndigheten begär det, en statusuppdatering om hanteringen av incidenten.

Inom 1 månad efter anmälan — slutrapport

En detaljerad beskrivning: grundorsak och hottyp, tillämpade och pågående åtgärder samt eventuell gränsöverskridande påverkan.

Om incidenten fortfarande pågår vid enmånaderspunkten lämnar du i stället en lägesrapport, och slutrapporten inom en månad efter att incidenten hanterats.

När någon annans incident blir din

NIS2:s rapporteringsskyldighet är inte begränsad till incidenter som uppstår i dina egna system. Om en leverantör eller tjänsteleverantör drabbas av en incident som orsakar en betydande störning av de tjänster du tillhandahåller, kan skyldigheten att anmäla falla på dig — och 24-timmarsklockan startar när du får kännedom, inte när leverantören äntligen berättar.

Det är den svåra delen: leverantörer avslöjar inte alltid incidenter snabbt, och en anmälan som kommer en vecka för sent har redan förbrukat din frist. Beredskap beror därför på oberoende insyn — att veta när en kritisk leverantör dyker upp på en ransomware-läcksajt, får uppgifter läckta eller blir mörklagd, utan att vänta på deras e-post.

Hur man är redo innan klockan startar

Att klara en frist på några timmar är en fråga om förberedelse, inte hjältemod. Se till att du före en incident kan svara på:

Vem avgör om en incident är "betydande", och vem når CSIRT utanför kontorstid?
Har vi CSIRT-/myndighetskontakten och anmälningskanalen redo — inte uppslagen mitt i krisen?
Finns leverantörernas klausuler om incidentanmälan i våra avtal, med ett definierat anmälningsfönster?
Har vi oberoende övervakning av kritiska leverantörer, så att vi inte är blinda för en incident de inte avslöjat?
Kan vi ta fram tidslinjen och bevisen som en slutrapport kräver — vad som hände, när, och vad vi gjorde?

Källa: Direktiv (EU) 2022/2555 (NIS2), artikel 23 — samt kommissionens genomförandeförordning om tröskelvärden för betydande incidenter för vissa digitala leverantörer; kontrollera ditt nationella CSIRT:s rapporteringsportal för rätt kanal.

Hur norppa.io hjälper

Den svåraste delen av tidslinjen är den du inte styr över: en leverantörsincident du får veta om för sent. norppa.io övervakar dina leverantörer kontinuerligt — ransomware-offerlistor och läckta uppgifter på dark web kontrolleras ungefär var sjätte timme, med omedelbar varning — så att en leverantörshändelse når dig i tid att starta din egen klocka.

Och eftersom varje fynd är tidsstämplat och kopplat till NIS2-artiklar är den historik som en 72-timmarsanmälan eller en slutrapport efter en månad behöver — vad som sågs, när, och vad som gjordes — redan sammanställd snarare än rekonstruerad under press.

Få inte veta om en leverantörsincident för sent

Se i exempelrapporten hur kontinuerlig leverantörsövervakning lyfter fram ransomware och läckor inom timmar.

Se exempelrapport

Relaterade guider

NIS2 och leveranskedjekravet — vad det innebär i praktiken

NIS2 kräver att viktiga och betydande aktörer bedömer cyberriskerna i sina leveranskedjor. Leverantörstierning, fjärdepartsrisk, Art. 23-anmälan och vad revisorer letar efter.

NIS2 Art. 21(2) — säkerhetschecklista för leverantörer

Checklista för inköps- och säkerhetsteam: vad man ska fråga, vilka bevis man ska samla in och hur man reagerar när en leverantör brister. Inkluderar förslag på styrkande dokument.

Leverantörens cyberriskbedömning: vad automatiserad NIS2-övervakning kontrollerar

Alla kontrollkategorier förklaras: ransomware, dark web-läckor, TLS/DNSSEC, cookie-säkerhet, CVE/EPSS, sanktioner, MX-svartlistor och SAQ. Fyndens livscykel och NIS2-artikelmappning.

Vem omfattas av NIS2? Väsentliga och viktiga aktörer, sektorer och storlekströsklar

Avgör om NIS2 gäller dig: de två nivåerna, sektorerna i bilaga I/II, storlekströsklarna, storleksoberoende undantag och hur leveranskedjan drar in dig även utan utpekning.

NIS2-leverantörsenkät (SAQ): vad du ska fråga, hur du poängsätter och en gratis mall

Vad du ska fråga leverantörer enligt art. 21.2 d, hur du poängsätter svar och hanterar brister, varför självdeklaration behöver verifieras, plus en gratis enkätmall.

NIS2 vs DORA: hur de skiljer sig, var de överlappar och vilken som gäller dig

Hur de två EU-regelverken skiljer sig och överlappar, varför DORA är lex specialis för finansiella enheter, vilken som gäller dig, och vad båda innebär för tredjepartsrisk.

NIS2 och ledningens ansvar: vad styrelse och ledning måste veta

Vad NIS2 förväntar sig av ledningsorganet: godkännande- och tillsynsplikt, personligt ansvar (art. 20), utbildning, styrelse-KPI:er och sanktionerna enligt art. 34.

ISO 27001 och NIS2: vad ditt LIS redan täcker — och luckorna det inte gör

Om du har ISO 27001: vad som förs över till NIS2 och inte — lagstadgad incidentrapportering, ledningens ansvar, registrering och kontinuerlig leveranskedjesäkring — och hur du täpper till luckan.