En incidenthanteringsplan måste klara tre saker samtidigt: ge rätt person mandat att fatta beslut inom minuter, leverera färdiga rapportmallar för 24 timmars-, 72 timmars- och 1 månads-tidsfristerna, och bygga på en process som personalen faktiskt har övat på. Utan de tre bitarna blir planen ett dokument som samlar damm i en pärm medan organisationen improviserar under press. MSB och NCSC/CERT‑SE sätter ramarna för vad som krävs, men det är detaljerna i mallarna och mandaten som avgör om planen håller när det gäller.
Kort sagt:
- En effektiv incidenthanteringsplan måste ha tydliga mandat för snabba beslut, färdiga rapportmallar och vara väl förankrad i personalens övningar.
- Planen ska innehålla konkreta instruktioner för upptäckt, bedömning, åtgärd, återställning och grundorsaksanalys, samt tydliga kontakt- och reservrutiner.
- Tydliga roller och mandat är avgörande, där varje funktion måste ha klart definierade befogenheter och beslutsnivåer för att agera snabbt.
- Rapportering enligt NIS2 kräver tidiga samt fullständiga incidentrapporter och slutrapporter inom 24, 72 timmar och en månad, samtidigt som GDPR-incidenter ska rapporteras inom 72 timmar.
- Regelbundna övningar och en koppling mellan incidentplanen och kontinuitetsplanen är nyckeln för att organisationen ska kunna agera effektivt under en kris.
Innehållsförteckning
- Vad ska ingå i en incidenthantering plan?
- Hur gör man en incidenthantering plan i praktiken?
- Vilka roller och mandat behövs i incidentteamet?
- Vilka rapporteringskrav gäller enligt NIS2 och GDPR?
- Hur ofta bör organisationen öva planen?
- Hur hänger incidentplanen ihop med kontinuitetshanteringen?
- Hur genomför man en grundorsaksanalys efter en incident?
- Kan Evertrust hjälpa till med incidenthanteringsplan och NIS2‑krav?
- Jespers perspektiv: praktiska prioriteringar och vanliga fallgropar
- Behöver ni hjälp att bygga en operativ incidenthanteringsplan?
- Källor
- Vanliga frågor
Vad ska ingå i en incidenthantering plan?
En incidenthanteringsplan är inte en policy om säkerhet i allmänna ordalag. Det är ett operativt dokument som svarar på frågan “vad gör vi klockan tre på natten när larmet går” med konkreta instruktioner, inte principer.
Grunden är fem byggstenar som MSB:s metodstöd för informationssäkerhet pekar ut: upptäckt, bedömning, åtgärd, återställning och grundorsaksanalys. Dessa ska vävas in i det systematiska säkerhetsarbetet, inte hanteras som en isolerad krismapp.
Konkret bör planen innehålla:
- Syfte, ägare och omfattning – vem äger dokumentet, vilka system och verksamheter täcks, och vilka kriterier utlöser att planen aktiveras.
- Kontaktlistor och externa resurser – juridisk rådgivning, forensisk expertis, leverantörskontakter och avtal som redan är påskrivna innan krisen är här.
- Färdiga rapportmallar – separata mallar för 24 timmars-upplysningen, 72 timmars-anmälan, 1 månads-slutrapporten samt en intern lägesrapport och en kommunikationsmall för externa budskap.
- Reservrutiner och återgångskriterier – vad som händer med verksamheten medan system är nedstängda, och vilka villkor som måste uppfyllas innan drift återgår till normalläge.
- Operativa checklistor och loggrutiner – steg för steg-instruktioner för de första timmarna, med tydliga fält för vem som loggade vad och när.
Poängen med att skriva mallarna i förväg är enkel: ingen ska behöva formulera en juridiskt korrekt anmälan medan systemen brinner. Texten ska bara fyllas i.
Hur gör man en incidenthantering plan i praktiken?
En incidenthanteringsplan fungerar bäst som ett faskopplat flöde snarare än en lång checklista. Ett praktiskt sexfasramverk, populärt bland svenska tech‑bolag, delar in arbetet i förberedelse, identifiering, avgränsning, utrotning, återställning och lärdomar, enligt SIAX. Varje fas har ett tydligt mål och en tydlig ägare.
- Förberedelse. Se till att loggning fungerar, att kontaktvägar är aktuella och att varje roll vet sitt ansvar innan något händer. Detta är den fas som oftast glöms bort, och samtidigt den som avgör hur snabbt ni kommer i gång.
- Identifiering. Definiera skarpt vad som räknas som en incident, inte bara en avvikelse. En felkonfigurerad brandvägg är inte automatiskt en incident, men obehörig åtkomst till persondata är det nästan alltid. Validera larmet innan ni eskalerar.
- Avgränsning. Isolera det drabbade systemet utan att förstöra bevis. Det är här beslutsmandatet blir avgörande: vem får stänga av en server, och måste den personen invänta godkännande först? MSB betonar att avvägningen mellan att bevara forensiska spår och att stoppa skadan kräver tydliga mandat satta i förväg, inte improviserade beslut mitt i händelsen.
- Utrotning och sanering. Ta bort grundorsaken. Det kan betyda att återkalla komprometterade inloggningsuppgifter, patcha en sårbarhet eller nollställa ett angripet konto. Halvmesyrer här leder ofta till att samma incident återkommer inom veckor.
- Återställning. Verifiera att backuper är rena innan ni återställer, och gå tillbaka till drift stegvis snarare än allt på en gång. En återställning som sker för snabbt riskerar att återinföra samma sårbarhet.
- Efterarbete. Dokumentera händelsen, genomför grundorsaksanalys och omsätt lärdomarna i konkreta förbättringsåtgärder.
Proffstips: Öva alltid fas ett och två extra hårt. Om identifieringen är långsam eller otydlig spelar det ingen roll hur bra resten av planen är, för ni hinner aldrig dit.
Vilka roller och mandat behövs i incidentteamet?
En plan utan namngivna roller är ett önsketänkande. Minimum är fem funktioner som måste finnas, oavsett organisationens storlek:
- Incidentmottagare – tar emot första larmet och avgör om det ska klassas som incident.
- Åtgärdsansvarig – leder det tekniska arbetet med avgränsning, sanering och återställning.
- Kommunikatör – ansvarar för både intern lägesinformation och extern kommunikation till kunder, media eller myndigheter.
- Juridisk kontakt – bedömer rapporteringsskyldighet enligt cybersäkerhetslagen och GDPR, och godkänner formuleringar i anmälningar.
- Ledningskontakt – informerar VD eller styrelse och fattar beslut som kräver högre mandat, till exempel att stänga en hel produktionslinje.
Mandatet måste vara skrivet, inte underförstått. Ange konkret vilka beslut varje roll får fatta självständigt, exempelvis att åtgärdsansvarig får stänga av ett enskilt system utan föregående godkännande, medan att stänga hela nätverket kräver ledningskontaktens signatur. Sätt också en tydlig eskaleringströskel: vid vilken allvarlighetsgrad informeras ledningen omedelbart i stället för i nästa statusmöte. MSB pekar ut ledningens engagemang som avgörande. Utan tydliga beslutsbefogenheter bromsas insatsen just när tempo räknas mest.
Vilka rapporteringskrav gäller enligt NIS2 och GDPR?
Cybersäkerhetslagen, som implementerar NIS2 i svensk rätt, sätter tre hårda tidsfrister för organisationer som omfattas av lagen. NCSC/CERT‑SE beskriver processen så:
- Inom 24 timmar – en tidig upplysning som anger att en betydande incident inträffat, ofta med begränsad information.
- Inom 72 timmar – en fullständig incidentanmälan med bedömning av allvarlighetsgrad, påverkan och eventuella tekniska indikatorer.
- Inom en månad – en slutrapport med detaljerad beskrivning av händelsen, grundorsak, vidtagna åtgärder och gränsöverskridande påverkan om sådan finns.
Kriterierna för vad som räknas som en betydande incident, inklusive gränsvärden för driftstörning och ekonomisk skada, finns preciserade i vägledningen för incidentrapportering enligt cybersäkerhetslagen. Organisationer bör slå upp sin egen sektors tröskelvärden snarare än att gissa.
Planens mallar måste redan innehålla fält för kontaktperson, preliminär bedömning av allvarlighetsgrad, tekniska indikatorer (IOC) och en uppskattning av påverkan. Att fylla i dessa fält under en pågående incident tar för lång tid om strukturen inte redan finns.
GDPR‑anmälan löper parallellt, inte efter. Om incidenten innebär en personuppgiftsincident, till exempel att obehöriga fått åtkomst till kunddata, gäller samma 72‑timmarslogik gentemot tillsynsmyndigheten, oberoende av cybersäkerhetslagens tidslinje. Många organisationer upptäcker sent att en och samma incident triggar båda regelverken samtidigt, vilket ett exempel från en advokatbyrå och ett ärende hos Kronofogden visar tydligt. Dokumentera alltid kostnadsuppskattning, antal påverkade system och antal berörda användare. Ledningen kommer att fråga, och tillsynsmyndigheten kräver det oftast i sin bedömning.
Hur ofta bör organisationen öva planen?
En plan som aldrig testas mot verkligheten är i praktiken en gissning. MSB:s vägledning lyfter övning som en av de mest avgörande faktorerna för om en organisation klarar en riktig incident.
Tre övningsformer täcker olika behov:
- Skrivbordsövning – teamet går igenom ett scenario muntligt runt ett bord, utan att röra faktiska system. Kör detta halvårsvis; det är billigt och avslöjar snabbt luckor i mandat och kontaktvägar.
- Teknisk övning – ett simulerat angrepp mot en testmiljö, där verktyg och loggning faktiskt används skarpt. En gång per år räcker för de flesta organisationer.
- Fullskalig simulering – hela organisationen, inklusive ledning och kommunikation, agerar som om incidenten var verklig. Detta bör ledningen genomgå minst en gång per år, ofta kopplat till styrelsens riskgenomgång.
Dokumentera varje övning med samma struktur som en riktig incident: vad fungerade, vad tog för lång tid, och vilka luckor upptäcktes. Mata sedan in resultaten i en åtgärdsplan med ägare och deadline, annars upprepas samma brister nästa gång.
Proffstips: Ett enkelt scenario att börja med är ett läckt lösenord till ett administratörskonto. Det är realistiskt, kräver ingen avancerad teknisk kulisser, och testar både identifiering och eskalering på under en timme.
Hur hänger incidentplanen ihop med kontinuitetshanteringen?
Incidentplanen och kontinuitetsplanen löser olika problem. Incidentplanen svarar på “hur stoppar vi och åtgärdar hotet”, medan kontinuitetsplanen svarar på “hur håller vi verksamheten flytande medan det pågår”. MSB:s kontinuitetsplan och lathund listar reservrutiner, återställningsrutiner, återgångsrutiner och kontaktuppgifter som kärnkomponenter.
Problemet uppstår när de två planerna inte pratar med varandra. En incidenthanteringsplan som saknar koppling till kontinuitetsplanen skapar ofta förvirring just i aktiveringsögonblicket, eftersom ingen vet om kontinuitetsplanen ska triggas samtidigt eller efteråt. Lösningen är en enkel aktiveringsmatris: vid vilken allvarlighetsgrad eller vilken systempåverkan utlöser incidenten automatiskt kontinuitetsplanen.
- Ange i planen vem som äger beslutet att aktivera reservrutiner.
- Dokumentera återgångskriterier tydligt, det räcker inte att systemet “verkar” fungera igen.
- Om en enskild verksamhetsgren behöver en egen operationsplan utöver den övergripande planen, ange det explicit, till exempel för en produktionslinje med egna säkerhetskrav.
- Kommunikationen till personal och kunder ska ske parallellt från båda planerna, inte i två separata spår som säger olika saker.
Hur genomför man en grundorsaksanalys efter en incident?
Grundorsaksanalysen (RCA) ska påbörjas inom en vecka efter att incidenten är avslutad, medan detaljerna fortfarande är färska. Ansvaret ligger normalt hos åtgärdsansvarig, med stöd från incidentmottagaren.
- Strukturera rapporten med fyra fält: fynd, trolig grundorsak, rekommenderade åtgärder samt ansvarig person och tidsplan för varje åtgärd.
- Prioritera åtgärder efter riskreducering, genomförbarhet och kostnad, inte efter vad som är enklast att implementera.
- Fokusera på grundorsaken snarare än symptomen. MSB understryker att detta minskar risken för att samma incident upprepas.
- Förankra resultaten hos ledningen och mata in dem i revisionsplanen, annars stannar lärdomarna på en hylla.
Kan Evertrust hjälpa till med incidenthanteringsplan och NIS2‑krav?
Vi bistår organisationer med att bygga incidenthanteringsplaner som faktiskt fungerar operativt, inte bara på papper. Det handlar om färdiga mallar för 24‑, 72‑timmars- och enmånadsrapportering, kompletta övningspaket för skrivbordsövningar och ledningssimuleringar, samt praktisk vägledning kring NIS2 och GDPR‑skyldigheter.
Vi har kompetens inom GDPR, cybersäkerhetslagen, incidentrådgivning och rollen som interim dataskyddsombud, vilket möjliggör en helhetsbild från teknisk incident till juridisk rapporteringsplikt. Fördjupning i vad NIS2 kräver konkret 2026 ger en bra utgångspunkt för organisationer som ännu inte har kartlagt sina skyldigheter.
Behöver ni en skräddarsydd genomgång av er befintliga plan, eller hjälp att bygga en från grunden, går det att boka ett samtal direkt med en rådgivare för en konkret behovsanalys.
Jespers perspektiv: praktiska prioriteringar och vanliga fallgropar
Det vanligaste misstaget jag ser är att organisationer lägger all energi på teknisk perfektion, brandväggsregler, loggningsverktyg, SIEM‑konfiguration, men glömmer att skriva ut vem som faktiskt får fatta beslutet att stänga ett system klockan två på natten. Mandatet är viktigare än verktyget. Det andra återkommande felet är att incidentplanen lever i sitt eget dokument, helt frikopplad från kontinuitetsplanen, vilket skapar dubbelarbete och förvirring just när tempo räknas mest. Börja där: skriv mandaten konkret, koppla ihop de två planerna, och boka in första skrivbordsövningen inom en månad.
— Jesper
Behöver ni hjälp att bygga en operativ incidenthanteringsplan?
Många organisationer försöker skriva sin incidenthanteringsplan internt utifrån en generisk mall hämtad från nätet, och upptäcker först under en skarp incident att mandaten är otydliga eller att rapportmallarna saknar de fält cybersäkerhetslagen faktiskt kräver. Vi erbjuder ett upplägg med juridisk och teknisk kompetens i samma leverans, så att planen håller både operativt och rättsligt från dag ett.
Genom rådgivning och konsulttjänster kan ni få hjälp att bygga hela planen, inklusive färdiga rapportmallar och skräddarsydda övningar, eller köpa löpande incidentrådgivning som finns tillgänglig när det verkligen behövs. Om ni redan har en plan men misstänker att den har luckor, är en genomlysning via GAP‑analyser och säkerhetsgranskningar ett snabbare sätt att hitta bristerna än att vänta på nästa incident för att upptäcka dem. Boka ett kort möte för en behovsanalys, så går ni igenom var er nuvarande plan står och vad som saknas för att klara aktuella regulatoriska krav.
Källor
- Incidenthantering
- Rapportera en betydande incident enligt cybersäkerhetslagen (NIS2)
- Skydd av samhällsviktig verksamhet
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
Vanliga frågor
Vad är skillnaden mellan incidentplan och krishanteringsplan?
En incidenthanteringsplan fokuserar på att upptäcka, avgränsa och åtgärda en specifik teknisk eller säkerhetsrelaterad händelse. En krishanteringsplan är bredare och omfattar hela organisationens agerande vid allvarliga händelser, inklusive sådana som inte är IT‑relaterade.
Hur snabbt måste vi rapportera en incident enligt NIS2?
Cybersäkerhetslagen kräver en tidig upplysning inom 24 timmar, en fullständig incidentanmälan inom 72 timmar och en slutrapport inom en månad, enligt NCSC:s vägledning. Tidsfristerna gäller organisationer som omfattas av lagens tillämpningsområde.
Måste vi ha en separat plan för GDPR‑incidenter?
Nej, men planen måste innehålla tydliga rutiner för att bedöma om en incident även utgör en personuppgiftsincident enligt GDPR, eftersom rapporteringsskyldigheten mot tillsynsmyndigheten löper parallellt med cybersäkerhetslagens tidslinje.
Hur ofta ska vi öva incidenthanteringsplanen?
En rimlig rytm är skrivbordsövning halvårsvis, teknisk övning en gång per år och en fullskalig ledningssimulering årligen. MSB pekar ut övning som en av de viktigaste faktorerna för att planen faktiskt fungerar under press.
Kan Evertrust hjälpa oss att skriva och öva vår incidenthanteringsplan?
Ja, Evertrust erbjuder både rådgivning för att bygga planen och praktiska övningar kopplade till NIS2‑ och GDPR‑krav. Aktuella priser för rådgivning och konsulttjänster finns tillgängliga direkt på webbplatsen.
