Krav om red teaming i jeres leverandørkontrakter: hvad giver mening at kræve?

En kritisk leverandør kan være den vej, en angriber vælger ind i jeres organisation, og den kan være en del af det forsvar, der skal opdage angrebet. Derfor kan det give mening at stille krav om red teaming i kontrakten. Om det gør, afhænger af leverandørens rolle i jeres scenarier, og om kravet virker, afhænger af, hvor præcist det er skrevet.

Kort sagt er der tre slags krav: at leverandøren deltager i jeres øvelser, at leverandøren accepterer at blive afprøvet af jeres hold, og at leverandøren selv gennemfører øvelser og dokumenterer dem over for jer. Et krav, der blot siger red teaming, giver hverken jer eller leverandøren noget at handle på. Teksten er ikke juridisk rådgivning, og kontraktens ordlyd bør gennemgås af jeres jurist.

Hvornår kravet er relevant

Kravet hører hjemme hos leverandører, hvor en øvelse kan svare på noget, I ellers ikke kan få svar på. Fire situationer peger i den retning:

Leverandøren understøtter en kritisk funktion · et nedbrud eller en kompromittering hos leverandøren rammer jeres forretning direkte.
Leverandøren har adgang ind til jer · fjernadministration, supportadgang eller integrationer, der kan misbruges.
Leverandøren er en del af forsvaret · en SOC- eller MDR-leverandør, hvis reaktion skal måles. → SOC-leverandøren og øvelsen
Jeres scenarier går gennem leverandøren · trusselsbilledet peger på leverandøren som indgang. → Leverandørscenariet

For en leverandør af kontorartikler eller en enkeltstående SaaS-tjeneste uden adgang til jeres miljø er et red team-krav svært at begrunde. Her giver et sikkerhedsspørgeskema, en pentestrapport eller en revisionserklæring et mere passende grundlag.

Det, regelsættene lægger op til

NIS2-direktivets artikel 21, stk. 2, litra d, kræver foranstaltninger for forsyningskædesikkerhed, og efter stk. 3 skal der tages hensyn til leverandørernes cybersikkerhedspraksis. For de digitale tjenesteudbydere, forordning (EU) 2024/2690 gælder for, opregner bilagets punkt 5.1.4, hvad kontrakter med leverandører kan indeholde, bl.a. cybersikkerhedskrav, underretning om hændelser og ret til audit eller til at modtage auditrapporter. Listen kan bruges som inspiration, også hvor forordningen ikke gælder.

I finanssektoren kræver DORA artikel 30, stk. 3, at kontrakter om tjenester bag kritiske eller vigtige funktioner bl.a. indeholder krav om, at leverandøren gennemfører og tester beredskabsplaner og sikkerhedsforanstaltninger (litra c), og ret til adgang, inspektion og revision (litra e). For virksomheder, der er udpeget til TLPT, kræver litra d desuden leverandørens pligt til at deltage i og samarbejde om testen. Artikel 28, stk. 1, litra b, gør leverandørstyringen forholdsmæssig efter afhængighedens karakter og betydning. Ingen af reglerne kræver frivillig red teaming af leverandører. De giver jer et grundlag for at kræve dokumentation og samarbejde, og red team-kravet er én måde at udfylde det på, når leverandørens rolle i jeres scenarier gør det relevant. → IKT-tredjepartsudbydere i TLPT

Tre slags krav

Deltagelse i jeres øvelse · leverandøren giver tilladelse til handlinger, der berører dens systemer, udpeger en fortrolig kontaktperson og holder øvelsen hemmelig for sine driftsfolk. → Driftsleverandører og cloududbydere i øvelsen
Afprøvning af leverandøren · jeres hold må efter aftale afprøve leverandørens medarbejdere, processer eller adgange, inden for regler, som begge parter har godkendt.
Leverandørens egen øvelse · leverandøren gennemfører selv øvelser mod sin organisation og giver jer et aftalt niveau af dokumentation.

Den første type er den, en øvelse med leverandøren i scenariet ikke kan undvære, og den er lettest at begrunde. Den anden kræver mest af leverandøren og kan møde modstand, hvis den ikke er forberedt. Den tredje giver jer mindst indsigt, men den belaster ikke leverandørens andre kunder.

Sådan formuleres kravet præcist

Et brugbart krav svarer på de spørgsmål, leverandøren vil stille, når klausulen bliver aktuel:

Formål · hvilket spørgsmål øvelsen skal besvare om leverandørens rolle.
Type · deltagelse, afprøvning eller egen øvelse, eller en kombination.
Hyppighed eller anledning · fx ved større ændringer i leverancen eller efter en alvorlig hændelse.
Omfang og grænser · hvilke systemer og medarbejdere der kan indgå, og hvad der aldrig må berøres, fx andre kunders miljøer.
Varsling og fortrolighed · hvem hos leverandøren der får besked, hvornår, og under hvilke vilkår.
Stop og ansvar · hvem der kan standse aktiviteter, og hvordan skader håndteres. → Kontrakten om en red team-øvelse
Dokumentation · hvad I modtager efter leverandørens egen øvelse, og i hvilken form.
Udgifter · hvem der afholder udgifterne til leverandørens tid og eventuelle eksterne testere.

Leverandørens side af de samme spørgsmål er beskrevet særskilt og er værd at læse, før I sender udkastet. → Kunden vil red teame jer

Når leverandøren siger nej

En udbyder kan have standardvilkår, der ikke forhandles, og cloududbydere har egne regler for sikkerhedstest. Et nej til afprøvning behøver ikke betyde, at kravet falder. I kan acceptere dokumentation af leverandørens egne øvelser, en målrettet penetrationstest af integrationen eller en øvelse, hvor jeres scenarie stopper ved leverandørens grænse. Det vigtige er, at forskellen mellem det ønskede og det aftalte står i jeres risikovurdering, så ledelsen kender det.

Tidspunktet betyder også noget. Et krav er lettest at få med, når kontrakten forhandles eller fornyes, og sværest at indføre midt i en løbende aftale. Notér derfor i leverandøroversigten, hvilke kritiske leverandører der mangler et krav, og tag det op ved næste fornyelse. Har I allerede en øvelse planlagt, hvor leverandøren indgår, kan en kort tillægsaftale om netop den øvelse dække behovet, indtil kontrakten kan ændres.

Hvordan en kontrakt mere generelt bør håndtere sikkerhedstest, beskriver sikkerhedstesten.dk fra ledelsens side.

Det skal I lade være med

At skrive red teaming uden at definere det · leverandøren kan opfylde kravet med noget helt andet.
At stille samme krav til alle leverandører · kravet skal følge leverandørens rolle i jeres scenarier.
At kræve den fulde rapport fra leverandørens egen øvelse · den beskriver også vejen til andre kunder.
At glemme varslingen · et krav om hemmelighold skal kunne forenes med leverandørens egne procedurer.
At kalde kravet en DORA-forpligtelse, hvor det ikke er det · TLPT-pligten gælder kun udpegede virksomheder.

Hvad kan og ikke kan konkluderes

Et præcist krav sikrer, at kritiske leverandører kan indgå i jeres øvelser og afprøves på en kontrolleret måde, og at I ved, hvad I får, når leverandøren selv tester. Kravet kan ikke garantere, at leverandøren er sikker, og et opfyldt krav siger kun noget om det, der var inden for rammerne. Leverandørens perspektiv på dokumentationen er beskrevet for sig. → Leverandørens dokumentation til kunder

Tjekliste til kravet

☐ Leverandørens rolle · er det beskrevet, hvordan leverandøren indgår i jeres scenarier?
☐ Type · er det valgt, hvilken slags krav der stilles?
☐ Grænser · er andre kunders miljøer og data udtrykkeligt holdt uden for?
☐ Fortrolighed · er kontaktperson og varsling aftalt?
☐ Dokumentation · er form og niveau fastlagt?
☐ Plan B · er det besluttet, hvad I accepterer, hvis leverandøren ikke kan sige ja?

Kilder

Direktiv (EU) 2022/2555 (NIS2): artikel 21, stk. 2, litra d, og stk. 3.
Kommissionens gennemførelsesforordning (EU) 2024/2690: bilagets punkt 5.1.4 om indholdet af kontrakter med leverandører og tjenesteudbydere.
Forordning (EU) 2022/2554 (DORA): artikel 28, stk. 1, litra b, og artikel 30, stk. 3, litra c, d og e.

Senest gennemgået: oktober 2026.