.webp)
.avif)
En cyberattack är inte längre en fråga om – det är en fråga om när. Ändå saknar många organisationer en dokumenterad plan för vad som ska göras när det väl händer. Det är ett dyrt misstag, både i tid och pengar.
Varför behöver ni en plan?
Utan en plan fattas beslut under press av personer som inte vet vad de ska göra, i vilken ordning eller vem de ska kontakta. Det syns i siffrorna: den genomsnittliga tiden att upptäcka ett intrång ligger på flera månader, och kostnaden för en incident utan strukturerad hantering är betydligt högre än för organisationer med en fungerande plan på plats.
NIS2 ställer också krav på dokumenterade incidenthanteringsrutiner för väsentliga och viktiga entiteter. En odokumenterad process räcker inte – direktivet förutsätter att planen är direktivet förutsätter att planen är dokumenterad, kommunicerad till rätt personer och faktiskt fungerar under press. Rapporteringsskyldigheterna inom 24 och 72 timmar är omöjliga att uppfylla utan att processen är på plats i förväg.
Vad ska planen innehålla?
En incidenthanteringsplan som faktiskt fungerar i skarpt läge behöver täcka följande:
- Scope och definition av incident. Vad räknas som en incident i er organisation? Utan en tydlig definition vet ingen när planen ska aktiveras. Definiera vad som krävs för att en händelse ska klassas som incident, och sätt kriterier för olika allvarlighetsnivåer.
- Roller och kontaktuppgifter. Vem gör vad när larmet går? Incidentledare, tekniskt team, juridik, kommunikation och ledning ska vara namngivna med aktuella kontaktuppgifter. Och se till att listan uppdateras kontinuerligt.
- Kommunikationsplan. Hur kommunicerar ni internt under en incident? Vad säger ni till kunder, leverantörer och eventuellt media? Vem har mandat att uttala sig externt?
- Tekniska runbooks. Steg-för-steg-instruktioner för de vanligaste incidenttyperna: ransomware, dataintrång, DDoS, kontokompromettering. Runbooks ska kunna följas av någon under stress, inte bara av den som skrev dem.
- Rapporteringskrav. Vilka myndigheter ska kontaktas, när och med vad? NIS2, GDPR och eventuella branschspecifika krav ska vara kartlagda med tidsfrister.
- Återställningsrutiner. Hur återställer ni system och data? Från vilka backuper? I vilken ordning återansluts system? Vem godkänner att ett system är rent nog att tas i drift igen?
- Lessons learned-process. Vad händer efter incidenten? Hur dokumenterar ni lärdomar, uppdaterar planen och säkerställer att samma sårbarhet inte utnyttjas igen?
Läs vår guide: Så funkar incidenthantering — steg för steg
Ladda ner vår mall
Vi har tagit fram en mall för incidenthanteringsplan anpassad för svenska organisationer och NIS2-krav. Mallen täcker samtliga kärnkomponenter ovan och är strukturerad för att kunna anpassas oavsett om ni är ett mindre bolag eller en stor organisation med komplex infrastruktur.
Den innehåller instruktioner för varje sektion, exempel på formuleringar och en checklista för att verifiera att ingenting missats.
Så anpassar ni mallen till er organisation
En mall ger er strukturen, men den behöver anpassas efter er faktiska miljö, era system och era roller.
- Bransch och regulatoriska krav. Finans, vård och kommunal sektor har specifika krav utöver NIS2 och GDPR. Identifiera vilka regelverk som gäller er och se till att rapporteringsrutinerna speglar dem.
- Företagsstorlek och organisation. I en mindre organisation bär ofta samma person flera roller. Det är okej, men planen måste reflektera det. Vem är backup om incidentledaren är den som är drabbad eller otillgänglig?
- Teknisk miljö. On-prem och molnmiljöer hanteras olika vid en incident. Kontaktuppgifter till molnleverantörer, SLA:er för incidentstöd och rutiner för att låsa konton i externa tjänster ska vara dokumenterade.
- Kritiska system. Vilka system är affärskritiska? Vilka processer stannar av om de är nere? Prioriteringsordningen för återställning ska vara explicit – den ska inte behöva diskuteras mitt i en incident.
Testa planen regelbundet – tabletop-övningar
En otestad plan är inte en plan, det är ett dokument. De flesta organisationer som har en incidenthanteringsplan har aldrig kört igenom den. Det innebär att första gången planen används på riktigt är under en faktisk kris.
En tabletop-övning är ett bra första steg – ett strukturerat scenariospel där incidentteamet går igenom ett realistiskt angreppsscenario utan att faktiska system påverkas. Ni testar kommunikationsvägar, beslutsprocesser och tekniska rutiner och identifierar hålen i processen.
Vill ni ta det ett steg längre är red teaming det mest realistiska sättet att testa om er plan faktiskt håller. Cyloq genomför red team-övningar med verkliga angreppsmönster – ransomware, supply chain-angrepp, insiderhot och riktade intrång – där systemen faktiskt utsätts för press. Det ger ett betydligt mer realistiskt underlag för att förbättra både den tekniska säkerheten och incidentberedskapen.
Rekommenderad frekvens för testning är minst en gång per år, och alltid efter större förändringar i organisation eller infrastruktur.
Integrera planen i SOC- eller MSSP-avtal
Har ni en extern SOC eller MSSP måste incidenthanteringsplanen koordineras med dem – annars riskerar ni parallella processer som inte pratar med varandra.
Dokumentera eskaleringsvägar tydligt. När ska SOC:en eskalera till er internt? Vem tar beslut om isolering av system – ni eller leverantören? Vilka befogenheter har de att agera utan att invänta godkännande från er?
Uppdelningen av ansvar måste vara skriftlig och överenskommen i förväg. Det räcker inte att det "är underförstått". Under en aktiv incident finns det ingen tid att diskutera vem som gör vad.
Se också till att SOC:en har uppdaterade kontaktuppgifter till era interna roller och vice versa.
Ladda ner mallen eller boka ett möte
Vill ni ha hjälp att implementera planen, eller behöver ni ett team som faktiskt rycker ut när det händer? Cyloqs incidentavtal ger er tillgång till offensiva specialister dygnet runt – redan inkopplade i er miljö innan något går snett. Läs mer om incidenthantering eller boka ett möte.