Incidenthanteringsplan – så bygger företag en praktisk plan för cyberincidenter

Av Mallbutiken · Sakuppgifter kontrollerade 1 oktober 2026 · Cirka 9 minuters läsning

En incidenthanteringsplan beskriver hur organisationen agerar från första tecken på en cyberincident tills verksamheten är stabil, bevis är säkrade, nödvändig rapportering är genomförd och lärdomar är omsatta i åtgärder. Planen bör vara kort nog att kunna användas under stress men detaljerad nog för att eliminera tvekan om roller, kontaktvägar och beslut.

Vad ska en incidenthanteringsplan omfatta?

Planen bör gälla de händelser som kan påverka konfidentialitet, riktighet, tillgänglighet eller autenticitet i verksamhetens system och information. Exempel är ransomware, kontokapning, dataläckage, överbelastningsangrepp, komprometterad leverantör, felkonfiguration, sabotage och större driftstörningar.

Definiera en ingång för larm även när händelsen är osäker. Medarbetaren ska inte behöva avgöra om något juridiskt är en ”incident” innan det får rapporteras internt.

Roller och beslutsmandat – bestäm före incidenten

Incidenter förvärras ofta när alla väntar på samma chef. Sätt därför roller i förväg. En mindre organisation kan kombinera flera roller, men ansvaren behöver fortfarande vara tydliga.

Dokumentera även ersättare, journummer och hur incidentgruppen samlas om ordinarie kommunikationssystem inte fungerar.

Incidentflöde i åtta steg

1. Upptäck och registrera. Skapa incident-ID, tidpunkt, rapportör och första observation.
2. Triagera. Bedöm snabbt vilka system, data, användare och tjänster som kan vara berörda.
3. Klassificera och eskalera. Sätt preliminär allvarlighetsgrad och aktivera rätt roller.
4. Inneslut. Begränsa skadan utan att i onödan förstöra bevis eller försvåra återställning.
5. Analysera. Fastställ sannolik orsak, tidslinje, intrångsväg och omfattning.
6. Avhjälp. Ta bort orsak, stäng sårbarhet och verifiera att hotet inte kvarstår.
7. Återställ. Återför tjänster kontrollerat och förstärk övervakning.
8. Efteranalys. Dokumentera rotorsak, beslut, lärdomar och förbättringsåtgärder.

Skapa en enkel klassningsmodell

Klassningen behöver stödja beslut, inte bli en akademisk poängmodell. Bedöm exempelvis:

• om kritisk verksamhet är nere,
• hur många användare/kunder som påverkas,
• om personuppgifter eller annan skyddsvärd information kan ha röjts,
• om angriparen har privilegierad åtkomst,
• om incidenten sprider sig,
• om leverantörer eller andra organisationer påverkas,
• om regulatorisk rapportering kan aktualiseras.

Bestäm vilken nivå som automatiskt aktiverar ledning, juridik, dataskydd eller extern incidentpartner.

Bevara loggar och bevis utan att stoppa responsen

Under tidspress är det lätt att radera eller skriva över viktig information. Planen bör därför ange vem som säkrar relevanta loggar, snapshots, tidslinjer, e-post, kontohändelser och andra tekniska underlag. Dokumentera vem som gjort vad och när.

Bevisbehovet behöver balanseras mot kravet att begränsa pågående skada. Vid allvarliga incidenter kan extern forensisk kompetens behöva aktiveras tidigt.

Kommunikation och extern rapportering

Skapa separata kontaktlistor för myndigheter, incidentresponsleverantör, cyberförsäkring, kritiska IT-leverantörer, ledning och kommunikation. Förbered gärna mallar för en första intern lägesrapport och för beslutspunkter.

För verksamheter som omfattas av cybersäkerhetslagen gäller särskilda regler om rapportering av betydande incidenter. Lagen anger en första upplysning senast 24 timmar efter att verksamhetsutövaren fått kännedom om incidenten och därefter incidentanmälan enligt de tidsfrister som gäller för verksamhetstypen. Detaljerna behandlas separat i guiden om NIS2:s 24/72-timmarsflöde.

Återställning är mer än att slå på systemen

Definiera kriterier för när en tjänst får öppnas igen. Kontrollera att sårbarheten är åtgärdad, att privilegierade konton har säkrats, att återställd data är tillförlitlig och att övervakningen förstärks under en period.

Koppla återställningsordningen till verksamhetens BIA och kontinuitetsplan. Läs BIA steg för steg och vad en kontinuitetsplan ska innehålla.

Efteranalys: gör lärandet obligatoriskt

Efter incidenten bör organisationen dokumentera rotorsak, vad som fungerade, vad som fördröjde arbetet och vilka kontroller som behöver ändras. Varje åtgärd ska få ansvarig och deadline. Följ sedan upp att den verkligen genomförts.

Testa planen innan den behövs

En incidentplan som aldrig övats innehåller nästan alltid felaktiga telefonnummer, otydliga mandat eller antaganden om system som inte längre finns. Kör minst återkommande table-top-övningar där ledning, IT, verksamhet och relevanta stödfunktioner får hantera ett realistiskt scenario.

Variera scenarierna: ransomware, komprometterad SaaS-leverantör, läckt administratörskonto eller längre driftstopp. Uppdatera planen efter varje övning.

Checklista för planen

• En enda tydlig intern larmväg
• Roller, ersättare och mandat
• Kontaktuppgifter även utanför kontorstid
• Allvarlighetsnivåer och eskaleringskriterier
• Steg för inneslutning, analys och återställning
• Rutiner för loggar och bevis
• Beslutspunkt för NIS2 och annan myndighetsrapportering
• Beslutspunkt för GDPR/personuppgiftsincident
• Kommunikationsansvar internt och externt
• Koppling till BIA och kontinuitetsplan
• Efteranalys med ansvariga förbättringsåtgärder
• Övnings- och uppdateringsintervall

Behöver ni dokumentera incidentflödet?

Mallbutikens NIS2 Mallpaket 2026 innehåller integrerade mallar för bland annat incidenthantering, rapportering, riskhantering, kontinuitet och leverantörssäkerhet. Pris i butiken: 199 kr.

Se NIS2-mallpaketet