De flesta organisationer som börjar närma sig NIS2 gör det med juristen i rummet. Direktivet
läses som en text att tolka, en checklista att bocka av, ett dokument att arkivera inför nästa
revision. Och visst – det juridiska behöver redas ut. Men misstaget ligger i att stanna där. För när en incident faktiskt inträffar är det inte juridiken som avgör om ni klarar kraven. Det är er drift.
NIS2 ställer krav som bara kan uppfyllas operativt: en tidig varning ska gå ut inom 24 timmar, en
mer fullständig rapport inom 72 timmar, en slutrapport senare. Det är inte en formulering som
löses i ett policydokument – det är ett arbetsflöde som måste fungera klockan tre på natten, när
någon i jouren ska avgöra om det som händer är en rapporteringspliktig incident eller inte
Frågan är inte om ni har en process. Frågan är om processen håller under tryck.

Var efterlevnaden faktiskt avgörs

Det avgörande är detta: NIS2-efterlevnad bor i samma system där ni redan hanterar era
ärenden. Inte i ett separat compliance-verktyg vid sidan om, utan i ärendehanteringen där
incidenter ändå registreras, klassificeras, eskaleras och stängs.
Anledningen är enkel. En incident som ska rapporteras till tillsynsmyndigheten är först och
främst en incident som ska hanteras. Om de två sakerna lever i olika system uppstår glappet –
informationen som behövs för rapporten finns utspridd, tidsstämplarna stämmer inte, och någon
måste i efterhand rekonstruera ett händelseförlopp under tidspress. Det är precis i det glappet
som krav faller mellan stolarna.
Lägger ni i stället rapporteringskraven inuti ärendeflödet blir samma arbete som löser incidenten
också det som dokumenterar den. Rätt fält fylls i från början. Klassificeringen som avgör om
incidenten är rapporteringspliktig sker vid registrering, inte i efterhand. Och tidslinjen byggs
automatiskt, eftersom varje åtgärd ändå tidsstämplas i systemet.

Tre saker driften måste klara

Klassificering vid källan. Den svåraste bedömningen i NIS2 är ofta den första: är detta en
betydande incident? Den frågan måste kunna besvaras strukturerat redan när ärendet skapas,
med stöd i fördefinierade kriterier – inte överlämnas till en enskild handläggares magkänsla. En
ärendemall som tvingar fram rätt information vid registrering är värd mer än någon
efterhandskontroll.

Tidskraven som inbyggd mekanik. 24 och 72 timmar låter generöst tills en incident inträffar
fredag eftermiddag. Tidsfristerna behöver vara inbyggda i flödet med automatiska påminnelser
och eskalering, så att ingen frist passeras för att rätt person inte råkade titta i inkorgen. Det är
skillnaden mellan att möta tidskraven och att hoppas på dem.Spårbarhet som biprodukt. Vid tillsyn eller revision behöver ni kunna visa inte bara att ni
hanterade en incident, utan hur – vilka beslut som togs, när, av vem, och vad ni lärde er. Om
dokumentationen är ett separat moment kommer den att slarvas bort. Om den är en naturlig del
av ärendehanteringen finns den redan där när granskaren frågar.

Den lugna versionen

Skillnaden mellan en stressig och en lugn NIS2-efterlevnad är inte hur mycket ni anstränger er
när larmet går. Den ligger i strukturen ni byggt innan. En organisation där rapportering, tidsramar
och spårbarhet redan är inbäddade i det dagliga ärendearbetet behöver inte improvisera vid en
incident. Den bara kör sin process.
Det är också därför detta sällan handlar om att köpa ett nytt, fristående NIS2-verktyg. Det handlar om att den ärendehantering ni redan litar på i driften ska bära kraven – så att efterlevnad blir något ni gör varje dag, inte något ni förbereder inför revisionen.
NIS2 är, rätt hanterat, inte en börda ovanpå verksamheten. Det är en anledning att skärpa en
process ni ändå behöver: att veta vad som händer, agera i tid, och kunna visa det i efterhand.