Incident response-plan: 6-fas-ramverket för svenska tech-bolag

När en säkerhetsincident inträffar avgörs utfallet ofta under de första timmarna, och då är det fel tillfälle att börja klura ut vem som gör vad. Skillnaden mellan ett bolag som hanterar en incident professionellt och ett som hamnar i panik är sällan teknisk skicklighet, det är att den ena har en plan som är inövad och den andra inte. Den här guiden går igenom ett beprövat ramverk i sex faser, anpassat för svenska tech-bolag som vill vara förberedda.

Jag hjälper bolag att bygga och testa incidentberedskap inom cybersäkerhet. En plan som ligger i en pärm är värd lite; en plan som teamet har övat på är värd allt. Ramverket nedan följer den etablerade incidenthanteringscykeln. Notera att faserna inte alltid löper strikt linjärt i verkligheten, man kan tvingas pendla mellan avgränsning och utrotning när nya detaljer dyker upp, men strukturen ger ett gemensamt språk och säkerställer att inget steg glöms bort i stridens hetta. Just det gemensamma språket är ofta värt mer än själva dokumentet, eftersom det låter ett stressat team koordinera utan missförstånd.

Fas 1: Förberedelse

Den viktigaste fasen sker innan något hänt. Här definieras rollerna (vem leder, vem beslutar, vem kommunicerar), kontaktvägarna, och de verktyg och loggar ni behöver för att kunna utreda. Förberedelse innebär också att veta vilka externa parter ni kan behöva, jurist, forensikexpert, försäkringsbolag, innan ni desperat googlar mitt i en kris. En stor del av god förberedelse är dessutom att ha grundskyddet på plats, exempelvis enligt Zero Trust för SMB, så att färre incidenter ens uppstår.

Fas 2: Identifiering

Nästa fas handlar om att upptäcka och bekräfta att något faktiskt är en incident. Det förutsätter att ni har övervakning och loggning som ger signaler, och kriterier för vad som räknas som en incident kontra ett vanligt larm. Här är rapporteringskultur avgörande: ju fler ögon som vågar flagga något misstänkt, desto tidigare upptäckt. Det hänger direkt ihop med säkerhetsmedvetande, som jag beskriver i phishing-simuleringar och träning.

Fas 3: Avgränsning

När en incident är bekräftad gäller det att hindra den från att sprida sig. Avgränsning kan vara att isolera drabbade system, spärra konton eller stänga av en angreppsväg, utan att förstöra de spår ni senare behöver för utredningen. Det är en balansgång, och det är därför besluten ska vara förberedda: vad får vi stänga av, och vem har mandat att fatta beslutet snabbt?

Här gör jag mid-vägs alltid en genomgång av era beslutsmandat. I en kris är det förödande om ingen vågar dra ur sladden för att de inte vet om de får. Vill ni ha den gjord ingår det i cybersäkerhetsuppdraget.

Fas 4: Utrotning

Med incidenten avgränsad ska grundorsaken bort: ta bort skadlig kod, stäng den utnyttjade sårbarheten, återkalla komprometterade uppgifter. Det räcker inte att släcka symptomen, om ni återställer utan att åtgärda hur angriparen kom in är ni snart tillbaka i samma läge. Det här hänger ihop med systematisk sårbarhetshantering, som jag beskriver i SBOM med Syft och Grype.

Fas 5: Återställning

Nu återförs verksamheten till normal drift, kontrollerat. Det innebär att återställa system från rena säkerhetskopior, verifiera att de faktiskt är rena, och övervaka noga för tecken på att angriparen finns kvar. Det är också i den här fasen rapporteringskraven aktualiseras, för bolag under NIS2 gäller tidsramar för rapportering, vilket jag tar upp i NIS2 artikel 21 i praktiken. Kommunikation, både internt och externt, hör hemma här och bör följa ett förberett protokoll.

Fas 6: Lärdomar

Den fas som oftast hoppas över är den mest värdefulla. Efter att dammet lagt sig: vad hände, vad fungerade, vad gjorde inte det, och vad ändrar vi? En ärlig genomgång utan skuldbeläggande gör att varje incident gör organisationen starkare. Planen ska uppdateras utifrån vad ni faktiskt lärde er, inte arkiveras tills nästa gång.

Kommunikation: den underskattade förmågan

En aspekt som tekniska team ofta underskattar är kommunikationen, och den är värd att förbereda lika noga som det tekniska. Vid en allvarlig incident behöver ni snabbt kunna informera flera målgrupper med olika behov: ledningen vill ha beslutsunderlag, medarbetarna vill veta vad de ska och inte ska göra, kunderna vill ha ärlighet och en tidsbild, och vid personuppgiftsincidenter finns det rättsliga krav på information till både myndighet och drabbade. Det värsta läget är att improvisera budskap mitt i krisen, eftersom fel formulering kan förvärra skadan på förtroendet långt mer än själva incidenten. Förbered därför mallar och en tydlig talesperson i förväg, och bestäm vem som godkänner extern kommunikation. En teknisk lösning utan en kommunikationsplan är en halv beredskap. Min erfarenhet är att de bolag som kommunicerar öppet och snabbt under en incident ofta kommer ur den med förtroendet i behåll, ibland till och med stärkt, medan de som försöker tysta ner eller släpar på informationen drabbas hårdast i efterspelet långt efter att det tekniska är löst.

Var jag brukar börja

Börja med fas 1 och en enkel övning. Det vanligaste och dyraste misstaget är att skriva en plan och aldrig testa den, då upptäcker ni luckorna mitt i en riktig kris, vilket är det värsta tänkbara tillfället. En kort skrivbordsövning, där teamet spelar igenom ett scenario, avslöjar på en eftermiddag vad ingen plan på papper visar. Se hur jag lägger upp incidentberedskap i kundcase.

Relaterat

• DORA-förordningen för fintech: Vad CTO:n måste veta innan 2027
• Schrems II och dataöverföring till USA 2026: Status och alternativ
• SBOM med Syft + Grype: Sårbarhetshantering i CI/CD

Vill du ta det vidare?

Jag hjälper svenska tech-bolag att bygga en incident response-plan som faktiskt fungerar i skarpt läge, och att öva den innan det behövs. Boka ett samtal så går vi igenom er beredskap.