När måste en incident rapporteras?

En incidentplan är bara värdefull om den fungerar i skarpt läge. När något händer behöver teknik, ledning, kommunikation och externa leverantörer kunna agera som en sammanhängande kedja.

Därför behöver ansvar, mandat och kontaktvägar vara tydliga innan klockan börjar ticka.

Sedan den svenska cybersäkerhetslagen trädde i kraft den 15 januari 2026 ska en verksamhetsutövare upplysa ansvarig myndighet om en betydande incident så snart det kan ske, senast inom 24 timmar från kännedom.

De flesta verksamhetsutövare ska därefter göra en incidentanmälan senast inom 72 timmar. En slutrapport lämnas normalt senast en månad efter incidentanmälan.

Det betyder inte att hela orsaken måste vara känd efter ett dygn. Det betyder att organisationen snabbt måste kunna känna igen en möjlig betydande incident, eskalera den och samla tillräckligt beslutsunderlag.

Den första bedömningen bör åtminstone svara på:

• Vad har observerats?
• Vilka system och tjänster kan vara berörda?
• När upptäcktes händelsen?
• Vilka begränsande åtgärder har redan vidtagits?
• Vilken verksamhetspåverkan kan uppstå?

Spara också loggar och andra tidsstämplade underlag. De behövs både för utredningen och för att kunna uppdatera informationen när läget klarnar.

Vilka roller behöver vara tydliga?

Incidentledaren håller ihop läget. Teknikansvarig säkrar bevis, begränsar skadan och återställer. Verksamhetsägaren bedömer påverkan på tjänster och kunder. Ledningen fattar prioriterade beslut. Kommunikations- eller juridikansvarig samordnar rapportering och information.

I mindre organisationer kan samma person ha flera roller. Det viktiga är inte antalet namn i planen, utan att mandat, ersättare och kontaktvägar är bestämda i förväg.

Planera även för att ordinarie e-post, chatt eller identitetsplattform kan vara otillgänglig eller osäker. Ha en alternativ kontaktväg och en uppdaterad lista som går att nå utanför den drabbade miljön.

Kontrollera vem som får stänga en tjänst, anlita extern hjälp eller kommunicera med kunder när den ordinarie beslutsfattaren inte går att nå.

Hur får vi med leverantörerna i incidentplanen?

Kartlägg vilka externa parter som driftar system, lagrar data, hanterar identiteter eller levererar kommunikation.

Kontrollera avtalen:

• Hur snabbt ska leverantören larma?
• Vilken information får ni?
• Vem bevarar loggar?
• Vem deltar i en incidentövning?
• Hur fungerar eskaleringen utanför kontorstid?

En kontaktlista utan överenskomna svarstider är inte en fungerande incidentkedja. Testa minst en kritisk leverantör i nästa övning.

Kontrollera dessutom om leverantören kan lämna de loggar, tidslinjer och tekniska bedömningar ni behöver. Om flera parter delar på driften måste gränserna vara tydliga.

Annars finns risken att viktig tid går åt till att avgöra vem som egentligen äger nästa åtgärd.

Hur testar vi incidentkedjan på 45 minuter?

Utgå från följande scenario:

En administratör får en oväntad MFA-förfrågan. Kort därefter vidarebefordras mejl externt och en kritisk filyta blir otillgänglig.

Ge gruppen tio minuter per fråga:

• Vem äger incidenten?
• Vilka system och kunder kan påverkas?
• Vilka loggar behöver säkras?
• Vem avgör om incidenten är betydande?
• Vilken leverantör kontaktas först?

Låt en person observera och notera när viktiga beslut fattas, vilka uppgifter gruppen saknar och var ansvarsfördelningen blir oklar.

Lägg inte till perfekt information i efterhand. Poängen är att se hur gruppen agerar med samma osäkerhet som vid en verklig incident.

Avsluta med tre förbättringar som får ansvarig och deadline. Övningen ska producera åtgärder, inte bara diskussion.

Vad behöver dokumenteras efter övningen?

Sammanfatta tidslinjen, besluten, de största hindren och vilka delar som fungerade. Uppdatera kontaktlistor, rollkort och tekniska instruktioner direkt medan erfarenheterna är färska.

Varje förbättring bör ha en ägare, ett slutdatum och en plan för hur den ska verifieras.

Följ upp åtgärderna vid nästa lednings- eller säkerhetsmöte och välj ett nytt scenario till nästa övning. På så sätt blir incidentplanen ett levande arbetssätt och inte en statisk pärm som bara tas fram efter att något redan har hänt.

Slutsats

En fungerande incidentkedja bygger på tydliga roller, tillgängliga kontaktvägar och regelbunden övning.

DSolution kan hjälpa er att översätta kraven till kontroller som går att se, äga och följa upp i den digitala arbetsplatsen – och identifiera de flaskhalsar som behöver lösas innan nästa incident.