Incidenthantering: så bygger du en process och en plan som fungerar

Incidenthantering låter som något för stora organisationer med säkerhetscenter och jourlistor. I praktiken har varje företag redan en, frågan är bara om den är planerad eller improviserad. Här går vi igenom processen, prioriteringen och rollerna, och sist finns en incidenthanteringsplan som du kan kopiera rakt av. Den är en del av guiden om IT-säkerhet för företag.

Vad är incidenthantering?

Incidenthantering är processen för att ta hand om en incident från det att någon märker den tills den är löst och utredd. ITIL, det ramverk för IT-tjänster som de flesta IT-avdelningar och leverantörer utgår från, definierar en incident som ett oplanerat avbrott i en tjänst eller en försämring av tjänstens kvalitet. Mer om ramverket finns i ITIL förklarat.

Det finns två sorters incidenter, och de hanteras i samma process men med olika tyngd:

• IT-incidenter. Något slutar fungera. Mejlen går inte fram, affärssystemet är nere, wifi på lagret har dött. Ingen har gjort något med flit, och målet är att få igång det igen så fort som möjligt.
• Säkerhetsincidenter. Någon har gjort eller försökt göra något de inte får. Ett konto har tagits över, en medarbetare har klickat på en länk i ett nätfiskemejl, filer krypteras. Här räcker det inte att få igång systemet. Du måste också förstå hur angriparen kom in, begränsa skadan och spara spåren.

En säkerhetsincident ser ofta ut som en vanlig IT-incident i början. En server som går trögt kan vara just det, eller en server där någon kopierar ut data. Därför ska processen alltid ställa frågan: kan det här vara ett angrepp?

Föreskrifterna till cybersäkerhetslagen, MCFFS 2026:11, beskriver samma logik i 17 §. Incidenter och tillbud ska kunna identifieras, anmälas, analyseras och begränsas, påverkad information och funktionalitet ska återställas i prioritetsordning, liknande incidenter ska förhindras och grundorsaken ska utredas vid behov. Enligt de allmänna råden ska personalen kunna rapportera på ett enkelt sätt. Omfattas du inte av lagen är det ändå en bra beskrivning av en fungerande process.

Vilka faser har incidenthanteringsprocessen?

Incidenthanteringsprocessen har sex faser som följer ungefär samma ordning varje gång. Amerikanska NIST betonar i sin senaste vägledning, SP 800-61 rev. 3, att hanteringen ska vara en del av hela säkerhetsarbetet och inte en isolerad kedja. För ett medelstort företag är faserna ändå det mest användbara sättet att tänka.

1. Upptäcka. Någon märker något. Det kan vara en användare, ett larm från övervakningen eller en kund som ringer. Det viktigaste i den här fasen är att det är enkelt och ofarligt att säga till. Den som är rädd för att ha gjort fel väntar, och väntan är dyr.
2. Bedöma och prioritera. Vad har hänt, vad påverkas och hur bråttom är det? Här avgörs också om det kan vara en säkerhetsincident. Prioriteringsmodellen nedan hjälper.
3. Begränsa. Stoppa spridningen innan du lagar. Koppla bort en angripen dator från nätverket, spärra ett kapat konto, stäng en funktion som läcker. Vid säkerhetsincidenter: stäng inte av datorer i onödan och radera ingenting, spåren behövs.
4. Åtgärda. Ta bort orsaken. Byt lösenord, patcha sårbarheten, ta bort den skadliga koden, byt trasig hårdvara.
5. Återställa. Få tillbaka system och information, i den ordning verksamheten behöver dem. Återställ inte från backup förrän du vet att angriparen är ute, annars återställer du rakt in i samma problem. Hur du planerar återställningen i stort står i disaster recovery.
6. Följa upp och lära. Vad hände, varför, och vad ändrar vi? Den här fasen hoppas oftast över, eftersom alla är trötta och glada att det fungerar igen. Det är också den enda fasen som gör nästa incident mindre.

Genom alla faser löper en sak till: loggen. Skriv ned klockslag, vad som upptäcktes, vad som beslutades och av vem. Den behövs för uppföljningen, för försäkringen och om incidenten visar sig vara rapporteringspliktig.

Hur prioriterar du en incident?

Prioritet bestäms av två saker: påverkan, alltså hur många och hur viktiga delar av verksamheten som drabbas, och brådska, alltså hur snabbt det blir värre. Det är den vanliga modellen i ITIL och i de flesta service desk-verktyg.

Påverkan / Brådska	Hög brådska	Medel brådska	Låg brådska
Hög påverkan (hela företaget eller en kritisk tjänst)	P1 Kritisk	P2 Hög	P3 Medel
Medel påverkan (en avdelning eller en viktig funktion)	P2 Hög	P3 Medel	P4 Låg
Låg påverkan (en person, det finns en väg runt)	P3 Medel	P4 Låg	P4 Låg

Bestäm i förväg vad varje nivå betyder för dig. Ett påhittat men typiskt exempel: ett åkeri med 40 anställda bestämmer att P1 innebär att incidentledaren ringer in all hjälp som behövs direkt, dygnet runt, medan P4 får vänta till nästa arbetsdag. Svarstiderna är ditt eget beslut, men de ska stå i planen och stämma med vad din IT-leverantör faktiskt har åtagit sig.

En regel som är värd att skriva in: alla misstänkta säkerhetsincidenter börjar som P2 eller högre tills någon har konstaterat motsatsen. Det är billigare att nedgradera än att upptäcka för sent.

Vem gör vad?

En incident behöver fyra roller, och i ett mindre företag kan samma person ha flera av dem. Det viktiga är att de är namngivna i förväg och har en ersättare.

• Incidentledare. Leder arbetet och fattar besluten, till exempel om ett system ska stängas eller om extern hjälp ska tas in. Det behöver inte vara den mest tekniska personen, snarare den som kan hålla lugnet och säga "vi gör så här".
• Tekniskt ansvarig. Utreder, begränsar och åtgärdar. Ofta din IT-avdelning eller IT-leverantör.
• Kommunikationsansvarig. Informerar personal, ledning, kunder och vid behov myndigheter. Ser till att ingen annan pratar med media.
• Loggförare. För loggen med klockslag. Låter som en bisak, men är det som gör uppföljning och eventuell rapportering möjlig.

Ledningen informeras vid allvarliga incidenter och fattar besluten som går utöver incidentledarens mandat. Skriv ned var den gränsen går.

Mall: incidenthanteringsplan

Här är en incidenthanteringsplan i sin helhet. Kopiera den, fyll i fälten och skriv ut den. En plan som bara finns på en server som är nere hjälper ingen.

1. Syfte och omfattning Planen gäller alla incidenter som påverkar [företagets namn]s IT-system, information eller tjänster, både IT-incidenter och säkerhetsincidenter. Planen ägs av [namn, roll] och ses över minst en gång per år.

2. Så larmar du Alla anställda larmar vid misstänkt incident via: [telefonnummer], [e-post eller kanal]. Det är alltid rätt att larma, även om det visar sig vara falskt larm.

3. Roller och kontakter

Roll	Namn	Telefon	Ersättare
Incidentledare
Tekniskt ansvarig
Kommunikationsansvarig
Loggförare
Ledning (vd eller motsvarande)

4. Externa kontakter

Kontakt	Nummer eller adress
IT-leverantör, jour
Leverantör affärssystem
Internetleverantör
Försäkringsbolag, skadeanmälan
CERT-SE (stöd, dygnet runt)	010-382 80 00
Polisen	114 14

5. Prioritering Prioritet sätts enligt matrisen påverkan × brådska. Misstänkt säkerhetsincident är alltid lägst P2. Svarstider: P1 [fyll i], P2 [fyll i], P3 [fyll i], P4 [fyll i].

6. Mandat Incidentledaren får utan att fråga: koppla bort enheter från nätverket, spärra konton, stänga externa tjänster och anlita extern hjälp upp till [belopp]. Beslut utöver det tas av [roll].

7. Arbetsgång Upptäcka, bedöma och prioritera, begränsa, åtgärda, återställa, följa upp. Vid misstänkt säkerhetsincident: stäng inte av datorer i onödan, radera ingenting, återställ inte från backup innan orsaken är känd.

8. Rapporteringsplikt Vid varje P1 och P2 bedömer [roll] inom [antal] timmar om incidenten ska rapporteras till NCSC enligt cybersäkerhetslagen och om det är en personuppgiftsincident som ska anmälas till IMY.

9. Logg Loggen förs i [var, till exempel ett delat dokument och på papper]. Varje post: klockslag, vad som hänt, beslut, vem.

10. Uppföljning Inom [antal] arbetsdagar efter en P1 eller P2 hålls ett uppföljningsmöte. Frågor: vad hände, varför, vad fungerade, vad ändrar vi och vem ansvarar för det.

11. Övning Planen övas minst en gång per år, senast [datum]. Nästa översyn: [datum].

Hantering eller rapportering?

Incidenthantering och incidentrapportering är två olika saker som lätt blandas ihop. Hanteringen är ditt interna arbete med att lösa incidenten. Rapporteringen är skyldigheten att berätta för en myndighet om den, och den gäller bara vissa incidenter hos vissa verksamheter.

En incident blir rapporteringspliktig i två huvudfall. Omfattas du av cybersäkerhetslagen och incidenten är betydande ska den rapporteras till NCSC, med korta tidsfrister som börjar när du identifierat incidenten. Det finns en egen genomgång i incidentrapportering enligt NIS2. Berörs personuppgifter kan det vara en personuppgiftsincident som ska anmälas till IMY, se GDPR och IT-säkerhet. En incident kan utlösa båda.

Det praktiska rådet är att bygga in frågan i hanteringen, som punkt 8 i mallen gör. Då blir rapporteringen ett beslut i en rutin i stället för något någon kommer på dagen efter.

Vem bestämmer klockan två på natten?

En plan som aldrig har övats är en förhoppning. Det första som spricker är sällan tekniken, utan att ingen vet om det är okej att stänga av e-posten för hela företaget, eller vem som ringer försäkringsbolaget. Tekniken går att köpa in. Tydligheten om vem som bestämmer måste du bygga själv. Fyll i mallen, sätt av en timme med dem som står i den och gå igenom ett scenario, till exempel ett ransomwareangrepp en fredagskväll. Luckorna du hittar där är de du inte hittar klockan två på natten.

Så hjälper Nod till

Nod hjälper dig att fylla i incidenthanteringsplanen och hålla en första övning, kostnadsfritt i ett första samtal. Driftar Nod din IT-miljö tar vi rollen som tekniskt ansvarig vid incidenter, för loggen över det tekniska arbetet och tar fram underlaget till en eventuell rapport. [FYLL I: Nods tillgänglighet och svarstider vid incidenter] Läs mer om IT-drift hos Nod.