I många svenska organisationer i dag är NIS2 erkänt men inte riktigt operationaliserat. Man vet att det gäller. Visst styrningsarbete har påbörjats. Några styrelsemöten har planerats och skjutits upp. De flesta avvaktar fortfarande för att se hur strikt tillsynen faktiskt kommer att bli innan de lägger seriös kraft bakom det.
Men ögonblicket då samtalet blir verkligt är oftast detsamma.
Vad händer egentligen mellan att en allvarlig säkerhetsincident upptäcks och att den första rapporten skickas in till MSB inom 24 timmar?
När den frågan ställs i praktiken – oavsett om det är i Stockholm, Malmö eller i offentliga och privata organisationer – kommer svaret sällan omedelbart. Inte för att teamen är tekniskt oförberedda, utan för att hela vägen från upptäckt till rapportering aldrig har testats som en sammanhängande process.
Enligt NIS2-direktivet, artikel 23, krävs tre saker: en tidig varning inom 24 timmar, en mer detaljerad rapport inom 72 timmar och en slutrapport inom en månad.
24-timmarssteget är det som avslöjar den verkliga svagheten i de flesta organisationer. Inte på den tekniska sidan, utan i hur beslut fattas och eskaleras.
De flesta företag har redan två saker på plats: en säkerhetsfunktion som kan upptäcka och hantera incidenter, och en ledningsstruktur som är formellt ansvarig. Problemet är ingen av dessa. Problemet är glappet mellan dem när tiden är knapp.
Det finns oftast ingen testad väg som kopplar en säkerhetsvarning till ett ledningsbeslut och sedan till en regulatorisk inlämning inom några timmar. Det finns på papper, men inte under press.
I ett fall inom finanssektorn såg allt ut att vara redo på ytan. Verktyg var på plats, rutiner var dokumenterade och ansvar hade tilldelats.
En kväll upptäcktes ovanlig lateral förflyttning i systemet. Det tekniska teamet gjorde det de skulle göra. System isolerades, loggar samlades in och åtgärder påbörjades omedelbart.
Svårigheten kom efteråt, när frågan skiftade från teknisk respons till klassificering.
Var detta en betydande incident som behövde rapporteras?
Den frågan stoppade allt. Säkerhetsteamet lutade åt ja. Ledningen behövde bekräftelse. Juridik behövde involveras. Juridik var inte tillgänglig vid den tidpunkten. Det fanns ingen fördefinierad metod för att fatta det beslutet utan dem.
Till slut hölls tidsfristen, men med nöd och näppe. Problemet var inte upptäckt eller respons. Det var beslutsfattande under osäkerhet, med en klocka som tickade.
Den situationen är vanligare än de flesta organisationer erkänner.
Klassificeringssteget i sig är där svårigheten döljer sig. Kriterierna är tydliga på papper: allvarlighetsgrad, antal påverkade användare, varaktighet och potentiell gränsöverskridande påverkan.
I verkligheten presenterar incidenter sällan ren information. Tidigt i en händelse har du inte hela bilden. Du kanske inte har den inom 24 timmar heller. Men rapporteringsklockan väntar inte på klarhet.
Det är här organisationer ofta misslyckas. Inte för att de missförstår reglerna, utan för att de förväntar sig säkerhet innan de agerar.
Det som behövs här är inte en juridisk tolkning utan en enkel intern regel. Något som gör det möjligt för ett team att säga: om dessa förutsättningar föreligger, rapporterar vi. Om vi är osäkra, rapporterar vi ändå och korrigerar senare. Risken att rapportera för tidigt är lägre än risken att rapportera för sent.
De flesta organisationer har inte den typen av regel. De antar att svaret kommer vara uppenbart när situationen uppstår. Det är det sällan.
En annan svag punkt är kopplingen mellan säkerhetsteam och ledning.
NIS2-direktivet lägger ansvar direkt på ledningsorgan. Det innebär att beslut kring rapportering inte bara är operativa – de är ledningsansvar.
I praktiken är eskaleringsvägar ofta otydliga. Incidenthanteringsplaner säger att ledningen ska informeras, men definierar inte exakt vem, hur snabbt eller med vilken strukturerad information. När en incident faktiskt inträffar saktar den otydligheten ner allt.
Förseningen orsakas inte av bristande engagemang. Den orsakas av bristande design.
När ett beslut väl är fattat behöver organisationen fortfarande skicka in den tidiga varningen till MSB. Den delen låter enkel men underskattas ofta.
MSB förväntar sig inte en fullständig kriminalteknisk analys inom 24 timmar. De förväntar sig en tydlig första bild. Vad som är känt, vilka system som påverkas, vad som har gjorts och om det finns potentiell bredare påverkan.
Utmaningen är inte innehållet i sig. Det är att producera det snabbt, under stress, medan en incident fortfarande pågår. Det kräver förtrogenhet med processen, inte bara dokumentation. Och helst bör det aldrig vara första gången teamet gör det.
Många organisationer behandlar rapportering som sekundärt jämfört med förebyggande och upptäckt. Det känns administrativt, mindre tekniskt, mindre brådskande.
Det antagandet är riskabelt. Enligt NIS2 är underlåtenhet att rapportera korrekt eller i tid en överträdelse i sig, oberoende av hur väl incidenten hanterades tekniskt.
Tillsynsmyndigheter tittar inte bara på om incidenter hanterades. De tittar också på om de rapporterades korrekt och i tid.
Den praktiska lösningen är inte komplex, men den måste vara medveten.
Organisationer behöver en dedikerad 24-timmars rapporteringsprocess som ligger vid sidan av huvudplanen för incidenthantering, inte begravd inuti den. Den behöver tydligt definiera hur en incident klassificeras, vem som fattar beslutet, vem som är behörig att anmäla och hur meddelandet skrivs och skickas in.
Den processen behöver också testas, inte bara dokumenteras. Åtminstone en gång bör den övas på ett sätt som inkluderar både tekniska team och ledning som fattar verkliga beslut under tidspress.
Utan det antar organisationen att processen kommer att fungera när den behövs. Det är vanligtvis där misslyckandet sker.
Under en tillsynsprocess enligt NIS2 kan tillsynsmyndigheter ställa en enkel fråga: när blev ni medvetna om incidenten, och vad gjorde ni under de följande 24 timmarna?
De organisationer som kommer ha svårt att besvara den frågan är inte nödvändigtvis de med svag säkerhet. Vissa av dem har stark säkerhet. De kommer att få svårt eftersom 24-timmarskravet i grunden inte främst är en utmaning för säkerhetsoperationer. Det är en organisatorisk samordningsutmaning som råkar utlösas av en säkerhetsincident.
Att ta reda på om er organisation faktiskt kan uppfylla det kravet är ett arbete som är värt att göra redan nu, medan det fortfarande finns tid att åtgärda det ni upptäcker.
