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 NCSC vid FRA om en betydande incident så snart det kan ske, dock senast inom 24 timmar från det att verksamhetsutövaren fick kännedom om incidenten. Verksamhetsutövare som inte tillhandahåller betrodda tjänster ska därefter göra en incidentanmälan senast inom 72 timmar från samma tidpunkt. För verksamhetsutövare som tillhandahåller betrodda tjänster är tidsfristen i stället 24 timmar. En slutrapport ska normalt lämnas senast en månad efter incidentanmälan. Om incidenten fortfarande pågår ska en lägesrapport lämnas vid denna tidpunkt och en slutrapport inom en månad efter att incidenten har hanterats.

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 som har observerats, vilka system och tjänster som kan vara berörda, när händelsen upptäcktes, vilka begränsande åtgärder som redan har tagits och vilken verksamhetspåverkan som 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 och vem deltar i en incidentövning?

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

Kontrollera dessutom hur eskaleringen fungerar utanför kontorstid och 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?

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. Midpoint kan hjälpa er att göra efterlevnad hanterbar genom att samla ansvar för drift, Microsoft 365 och dataskydd och identifiera de flaskhalsar som behöver lösas innan nästa incident.