Incidentrapportering enligt NIS2 – steg-för-steg från upptäckt till avslut

En av de mest konkreta och tidskritiska förändringarna med NIS2 är de harmoniserade kraven på incidentrapportering. För första gången har vi i EU gemensamma tidsfrister och tröskelvärden för när en säkerhetsincident måste rapporteras till tillsynsmyndigheten. Den här guiden går igenom hela flödet, från upptäckt till avslutad rapport, med tidslinjer, tröskelvärden och en mall ni kan använda direkt.

Jag bygger incidentberedskap och rapporteringsrutiner inom cybersäkerhet och compliance. Min erfarenhet är att de flesta bolag underskattar hur mycket förberedelse som krävs för att klara rapporteringsfristerna i praktiken. Det räcker inte att veta att man ska rapportera inom 24 timmar, man måste på förhand ha bestämt vem som bedömer om incidenten är rapporteringspliktig, vem som fattar beslutet och vem som skriver rapporten. Utan den förberedelsen blir 24-timmarsfristen ett stressmoment snarare än en stödjande struktur.

Varför incidentrapportering är central i NIS2

Incidentrapportering är inte bara en administrativ skyldighet. Den är en av de mekanismer som gör NIS2 till ett levande regelverk istället för en pappersprodukt. När incidenter rapporteras får myndigheterna en samlad hotbild över sektorerna, kan varna andra aktörer och i förlängningen stärka hela samhällets motståndskraft. För ert eget bolag är rapporteringskravet en motor för att faktiskt ha koll: för att kunna rapportera inom 24 timmar måste ni ha en fungerande incidenthantering där det är uppenbart vem som gör vad när något händer.

Tidlinjen: tre deadlines att hålla

NIS2 inför en rapporteringsstruktur i tre steg. Early warning inom 24 timmar från det att ni får kännedom om incidenten. Det är en kort rapport med vad som hänt, vilken påverkan ni bedömer och om den pågår fortfarande. Full rapport inom 72 timmar, där ni detaljerat beskriver incidentens art, påverkan, omfattning och de tekniska detaljerna som är kända. Slutrapport inom en månad, med den fullständiga utredningen, grundorsaksanalys, vidtagna åtgärder och lärdomar.

Det här är en betydligt tätare tidtabell än något tidigare svenska regelverk krävt. För bolag som idag har en incidentrapporteringsprocess som tar veckor är gapet stort. Men det går att bygga upp steg för steg. Det viktigaste är att ha roller, mallar och beslutsmandat redo i förväg, så att de första 24 timmar kan ägnas åt att hantera incidenten och samla fakta, inte åt att diskutera vem som ska skriva rapporten.

Tröskelvärden: när ska ni rapportera?

Alla incidenter ska inte rapporteras. NIS2 definierar tröskelvärden som avgör när en incident är allvarlig nog att kräva rapportering. Kriterierna inkluderar om incidenten orsakat eller kan orsaka en betydande störning i tjänstens kontinuitet, om den lett till ekonomisk skada över en viss nivå, eller om den påverkat andra fysiska eller juridiska personer betydande. Om osäkerhet råder är rekommendationen att rapportera, bedömningen kan alltid justeras i efterhand.

Det här är en av de punkter där förberedelse lönar sig mest. Att i lugn och ro definiera vad "betydande störning" betyder för just er verksamhet, och dokumentera det i en policy, gör att beslut under stress blir snabbare och mer konsekventa. Utan den förberedelsen hamnar ni i en diskussion om definitioner när ni egentligen borde hantera incidenten.

Mall för rapportering – vad ska med?

En full rapport enligt NIS2 bör innehålla: beskrivning av incidenten (vad, när, hur), bedömd påverkan (operativ, ekonomisk, personuppgifter), omfattning (antal berörda system, användare, kunder), vidtagna och planerade åtgärder, samt kontaktuppgifter till ansvarig. För early warning räcker en kortare version: typ av incident, påverkan och status. Det är klokt att ha mallar för alla tre stegen färdiga på förhand.

Här gör jag mid-vägs alltid samma sak: jag tar fram mallar för early warning, full rapport och slutrapport anpassade till bolagets sektor och storlek. Vill ni ha dem gjorda ingår det i cybersäkerhetsuppdraget.

Vanliga misstag

Tre misstag återkommer. Det första är att rapportera för sent, ofta för att man försöker få en fullständig bild innan man skickar early warning, men tidiga varningen är just tidig, den ska vara kort. Det andra är att inte ha bestämt vem som rapporterar, vilket leder till fördröjning när ansvaret studsar mellan IT och ledning. Det tredje är att glömma att dokumentera incidenten internt även om den inte når rapporteringströskeln, eftersom flera mindre incidenter tillsammans kan indikera ett systematiskt problem som kräver åtgärd. Alla tre misstagen går att förebygga med förberedelse och tydliga roller.

Ett fjärde, mer subtilt misstag är att inte öva på rapporteringsflödet. Teorin är en sak, men att faktiskt sitta med en incident och försöka fylla i early warning-mallen under tidspress är en annan. En enkel skrivbordsövning där någon simulerar ett intrång och teamet får producera rapporterna enligt tidsfristerna avslöjar snabbt var flaskhalsarna sitter, och den övningen kostar inget mer än en eftermiddag.

Relation till incidentberedskap

Rapporteringskraven i NIS2 förutsätter en fungerande incidentberedskap. Om ni inte redan har en incident response-plan på plats är det första steget att bygga den, jag beskriver ett beprövat ramverk i Incident response-plan: 6-fas-ramverket. Rapporteringsförmågan är en konsekvens av en mogen incidenthantering, inte en separat administrativ uppgift.

Var jag brukar börja

Börja med att definiera tröskelvärdena för just ert bolag och ta fram mallar för de tre rapporteringsstegen. Därefter bestämmer ni roller och mandat: vem bedömer, vem beslutar, vem rapporterar. När det är på plats är ni redo för en första övning. Se hur jag lägger upp incidentberedskap i kundcase.

Relaterat

• NIS2 – så påverkas just ditt företag beroende på sektor
• Personligt ledningsansvar enligt NIS2 – vad styrelsen måste veta
• NIS2-compliance – så hjälper jag ert bolag

Vill du ta det vidare?

Jag hjälper svenska bolag att bygga incidentrapporteringsrutiner som klarar NIS2:s tidsfrister i skarpt läge. Boka ett samtal så går vi igenom er beredskap.