En samarbejdspartner er blevet ramt: skal vi selv teste?

Når en leverandør eller samarbejdspartner melder om et angreb, er det første spørgsmål for ledelsen ikke, om der skal testes, men hvor tæt forbindelsen er. Svaret afhænger af to forhold: hvilken adgang partneren har til jeres systemer og data, og hvad partneren kan fortælle om hændelsen. En sikkerhedstest kan blive relevant senere, men den kommer efter afklaringen, ikke i stedet for den.

Situationen er ubehagelig, fordi ledelsen er afhængig af oplysninger fra en anden virksomhed, der selv er under pres. Partneren har travlt med sin egen hændelse og vil måske ikke eller kan ikke fortælle meget endnu. Det gør det endnu vigtigere, at ledelsen ved, hvad den skal spørge om.

Hvor tæt er forbindelsen?

Partnere kan være forbundet med virksomheden på forskellige måder, og betydningen af en hændelse hos dem afhænger helt af, hvilken slags forbindelse der er tale om.

Adgang til jeres systemer · driftsleverandøren, en softwareleverandør med fjernadgang, et bureau med adgang til hjemmesiden.
Jeres data hos dem · lønbureauet, regnskabssystemet i skyen, et fragtfirma med kundeadresser.
Systemer, der taler sammen · integrationer, hvor ordrer, fakturaer eller lagertal sendes automatisk.
Mails og dokumenter · en fast samarbejdspartner, der udveksler fakturaer og kontrakter med jer.
Fælles leverandør · I bruger selv den løsning, der blev ramt hos partneren.

Den første opgave er at finde ud af, hvilke af disse forbindelser der findes. Det lyder enkelt, men en sådan situation kan afsløre, at ingen har en samlet oversigt, og at listen må stykkes sammen fra kontrakter, fakturaer og IT’s hukommelse. → Hvem har adgang til hvad?

Det første døgn: afklaring frem for test

I de første timer og dage er opgaven at begrænse en eventuel skade og at få oplysninger. Ledelsen bør sikre, at nogen tager stilling til, om partnerens adgang skal lukkes eller begrænses midlertidigt, og at nogen tager kontakt til partneren for at få at vide, hvad der er ramt.

En sikkerhedstest i denne fase giver ikke nødvendigvis mening. Testen afprøver, hvordan jeres systemer står, ikke om en angriber allerede har brugt forbindelsen til partneren. Hvis der er mistanke om, at nogen er kommet ind hos jer, er det en anden opgave, der kræver en undersøgelse af hændelsen, ikke en test. → Testen finder tegn på, at nogen allerede er inde

Spørgsmål til partneren

Partneren er ikke altid klar til at svare med det samme, men ledelsen bør stille spørgsmålene tidligt, så de står på listen.

Hvilke systemer og data er ramt, og omfatter det noget, der vedrører os?
Har angriberen haft mulighed for at bruge jeres adgang til vores systemer?
Hvilke forholdsregler anbefaler I, at vi tager?
Hvornår kan vi forvente mere viden, og hvem er vores kontaktperson?
Hvordan vil I dokumentere, at hændelsen er håndteret, før forbindelsen åbnes igen?

Det sidste spørgsmål er vigtigt for den senere beslutning. Når partneren melder, at alt er i orden igen, skal ledelsen vide, hvad udsagnet bygger på. → Spørgsmål til IT-leverandøren

Når jeres egne kunder spørger

En hændelse hos en partner kan blive kendt, før ledelsen har overblikket. Kunder, der ved, at I samarbejder med den ramte virksomhed, kan spørge, om deres data er berørt. Svar ikke, før I ved det, men svar heller ikke ved at tie. Et kort budskab om, at I er i dialog med partneren og undersøger, om jeres systemer og kundernes data er berørt, er ærligt og holder, uanset hvad der kommer frem senere.

Aftal i ledelsen, hvem der svarer udadtil, og at svarene bygger på det, der er afklaret, ikke på partnerens første melding. Hvis jeres kunders personoplysninger kan være berørt, kan der være pligter efter databeskyttelsesreglerne, som ledelsen skal tage stilling til. Det bør vurderes af nogen med juridisk indsigt, og teksten her er ikke juridisk rådgivning.

Hvornår en test giver mening

Når hændelsen hos partneren er håndteret, og forbindelsen skal genoptages, kan en sikkerhedstest være et fornuftigt skridt. Den kan belyse, om partnerens adgang til jeres systemer er begrænset til det nødvendige, om en angriber med samme adgang ville kunne komme længere, og om jeres egne systemer er sårbare over for den type svaghed, der ramte partneren.

Testen er også relevant, hvis hændelsen har vist, at jeres afhængighed af partneren er større, end ledelsen troede. Så er spørgsmålet ikke længere kun den konkrete hændelse, men hvordan virksomheden er sårbar over for alle de partnere, der har adgang. Testens resultat kan bruges til at stille krav i aftalerne fremover.

Afhængighed er en ledelsesbeslutning

En hændelse hos en partner minder ledelsen om, at virksomhedens sikkerhed delvis ligger i andres hænder. Det kan ikke undgås, men det kan styres. Den britiske myndighed NCSC anbefaler i sin vejledning om ledelse af cyberrisici, at bestyrelsen sikrer sig, at oplysninger om leverandører vurderes løbende og i forhold til risikoen, og at virksomheden kan modstå risici fra sin leverandørkæde og sine partnere. Vejledningen er britisk og frivillig, men den beskriver en opgave, der også gælder for en dansk ledelse.

I praksis betyder det at kende de vigtigste partnere, vide, hvad de har adgang til, og have aftaler, der giver ret til oplysninger, når noget sker. → Leverandørrisiko · → Sikkerhed i samarbejdsaftaler

Det skal I lade være med

At bestille en test, mens hændelsen hos partneren står på · testen svarer ikke på, om angriberen er nået ind hos jer.
At vente passivt på partnerens melding · afklar selv, hvilke forbindelser der findes.
At genåbne forbindelsen uden grundlag · bed om at få at vide, hvad partnerens melding bygger på.
At lade det blive ved den konkrete hændelse · brug den til at se på alle partnere med adgang.
At bebrejde partneren offentligt · I skal måske samarbejde om at løse det.

Hvad kan og ikke kan konkluderes

En hændelse hos en partner betyder ikke, at jeres virksomhed er ramt, men den betyder, at ledelsen skal afklare det. En sikkerhedstest efter hændelsen kan vise, hvordan forbindelsen til partneren og jeres egne systemer står på testtidspunktet. Den kan ikke vise, om en angriber har været inde hos jer under hændelsen, og den kan ikke erstatte partnerens egen dokumentation af, hvordan hændelsen er håndteret.

Tjekliste, når en partner er ramt

☐ Ved vi, hvilken adgang partneren har til vores systemer og data?
☐ Har nogen taget stilling til at begrænse adgangen midlertidigt?
☐ Har vi en kontaktperson hos partneren og en liste over spørgsmål?
☐ Er det aftalt, hvad der skal til, før forbindelsen genåbnes?
☐ Er det vurderet, om en test giver mening, når hændelsen er håndteret?
☐ Er det besluttet at gennemgå andre partnere med adgang?

Kilder

NCSC og UK Government, Cyber Governance Code of Practice: princip A om løbende vurdering af leverandører og modstandskraft over for risici fra leverandørkæden og partnere.

Senest gennemgået: oktober 2026.