En incident inträffar alltid vid fel tidpunkt. Det är inte ett problem som går att lösa det är en grundförutsättning att förhålla sig till.
Det som däremot går att lösa är vad som händer när incidenten väl är ett faktum, om det finns en process som styr arbetet, eller om det är improvisation och personberoende som tar vid.
Hur kaos ser ut i praktiken
De flesta organisationer har upplevt det.
En kritisk tjänst slutar fungera. Någon märker det och skickar ett mejl. Någon annan hör av sig via telefon. En tredje person hör ryktet och öppnar ett ärende i systemet. Ingen vet vem som äger frågan, om någon jobbar på det eller hur allvarligt det egentligen är.
Det är inte ett tecken på att medarbetarna är slarviga. Det är ett tecken på att det saknas en process.
En incidentprocess definierar vad som ska hända från det att en incident identifieras till det att den är löst och dokumenterad. Incident Management är också en av de fem ITIL-processer som ger mest värde för de flesta IT-avdelningar. Den gör arbetet förutsägbart, minskar personberoendet och säkerställer att rätt saker händer i rätt ordning oavsett vem som råkar vara på plats när incidenten inträffar.
Prioritering som faktiskt styr arbetet
Inte alla incidenter är lika allvarliga. Men utan en tydlig prioriteringsmodell behandlas de ofta som om de vore det, eller tvärtom, att allt hamnar i en hög där det mest högljudda ärendet vinner uppmärksamheten.
En fungerande prioriteringsmodell bygger på två faktorer: påverkan och brådska.
Påverkan handlar om hur många användare eller hur kritiska system som berörs. En incident som stoppar en enstaka medarbetare är allvarlig, men en incident som slår ut ett system som hela verksamheten är beroende av kräver omedelbar respons.
Brådska handlar om hur snabbt situationen förvärras om inget görs. En incident som eskalerar för varje minut kräver annan hantering än en som är stabil men störande.
Kombinationen av dessa två faktorer ger en prioritetsmatris som kan tillämpas konsekvent av vem som helst som tar emot incidenten.
Eskaleringsvägar – vem gör vad när
Prioriteringen avgör hur snabbt en incident måste hanteras. Eskaleringsvägen avgör vem som hanterar den och när fler behöver involveras.
En tydlig eskaleringsstruktur innehåller tre saker: rollbeskrivningar, tidsgränser och kommunikationsvägar.
Rollbeskrivningarna definierar vem som ansvarar för vad i respektive prioritetsnivå. Inte namngivna personer, utan roller så att processen håller även när nyckelpersoner är frånvarande.
Tidsgränserna anger hur länge en incident på en given prioritetsnivå får pågå innan den eskaleras till nästa nivå. Det är det som gör att incidenter inte tyst faller bort i systemet.
Kommunikationsvägarna anger vem som informeras när, inte bara internt hos IT, utan också mot de verksamhetsdelar som berörs av incidenten.
Kommunikation under pågående incident
En av de vanligaste bristerna i incidenthantering är inte den tekniska hanteringen, det är kommunikationen mot dem som berörs.
Användare och verksamhetsansvariga behöver veta tre saker: att problemet är känt, att det hanteras och när de kan förvänta sig mer information. Det är inte mer än det. Men det är tillräckligt för att minska trycket på helpdesken och skapa trygghet.
En strukturerad incidentprocess innehåller kommunikationsmallar och automatiserade notifieringar som triggas vid statusförändringar. Det frigör tid för den som hanterar incidenten att fokusera på lösningen, inte på att svara på statusfrågor.
Att stänga en incident rätt
En incident är inte löst när tjänsten fungerar igen. Den är löst när den är dokumenterad, utvärderad och lärdomen är omhändertagen.
Det avslutande steget i en incidentprocess, post-incident review, eller PIR, är det som avgör om organisationen lär sig av det som hänt. Vad var grundorsaken? Vad fungerade i processen? Vad fungerade inte? Vad behöver åtgärdas för att minska risken för upprepning?
De organisationer som konsekvent genomför PIR efter allvarligare incidenter bygger upp en systematisk förmåga att hantera störningar. De som hoppar över det löser samma problem om och om igen.
NIS2 har höjt ribban – en ny dimension för många
För organisationer som omfattas av NIS2-direktivet är incidenthantering inte längre bara en intern fråga. Allvarliga och rapporteringspliktiga cybersäkerhetsincidenter ska rapporteras till MSB, Polisen och Integritetsskyddsmyndigheten.
Det kräver en process som inte bara hanterar incidenten operativt, utan också säkerställer att dokumentation och rapportering sker i rätt format och inom rätt tidsramar. Utan strukturstöd är det ett orimligt krav med rätt process är det hanterbart.
Easit GO har en färdig incidentprocess för cybersäkerhetsincidenter, anpassad för NIS2:s rapporteringskrav med sex tydliga steg från initial bedömning till avslutad dokumentation.
Vanliga frågor
Vad är skillnaden mellan en incident och ett vanligt ärende?
En incident är en oplanerad händelse som stör eller hotar att störa en tjänst. Den hanteras i ett separat flöde med prioritering, eskaleringsregler och kommunikationskrav skilt från den ordinarie ärendehanteringen.
Hur sätter man rätt prioritet på en incident?
Basera prioriteten på påverkan (hur många och hur kritiska system som berörs) och brådska (hur snabbt situationen förvärras). En enkel matris med dessa två faktorer ger en konsekvent prioritering oberoende av vem som tar emot incidenten.
Vad krävs för att uppfylla NIS2:s krav på incidenthantering?
En process som möjliggör snabb identifiering, dokumentation och rapportering till MSB, Polisen och IMY vid allvarliga cybersäkerhetsincidenter, med full spårbarhet för varje steg i hanteringen.
En incidentprocess är inte ett projekt med ett slutdatum. Det är en förmåga som byggs upp steg för steg – och som gör skillnad varje gång något går fel.
Vill du se hur en strukturerad incidentprocess ser ut i Easit GO? Boka en demo
Läs också: Från incident till rapport – GO stödjer NIS2-kraven
Henrik Resare
Commercial Product Manager
henrik.resare@easit.com
+46 70 249 36 06