Sammanfattning: En incident är sällan bara en incident – en teknisk störning kan snabbt bli kontinuitet, återställning, leverantör, personuppgifter och krisledning på samma gång. Incidenttriage hjälper er tidigt avgöra vad som behöver aktiveras, vem som ska involveras och vilka tidsfrister som redan löper. Här är en praktisk modell som kopplar ihop era befintliga planer.

En incident är sällan bara en incident. En teknisk störning kan snabbt bli ett kontinuitetsproblem, kräva återställning från backup, involvera en kritisk leverantör, beröra personuppgifter och samtidigt kräva beslut från ledning eller krisorganisation. En fungerande incidenttriage hjälper organisationen att tidigt förstå inte bara hur allvarlig händelsen är – utan vad som behöver aktiveras, vem som behöver involveras och vilka tidsfrister som redan kan ha börjat löpa.

Många organisationer har redan de planer och processer som förväntas finnas.

Det finns en incidentprocess. Kontinuitetsplaner. Krisplan. Teknisk återställningsplan eller DRP. Rutiner för personuppgiftsincidenter. Leverantörskontakter och processer för regulatorisk rapportering.

Utmaningen visar sig när något faktiskt händer.

Vem avgör att en teknisk incident också har blivit en verksamhetsstörning? När ska kontinuitetsplanen aktiveras? När behöver krisledningen kopplas in? Vem bedömer om incidenten ska rapporteras till en myndighet? När behöver en leverantör eskaleras – och vem håller ihop helheten?

Det är här incidenttriage blir en viktig del av organisationens faktiska incidentförmåga.

Triage är mer än en allvarlighetsgrad

Incidenttriage förknippas ofta med att klassificera en incident som låg, medel, hög eller kritisk – eller som exempelvis P1, P2 eller P3.

Det behövs. Men det räcker inte.

En bra triage behöver också svara på en annan fråga: vilka delar av organisationens respons behöver aktiveras nu?

Samma händelse kan behöva hanteras genom flera parallella spår:

operativ incidenthantering
kontinuitet och alternativa arbetssätt
teknisk återställning och DRP
krisledning
leverantörs- och avtalseskalering
dataskydd och juridisk bedömning
regulatorisk rapportering
intern och extern kommunikation

Triage blir därför inte bara en klassificering. Den fungerar också som en routing- och beslutsfunktion mellan organisationens olika förmågor.

ISO/IEC 27035-1:2023 beskriver en strukturerad incidenthantering med bland annat upptäckt, rapportering, bedömning, respons och lärande. ISO 22301 behandlar kontinuitetsförmågan och hur organisationen förbereder sig för, hanterar och återhämtar sig från störningar. I verkliga incidenter behöver de här perspektiven mötas.

Begreppet incidenttriage används här som en praktisk modell för just den kopplingen – inte som ytterligare en separat process som organisationen behöver bygga.

Incidentprocessen kan vara den gemensamma ingången

För IT- och informationssäkerhetsrelaterade händelser är den operativa incidentprocessen ofta en naturlig ingång.

Det är där de första frågorna ställs: Vad har hänt? Vad är påverkat? Hur omfattande är händelsen? Fortsätter den att utvecklas? Har vi kontroll?

Men incidentteamet ska inte försöka lösa alla perspektiv självt. Triage behöver tidigt kunna identifiera när andra förmågor ska aktiveras parallellt.

Fråga i triagen	Möjlig aktivering
Kan händelsen begränsas och hanteras inom ordinarie verksamhet?	Incidentprocess
Kan en kritisk tjänst eller process inte levereras normalt?	Incident + kontinuitetsplan
Behöver system, data eller infrastruktur återställas?	Incident + DRP/återställningsplan
Krävs beslut eller prioriteringar utanför incidentteamets mandat?	Incident + krisledning
Är en extern leverantör del av orsaken eller lösningen?	Leverantörs- och avtalseskalering
Berörs personuppgifter eller annan reglerad information?	Dataskydd/juridik + eventuell rapportering
Kan regulatoriska rapporteringskriterier vara uppfyllda?	Compliance/regulatoriskt spår
Finns betydande kund-, media- eller förtroendepåverkan?	Kommunikation + eventuell krisledning

Det viktiga är att organisationen inte väntar på att ett spår ska bli klart innan nästa startar. Vid en allvarlig incident kan flera av dessa aktiviteter behöva pågå samtidigt.

Incidenttriangeln – incident, kontinuitet, återställning och kris

Ett enkelt sätt att illustrera sambandet är genom det vi brukar kalla incidenttriangeln.

I mitten finns incidenthanteringen: upptäcka, analysera, begränsa, åtgärda, kommunicera och följa upp händelsen. Runt incidentprocessen finns tre huvudsakliga eskaleringsriktningar.

Kontinuitet

Kontinuitetsplaneringen aktiveras när verksamheten inte längre kan leverera en kritisk tjänst eller process på normalt sätt.

Fokus är då inte främst att reparera grundorsaken. Fokus är att fortsätta verksamheten på en acceptabel nivå. Det kan innebära manuella reservrutiner, alternativa system, andra lokaler, omprioritering av resurser eller andra tillfälliga arbetssätt.

Teknisk återställning och DRP

Återställningsplaneringen aktiveras när system, information, plattformar eller infrastruktur behöver återställas.

Det kan exempelvis handla om att:

återläsa information från backup
aktivera en reservmiljö
återställa en kritisk tjänst
bygga upp infrastruktur på nytt efter ett cyberangrepp

Kontinuitet och återställning har olika fokus. Kontinuitet handlar om hur verksamheten fortsätter under störningen. DRP handlar om hur den tekniska förmågan återställs. De behöver ofta pågå parallellt.

Krisledning

Krisledningen behöver kopplas in när incidenten kräver beslut och samordning utanför den operativa incidentorganisationens mandat.

Det kan handla om prioritering mellan verksamheter, större ekonomiska konsekvenser, kundpåverkan, säkerhetsfrågor, media, myndighetskontakter eller förtroendepåverkan.

Krisledningen ska inte ta över den tekniska incidenthanteringen. Dess roll är att hantera de strategiska och verksamhetsövergripande konsekvenserna.

Tre perspektiv går på tvären genom hela incidenten

Incidenttriangeln behöver kompletteras med tre perspektiv som kan bli aktuella oavsett vilken del av triangeln som aktiveras: leverantörer, regelefterlevnad och kommunikation.

De är inte alltid egna steg i incidentprocessen. De är snarare frågor som behöver bedömas kontinuerligt medan incidenten utvecklas.

Leverantören behöver in i triagen tidigt

En stor del av dagens IT-miljöer består av externa beroenden. Molntjänster, SaaS-lösningar, driftleverantörer, SOC-tjänster, nätoperatörer och andra IT-partners kan både vara en del av orsaken till en störning och helt avgörande för att lösa den.

Därför bör en fråga komma tidigt: är vi beroende av någon annan för att förstå, begränsa eller återställa incidenten?

Det räcker inte att ha en leverantörslista. Organisationen behöver också veta:

vem som får eskalera
vilka kontaktvägar som gäller
vilka SLA och avtalskrav som är relevanta
vilken information leverantören förväntas kunna lämna
vilka underleverantörer som kan vara berörda
vilka alternativa lösningar som finns om leverantören själv inte kan leverera

Den svenska cybersäkerhetslagen visar tydligt hur områdena hänger samman. Kraven på säkerhetsåtgärder omfattar bland annat riskhantering, incident- och kontinuitetshantering, säkerhet i leveranskedjan samt uppföljning av säkerhetsarbetet. De nya föreskrifterna om säkerhetsåtgärder och ledningens utbildning börjar gälla den 1 oktober 2026 för de verksamheter som berörs.

Leverantörsrisk, incidenthantering och kontinuitet går därför inte att behandla som helt fristående områden.

Rapportering behöver bedömas medan incidenten pågår

En vanlig svaghet är att den regulatoriska bedömningen kommer för sent.

Incidentteamet fokuserar på att förstå orsaken och återställa systemen. Först när det tekniska arbetet börjar bli klart involveras informationssäkerhet, dataskydd, juridik eller compliance.

Problemet är att flera rapporteringsfrister börjar löpa långt innan den tekniska utredningen är färdig.

Cybersäkerhetslagen

Verksamhetsutövare som omfattas av cybersäkerhetslagen ska rapportera betydande incidenter till NCSC. För de flesta berörda verksamhetsutövare sker rapporteringen i tre steg:

upplysning inom 24 timmar
incidentanmälan inom 72 timmar
slutrapport inom en månad, eller lägesrapport om incidenten fortfarande pågår

NCSC betonar också att organisationen inte ska vänta med den första rapporteringen för att all information ännu inte finns tillgänglig.

GDPR

Vid en personuppgiftsincident behöver den personuppgiftsansvarige bedöma om incidenten innebär en risk för fysiska personers rättigheter och friheter.

Om incidenten är anmälningspliktig är utgångspunkten att den ska anmälas till Integritetsskyddsmyndigheten inom 72 timmar från att organisationen fått vetskap om den.

DORA

För finansiella företag som omfattas av DORA gäller särskilda tidsfrister för allvarliga IKT-relaterade incidenter.

Initialrapporten ska lämnas så snart som möjligt, men senast inom fyra timmar efter att incidenten klassificerats som allvarlig och senast 24 timmar efter att företaget blivit medvetet om incidenten. Därefter ska en delrapport lämnas inom 72 timmar efter initialrapporten och en slutrapport senast en månad efter delrapporten, eller den senaste uppdaterade delrapporten.

Cyber Resilience Act

Från den 11 september 2026 börjar CRA:s rapporteringsskyldigheter tillämpas för tillverkare av produkter med digitala element.

Det omfattar bland annat aktivt utnyttjade sårbarheter och allvarliga incidenter som påverkar produktens säkerhet. Även här finns tidiga rapporteringsfrister: en tidig varning inom 24 timmar och fullständig anmälan inom 72 timmar.

Poängen är inte att samma incident automatiskt omfattas av alla dessa regelverk. Poängen är att triagen måste identifiera vilka lagkrav, sektorskrav och avtalskrav som kan vara relevanta innan tidsfristerna blir ett problem.

En incident – flera samtidiga aktiviteter

Tänk att en organisation drabbas av ransomware och att ett affärskritiskt system blir otillgängligt.

Incidentteamet försöker förstå angreppet och begränsa spridningen. Samtidigt behöver verksamheten kanske gå över till reservrutiner eftersom den normala processen inte längre fungerar.

Om servrar eller data måste återställas från backup aktiveras DRP eller återställningsplan. Om infrastrukturen hanteras av en extern driftleverantör behöver leverantören eskaleras.

Finns misstanke om att personuppgifter har exfiltrerats behöver dataskyddsorganisationen börja sin bedömning. Om verksamheten omfattas av cybersäkerhetslagen, DORA eller annan sektorsreglering behöver rapporteringsskyldigheten bedömas.

Och om påverkan blir tillräckligt omfattande – kunder börjar ringa, viktiga tjänster står still eller media uppmärksammar händelsen – kan även krisledning och kommunikationsfunktion behöva aktiveras.

Det är fortfarande en incident. Men organisationens respons består av flera samtidiga aktiviteter. Det är precis det incidenttriagen behöver fånga.

Sex frågor för den första triagen

Den första triagen behöver inte vara komplicerad. Men den behöver tvinga organisationen att titta bredare än på det tekniska felet.

1. Verksamhet

Vilka tjänster, processer, kunder eller andra intressenter påverkas? Riskerar kritiska tidsgränser, RTO eller tolererade avbrottstider att överskridas?

2. Teknik och information

Vilka system och informationstillgångar är berörda? Finns risk för förlust, manipulation, kryptering eller obehörig åtkomst? Behöver något återställas?

3. Kontroll över situationen

Är orsaken och omfattningen känd? Är incidenten begränsad eller fortsätter den att utvecklas? Finns risk för spridning?

4. Externa beroenden

Är en leverantör, partner eller annan extern part berörd? Behöver någon av dem agera för att incidenten ska kunna begränsas eller lösas?

5. Regelefterlevnad och avtal

Kan incidenten omfattas av rapporteringskrav enligt exempelvis cybersäkerhetslagen, GDPR, DORA, CRA eller andra sektorsregler? Finns avtalsmässiga krav på att informera kunder, leverantörer eller andra parter?

6. Ledning och kommunikation

Krävs beslut utanför incidentteamets mandat? Finns betydande påverkan på kunder, personal, myndigheter, media eller organisationens förtroende?

Svar på dessa frågor ger betydligt bättre beslutsunderlag än en klassificering som enbart säger Critical eller P1.

Poängmodeller kan hjälpa – men vissa händelser ska trigga direkt

En enkel poängmodell kan vara ett bra stöd i triagen. Verksamhetspåverkan, tekniskt återställningsbehov, informationspåverkan, kontroll över situationen, leverantörsberoende och behov av ledningsbeslut kan exempelvis bedömas utifrån en gemensam skala. Det ger struktur och gör bedömningar mer konsekventa.

Men totalsumman får aldrig bli den enda sanningen. Vissa förhållanden bör kunna fungera som direkta triggers för eskalering. Exempel kan vara:

misstänkt ransomware
omfattande eller känslig informationsläcka
kritisk tjänst som är otillgänglig
risk för fysisk säkerhet eller liv och hälsa
omfattande påverkan hos kritisk leverantör
sannolik regulatorisk rapporteringsskyldighet
snabbt växande kund- eller mediapåverkan

När informationen fortfarande är begränsad behöver organisationen ibland hellre eskalera en gång för mycket än upptäcka för sent att situationen var allvarligare än man först trodde.

Triage är inte ett engångsbeslut

En annan viktig princip är att triagen behöver upprepas.

En incident som klockan 09.00 bedöms som begränsad kan klockan 10.30 ha utvecklats till en verksamhetskritisk störning. Ny information kan visa att fler system är drabbade, att data har läckt, att en leverantör också är påverkad eller att återställningen kommer att ta betydligt längre tid än man först trodde.

Därför behöver organisationen bestämma när omtriage ska göras. Det kan vara:

vid ny väsentlig information
när påverkan förändras
när incidenten passerar en definierad tidsgräns
när en kritisk tjänst påverkas
när rapporteringskriterier kan vara uppfyllda
när ansvar eller ledningsnivå förändras

Triage följer incidentens hela livscykel.

Från separata planer till en samlad incidentförmåga

En organisation kan ha välskrivna incident-, kontinuitets-, återställnings- och krisplaner och ändå ha svårt att hantera en allvarlig händelse.

Det avgörande är inte bara kvaliteten på respektive dokument. Det är hur planerna hänger ihop när de behöver användas samtidigt.

Organisationen behöver därför veta:

vem som genomför den första triagen
vilka kriterier som leder till eskalering
vem som får aktivera respektive plan
vilka funktioner som ska involveras
vilka leverantörer som ska kontaktas
vilka regulatoriska och avtalsmässiga bedömningar som ska göras
hur en gemensam lägesbild upprätthålls
vem som fattar vilka beslut
hur och när triagen ska omprövas

Det är först då dokumenterade processer börjar bli en verklig incidenthanteringsförmåga.

En bra incidenttriage svarar därför inte bara på frågan ”Hur allvarlig är incidenten?”. Den ska också svara på ”Vad behöver vi göra nu, vilka behöver involveras och vilka andra processer behöver starta?”.

Det är den kopplingen som gör skillnaden mellan flera separata planer och en samordnad verksamhetsrespons när något faktiskt händer.

Så kan Kristensson i Skåne stödja arbetet

Kristensson i Skåne hjälper organisationer att utveckla och förbättra samspelet mellan incidenthantering, kontinuitet, teknisk återställning, krisledning, leverantörshantering och regulatorisk rapportering.

Stödet kan exempelvis omfatta:

nuläges- och gap-analys av incidentförmågan
utveckling av incidentprocess och triagemodell
klassificerings- och eskaleringskriterier
koppling mellan incidentprocess, BCP, DRP och krisplan
processer för regulatorisk rapportering
integration av leverantörs- och tredjepartseskalering
roller, ansvar och beslutsmandat
playbooks för olika incidenttyper
tabletop-övningar och andra tester
uppföljning och förbättring efter incidenter och övningar
löpande stöd inom informationssäkerhet, GRC och CISO-funktion

Vår utgångspunkt är praktisk: organisationen ska inte behöva fundera på hur planerna hänger ihop när incidenten redan pågår. Det sambandet behöver vara etablerat, förankrat och övat i förväg.

Vill ni diskutera hur incidenttriage kan byggas in i er befintliga incident-, kontinuitets- och krishantering? Läs mer om vårt arbete med informationssäkerhet och styrning eller kontakta oss så tar vi ett första samtal om nuläge och nästa steg.

Källor och vidare läsning: ISO/IEC 27035-1:2023; ISO 22301; Cybersäkerhetslagen och NCSC:s vägledning om incidentrapportering; GDPR (artikel 33) och Integritetsskyddsmyndigheten; DORA (rapportering av allvarliga IKT-relaterade incidenter); Cyber Resilience Act (rapporteringsskyldigheter).

Detta är en översikt och inte juridisk rådgivning. Varje organisation behöver bedöma sina krav utifrån verksamhet, sektor, riskbild och tillämpliga regelverk.