När leverantören blir hackad – vad gör du då?

Förr eller senare händer det. En leverantör du arbetar med drabbas av en incident. Det kan vara ett intrång, ransomware eller ett driftstopp som gör att din leverantör inte längre kan leverera som vanligt.

Vi såg det i samband med driftstörningarna hos Tunstall i slutet av 2021, efter ransomwareattacken mot Tietoevry 2024, och efter den felaktiga uppdateringen från CrowdStrike 2024.

Även tidigare har vi sett hur leverantörsproblem kan få långvariga konsekvenser. Ett exempel är när Loopia drabbades av driftstörningar i sin e-posttjänst runt 2008. Problemet var inte bara själva avbrottet, utan mer att tjänsten under en längre period var instabil. I detta fall blev konsekvensen helt enkelt att många till slut bytte leverantör.

Leverantörens incident är din incident

Frågan är egentligen inte ”om det händer”, utan vad som händer och hur du agerar när det gör det. Att ställa den frågan efter att du gjort det du ska, kan kännas lite obekvämt. Man har ställt krav, skickat ut enkäter och kanske till och med gjort en granskning. Men när något faktiskt inträffar är det oklart vad som ska göras, vem som ansvarar och hur snabbt man får information. Det är just det här cybersäkerhetslagen försöker förändra.

Under ett NIS2-webbinarium i januari 2026 lyfter Jonas Stewén att incidenthantering i leverantörsledet inte bara är en teknisk fråga – utan en del av det övergripande ansvaret:

”Om du är en del av en försörjningskedja så räcker det inte att hantera incidenter internt. Du måste också kunna rapportera vidare, så att organisationen du jobbar mot kan agera och i sin tur uppfylla sina krav.”

Det innebär att en leverantörs incident snabbt blir din incident. Du kan inte outsourca ansvaret.

En vanlig missuppfattning är att risken ”flyttar ut” när man använder en leverantör. I praktiken är det tvärtom. Ansvar ligger kvar hos den organisation som omfattas av regelverket – oavsett var problemet uppstår.

Jonas beskriver det som en konsekvens av hur hela ekosystemet hänger ihop:

”Man måste komma ihåg att man är en del av ett större ekosystem. Om något händer hos en leverantör påverkar det inte bara dem – det påverkar hela kedjan. Och då behöver man kunna hantera det tillsammans.”

Det betyder att du inte bara behöver veta att något har hänt – utan vad det innebär för dig.

Vad du behöver göra när det händer

När incidenten väl inträffar är det inte läge att börja fundera. Då behöver du agera. I praktiken handlar det om några avgörande steg.

För det första måste du snabbt få en bild av påverkan. Vad har hänt – och vad påverkar det?

Jonas är inne på just den typen av frågor:

”Du behöver förstå vad det innebär för din verksamhet – påverkar det leveransen, påverkar det din information, och vad behöver du göra nu?”

Det innebär att du direkt behöver ta reda på:

• Om din data är påverkad
• Om leveransen är störd eller riskerar att bli det
• Om det finns en spridningsrisk in i din egen miljö

Nästa steg är att aktivera din egen incidenthantering. Det är här många organisationer missar kopplingen. Leverantörens incident ses som ”deras problem”, trots att den i praktiken kan påverka din verksamhet lika mycket.

Du behöver därför snabbt avgöra:

• Behöver du isolera system eller åtkomst?
• Behöver du informera internt eller externt?
• Behöver du eskalera till ledning eller krisorganisation?

Samtidigt behöver du säkerställa att kommunikationen fungerar.

Vem pratar med leverantören, hur ofta uppdateras läget och får du faktiskt den information du behöver?

Problemet uppstår långt innan incidenten

Det som ofta blir tydligt i skarpa lägen är att problem sällan uppstår där och då.

De uppstår i förberedelserna hos leverantören. Ofta vet leverantören inte vad den ska rapportera, hur snabbt det ska ske och vilken information du som beställare har rätt att få. Det blir helt enkelt otydligt när något händer om din leverantör inte har koll.

Jonas är tydlig med att det här måste vara definierat i förväg:

”Det räcker inte att bara säga att man ska rapportera incidenter. Man måste förstå hur det ska gå till i praktiken och vad det innebär när det faktiskt händer.”

Det gäller särskilt för kritiska leverantörer, där i princip varje minut spelar roll.

Du behöver mer än information – du behöver handlingsbar information

En annan vanlig utmaning är kvaliteten på den information man får.

Att få ett meddelande om att ”vi har haft en incident” räcker inte.

Du måste kunna få tillräckligt konkret information för att kunna fatta beslut.

• Vad är påverkat?
• Vad är risken framåt?
• Vad förväntas jag göra?

Om du inte får den typen av svar blir du passiv, och det är ofta då konsekvenserna växer.

Det går inte att testa i efterhand

Många organisationer inser först vid en incident att deras arbetssätt inte håller.

Kontaktvägar saknas. Ansvar är otydligt och informationen är för vag. Det är därför det finns ett stort värde i att faktiskt testa det här i förväg.

Jonas lyfter hur man kan arbeta mer praktiskt:

”Man kan utgå från sina största risker och bygga scenarion tillsammans. Det kan vara allt från diskussionsövningar till mer avancerade simuleringar där man jobbar som om det händer på riktigt.”

Det är först i de situationerna som det blir tydligt om arbetssättet fungerar.

Slutsats

Och när en leverantör drabbas av en incident testas allt. Inte bara leverantören, utan även din egen förmåga att förstå situationen, fatta beslut och sist men inte minst agera i tid. Har du rätt förväntningar på plats, får du rätt information och vet du vad du ska göra? Om svaret är nej på någon av de frågorna är det sällan ett isolerat problem. Det är ett tecken på att arbetet innan inte varit tillräckligt tydligt. Och det är också därför cybersäkerhetslagen lägger så stor vikt vid leverantörsledet.

För i praktiken är det just i de tre frågorna, som de största riskerna finns. Inte i det du kontrollerar själv, utan i det du är beroende av. Och när något går fel är det redan för sent att börja fundera. Då ska det ju redan sitta.

Lösningen på allt detta är i grunden ganska enkel i teorin, men kräver disciplin i praktiken. Det handlar om att klargöra förväntningar, säkerställa att krav verkligen kan omsättas i handling och att regelbundet pröva hur väl det fungerar när det verkligen gäller. För det är först då du vet om du har kontroll.

Att hantera leverantörsrisker är inte en engångsinsats, utan en kontinuerlig förmåga. Och i slutändan är det inte avtalen eller formuleringarna som avgör – utan hur snabbt och tydligt du kan agera när något inträffar.

För när leverantören blir hackad är det inte längre deras problem.

Det är ditt.