Anmälningsplikten går snabbare än ni hinner läsa lagtexten

De flesta bolag som läser om den nya cybersäkerhetslagen fastnar på frågan om de omfattas. Färre tänker på vad som händer den dag en incident faktiskt inträffar. Det är där lagen ställer de skarpaste kraven, och där de flesta bolag har minst förberedelse.

Kravet gäller oavsett om bolaget själv orsakat incidenten eller om den kommer från en extern attack. En leverantör som drabbas av utpressningsprogram, en felkonfiguration som exponerar data, eller ett längre driftavbrott i en kritisk tjänst kan alla utlösa samma anmälningsplikt, vilket gör att processen behöver vara generell nog att täcka flera typer av händelser snarare än byggd för ett enda scenario som råkar kännas mest sannolikt idag.

Ett bolag som omfattas av lagen ska lämna en första anmälan till ansvarig myndighet inom mycket kort tid efter att en allvarlig incident upptäckts. Sedan följer en uppföljande anmälan, och till sist en slutrapport. Tidsramarna är satta i timmar och dagar, inte i veckor. Det är en helt annan takt än den som gäller för de flesta interna incidentprocesser idag, som ofta är byggda för att först utreda internt och kommunicera senare.

Det räcker sällan att skriva ner en process en gång och sedan lägga den i en pärm. En anmälningsprocess som aldrig testats i praktiken tenderar att visa sina svagheter först när den verkligen behövs, till exempel att mallen är föråldrad, att ansvarslistan pekar på någon som slutat, eller att ingen längre minns var dokumentet ens ligger sparat. Ett kort, återkommande test av processen, en eller två gånger om året, är ofta det som gör skillnaden mellan en plan som fungerar och en som bara ser bra ut på pappret.

Problemet är sällan tekniskt. De flesta bolag med en fungerande IT-drift kan upptäcka och stoppa en incident. Problemet är organisatoriskt. Vem inom bolaget har mandat att avgöra att en incident är anmälningspliktig. Vem skriver anmälan. Vem godkänner texten innan den skickas till en myndighet, med vetskap om att en dåligt formulerad anmälan kan skapa mer problem än den löser.

Tänk dig ett mjukvarubolag som upptäcker ovanlig trafik i sitt system en fredag kväll. IT-avdelningen löser det tekniska problemet under helgen och känner sig nöjd på måndagen. Ingen i bolaget har tänkt på att klockan redan börjat ticka för en anmälan som skulle ha lämnats inom det första dygnet. Det är inte den tekniska lösningen som blir problemet i efterhand. Det är avsaknaden av en process för att fatta anmälningsbeslutet i tid.

Många bolag utgår från att det räcker att ha en generell krisplan från tidigare, till exempel för driftstörningar eller allvarliga kundklagomål. Cybersäkerhetslagens process skiljer sig från det på ett avgörande sätt: den kräver kontakt med en extern myndighet inom en fast tidsram, med juridiskt korrekt formulerade uppgifter, mer omfattande än en vanlig intern eskalering till närmaste chef. En krisplan byggd för att lösa problemet internt är inte samma sak som en plan byggd för att också kommunicera det korrekt utåt.

En fungerande process kräver tre saker på plats innan något händer. Det första är en tydlig definition av vad som räknas som en anmälningspliktig incident för just det egna bolagets verksamhet, eftersom lagtexten är generell och behöver översättas till konkreta exempel som personalen känner igen. Det andra är en namngiven kedja av beslutsfattare som kan agera även när den ordinarie ansvariga är på semester eller otillgänglig. Det tredje är en färdig mall för själva anmälan, så att den akuta situationen inte också blir det första tillfället att formulera juridisk text under tidspress.

Övningen behöver inte vara omfattande för att göra nytta. Även en kort genomgång, där de inblandade går igenom ett tänkt scenario muntligt och pekar på vem som gör vad, brukar räcka för att avslöja de mest akuta luckorna i ansvarsfördelningen, långt innan en verklig incident sätter processen på prov på riktigt.

Kostnaden för att sakna det här syns inte i en vanlig vecka. Den syns den dag en incident faktiskt inträffar, i form av försenade anmälningar, otydligt ansvar och beslut som fattas av fel person i stressen. En sen eller ofullständig anmälan kan i sig bli en egen sanktionsgrundande händelse, utöver själva säkerhetsincidenten.

Gör den här övningen den här veckan. Fråga tre personer i ledningen, oberoende av varandra, vem som skulle fatta beslutet om en anmälan till myndigheten om en allvarlig incident inträffade imorgon. Får ni tre olika svar, eller tveksamma svar, är det ett tydligt tecken på att processen behöver formaliseras innan den sätts på prov på riktigt.