Incidenthantering är processen att identifiera, hantera och åtgärda säkerhetshändelser som stör verksamheten eller riskerar att exponera känslig information. Målet är att minimera skador, återställa normal drift snabbt och förebygga att samma incident inträffar igen.
Kostnaden för en incident beror på vilka tjänster som påverkas, avbrottets längd och återställningen som krävs. Nedan går vi igenom de fem stegen i en incidenthanteringsprocess, vilka rutiner som måste finnas på plats och när det är dags att gå från kalkylblad till systemstöd.
Vad är en incident?
En anställd kanske inte kan öppna sina kundfiler. Någon kanske har skickat känsliga avtalsuppgifter till fel person. Det är exempel på säkerhetsincidenter: händelser som stör verksamheten eller riskerar att röja känslig information.
En incident kan vara allt från ett ransomware-angrepp som krypterar företagets data till ett oväntat systemavbrott som hindrar er från att leverera tjänster till kunder. Det avgörande är inte hur omfattande problemet är, utan hur det påverkar er förmåga att bedriva verksamheten.
Många organisationer reagerar bara på stora, uppenbara hot. Men återkommande små incidenter – som användare som blir utelåsta eller system som går ner – är ofta första tecknet på större sårbarheter. Fånga upp varningssignalerna tidigt för att förebygga allvarligare problem.
Proaktiv incidenthantering lönar sig
När säkerhetsproblem uppstår är det lätt att hamna i brandkårsutryckningar med stressade programmerare som försöker lösa akuta problem mitt i natten. Men det finns ett bättre sätt att arbeta som både sparar pengar och minskar stressen.
Genom att systematiskt dokumentera och analysera även mindre incidenter kan du ofta upptäcka problem innan de blir kritiska. Ett exempel är när samma typ av driftstörningar återkommer, det kan vara första tecknet på att en server behöver uppgraderas eller att användarna behöver bättre rutiner.
För mindre verksamheter handlar det inte om att implementera dyra system, utan om att börja i rätt ände med enkla rutiner som sedan kan utvecklas. Det viktiga är att komma igång och sedan förbättra processen steg för steg baserat på verkliga behov.
Hur ser en incidenthanteringsprocess ut?
En incidenthanteringsprocess består av fem steg: förberedelse, identifiering, åtgärd, återställning och lärdomar. Stegen hjälper dig fånga upp, hantera och lära dig av säkerhetsrelaterade händelser i företaget.
1. Förberedelse och planering
Börja bygga din incidenthantering innan något händer. Fokusera på:
- En tydlig ansvarsfördelning där alla vet sin roll.
- Ett enkelt system för att dokumentera incidenter.
- Uppdaterade kontaktvägar till kritiska partners.
Det viktiga är inte att ha perfekta rutiner från start, utan att börja någonstans och successivt förbättra processen baserat på faktiska erfarenheter. Vill ni inte börja från ett blankt papper finns vår kostnadsfria mall för incidenthanteringsplan att utgå ifrån.
2. Identifiering och initial bedömning
Ju tidigare en incident upptäcks, desto större chans har du att begränsa skadan. Skapa därför tydliga rutiner för hur avvikelser ska rapporteras och bedömas.
En enkel men effektiv modell för bedömning kan vara:
- Påverkan på verksamheten (Kritisk/Hög/Medel/Låg)
- Spridningsrisk (Kan detta påverka andra system?)
- Återställningstid (Hur länge kan vi vara utan denna funktion?)
Det handlar om att snabbt kunna avgöra vilka incidenter som kräver omedelbara åtgärder och vilka som kan hanteras inom ordinarie arbetsflöden. En strukturerad riskbedömning hjälper dig att prioritera rätt.
3. Åtgärda incidenter
När en incident upptäcks krävs ett snabbt agerande. Det första och viktigaste steget är att begränsa spridningen.
Om en dator visar tecken på skadlig kod, koppla bort den från nätverket. Är du osäker på omfattningen? Då är det bäst att ta det säkra före det osäkra och isolera berörda system tills du har en bättre bild av läget.
Dokumentera också medan du arbetar. Ta skärmdumpar och anteckna det väsentliga: När upptäcktes incidenten? Vilka system påverkas? Vilka åtgärder vidtas? Detta hjälper dig både nu och i det förebyggande arbetet.
4. Återställning
Återställningen handlar om två delar: att få systemet i drift igen och att minska risken för att samma incident återkommer.
Börja med att verifiera grundläggande säkerhet, har några lösenord komprometterats? Finns det ytterligare sårbarheter som behöver åtgärdas? Dokumentera vad du gör.
Under återställningen kan du tänka på följande tre principer:
- Återställ system stegvis och kontrollerat.
- Verifiera säkerheten innan normal drift återupptas.
- Dokumentera alla förändringar som genomförs.
5. Kontinuerligt lärande och förbättring
Detta är kanske den allra viktigaste delen inom incidenthantering: att faktiskt lära sig av det som hänt. Tyvärr hamnar många incidentrapporter i en mapp som ingen öppnar förrän nästa incident inträffar – om ens då.
Det behöver inte ens vara så svårt, utan det kan räcka med 30 minuter. Efter varje incident, ta 30 minuter med teamet och gå igenom tre enkla frågor:
- Vad fungerade bra i vår hantering?
- Var stötte vi på problem?
- Vilken konkret förbättring skulle göra störst skillnad?
Samla sedan svaren i samma system där ni dokumenterar incidenterna. När du ser samma typ av problem återkomma blir det lättare att motivera förebyggande åtgärder.
Fokusera också på de små, konkreta förbättringar som du faktiskt genomför. Detta gör att du hela tiden bygger en starkare säkerhetskultur, incident för incident.
Vilka rutiner behövs för incidenthantering?
Processen beskriver flödet. Rutinerna är de konkreta instruktionerna som gör flödet möjligt att följa när något faktiskt händer. Fyra rutiner bär det mesta av arbetet:
- Rapporteringsrutin: Hur en medarbetare larmar om en misstänkt incident, och till vem. Ska fungera även när mejlen ligger nere – ange ett telefonnummer som reserv.
- Klassificeringsrutin: Vem som sätter allvarlighetsgrad, och enligt vilka kriterier. Utan den fastnar bedömningen hos den som råkade upptäcka problemet.
- Eskaleringsrutin: När ledning, styrelse eller kunder ska informeras, och vem som fattar det beslutet. Definiera tröskeln i förväg, inte under pågående incident.
- Anmälningsrutin: Vem som kontaktar myndighet, och inom vilken tidsfrist. Här skiljer sig både mottagare och frister mellan regelverken: CSIRT enligt de svenska cybersäkerhetsreglerna och Integritetsskyddsmyndigheten enligt GDPR. Se cybersäkerhetslagen, 2 kap. 5–8 §§ och GDPR artikel 33.
Skriv rutinerna kort nog att de faktiskt läses under press. En sida per rutin är oftast rätt ambition, och de bör testas minst en gång per år genom en enkel genomgång vid bordet.
När behövs ett incidenthanteringssystem?
Börja enkelt. Ett delat formulär räcker för de första månaderna – så länge varje incident faktiskt registreras och ingen löses muntligt vid kaffemaskinen.
Behovet av ett dedikerat incidenthanteringssystem uppstår i regel när något av följande blir sant:
| Situation | Varför kalkylbladet börjar svikta |
|---|---|
| Ni omfattas av NIS2 eller DORA | Korta rapporteringsfrister behöver bevakas per incident, inte hittas i efterhand |
| Revisor efterfrågar historik | Spårbarhet från upptäckt till stängd åtgärd ska kunna visas utan att leta i mejltrådar |
| Fler än en person tar emot larm | Utan gemensam kö tappas incidenter mellan ansvariga |
| Samma incident återkommer | Mönstret syns bara om händelserna klassificerats likadant över tid |
Den återkommande incidenten är också den som ska leda vidare. När en händelse upprepas hör den hemma som en risk i riskregistret med en åtgärd som har en ansvarig och ett datum – annars stannar arbetet vid att incidenten dokumenterats.
Om ni omfattas av NIS2 finns det även särskilda krav på incidentrapportering som ni måste följa. Vänta inte med förberedelserna till den dagen en incident redan pågår – utse en ansvarig, dokumentera processen och testa den minst en gång per år.
Vanliga frågor
Vad är en säkerhetsincident?
En säkerhetsincident är en händelse som hotar eller kan hota informationens konfidentialitet, riktighet eller tillgänglighet. Det kan vara allt från en lyckad phishing-attack och ett ransomware-utbrott till en oavsiktlig dataläcka eller obehörig åtkomst till känsliga system.
Vilka incidenter måste rapporteras enligt NIS2?
Verksamheter som omfattas ska rapportera betydande incidenter. Det gäller incidenter som orsakat eller kan orsaka allvarlig driftsstörning eller ekonomisk förlust för verksamheten, eller betydande materiell eller immateriell skada för andra. Bedömningen måste göras mot reglerna som gäller er verksamhet; alla säkerhetshändelser är inte rapporteringspliktiga.
Hur snabbt måste en NIS2-incident rapporteras?
Huvudregeln är en tidig varning inom 24 timmar och en incidentanmälan inom 72 timmar efter att verksamheten fått kännedom om en betydande incident. Slutrapport lämnas senast en månad efter incidentanmälan. Pågår incidenten då lämnas en lägesrapport och därefter slutrapport inom en månad efter att incidenten hanterats. För betrodda tjänster gäller en särskild 24-timmarsfrist för incidentanmälan.
Vad ska ingå i en incidenthanteringsplan?
Planen ska ange vem som gör vad vid en incident, vem som ska kontaktas och när fler ansvariga ska kopplas in. Beskriv hur ni bedömer hur allvarlig incidenten är. Ha rutiner för att förbereda er, upptäcka incidenter, begränsa skadan, ta bort hotet, återställa driften och dra lärdomar. Ta också fram mallar för information inom och utanför företaget. Testa planen regelbundet genom att tillsammans gå igenom ett tänkt scenario, en så kallad tabletop-övning.
Vad är skillnaden mellan en incidenthanteringsprocess och en rutin?
Processen beskriver hela flödet från upptäckt till lärdomar och vem som ansvarar för varje steg. En rutin är den konkreta instruktionen för ett enskilt moment i flödet, exempelvis hur en medarbetare rapporterar en misstänkt incident eller hur ett drabbat system isoleras. Processen ger strukturen, rutinerna gör den möjlig att följa i praktiken.
Behöver man ett system för incidenthantering?
Inte från start. Ett delat formulär och ett kalkylblad räcker långt för de första månaderna, förutsatt att alla incidenter faktiskt registreras. Behovet av ett dedikerat incidenthanteringssystem uppstår när ni behöver bevaka rapporteringsfrister per incident, se mönster i återkommande händelser och visa en revisor historiken utan att leta i mejltrådar.
Måste incidenter rapporteras enligt både NIS2 och GDPR?
Båda rapporteringsskyldigheterna kan gälla samma händelse. En betydande incident hos en verksamhet som omfattas av NIS2 ska rapporteras enligt cybersäkerhetsreglerna. En personuppgiftsincident ska dessutom anmälas till IMY inom 72 timmar efter kännedom, om det inte är osannolikt att den medför risk för de registrerades rättigheter och friheter. Att en händelse berör personuppgifter räcker inte i sig för att utlösa anmälningsplikt.
