Pligt til at håndtere sårbarheder i leverandøraftalen

En ny eller fornyet aftale med en NIS2-kunde kan indeholde en klausul om, at I som leverandør skal håndtere sårbarheder, der udgør en risiko for kundens systemer. Formuleringen lyder rimelig, men den siger ikke i sig selv, hvilke sårbarheder det gælder, hvordan I skal finde dem, hvor hurtigt de skal håndteres, eller hvad kunden skal have at vide. Svaret hviler på, hvor formuleringen kommer fra, og på at få de åbne punkter afklaret, før I skriver under.

En klar klausul er en fordel for begge parter, fordi den gør det muligt at vise, at pligten er opfyldt. Teksten er ikke juridisk rådgivning.

Hvor formuleringen kommer fra

Bilaget til gennemførelsesforordning (EU) 2024/2690 gælder direkte for bestemte digitale udbydere, fx cloud, datacentre og administrerede tjenester. Punkt 5.1.4, litra f, nævner som et punkt, kunden skal sikre i sine kontrakter, hvor det er relevant, en forpligtelse for leverandøren til at håndtere sårbarheder, der udgør en risiko for sikkerheden i kundens net- og informationssystemer.

Kunder uden for forordningen møder samme formulering i SAMSIK’s vejledning om foranstaltninger, afsnit 4. Den nævner en forpligtelse til at håndtere sårbarheder blandt de afsnit, aftaler med direkte leverandører kan indeholde, i overensstemmelse med risikovurderingen. Bag begge ligger NIS2-direktivets artikel 21, stk. 3, som beder enheden tage hensyn til de sårbarheder, der er specifikke for hver direkte leverandør. → Artikel 21, stk. 3, for leverandører

Hvad en sårbarhed er i denne sammenhæng

NIS 2-loven definerer i § 3, nr. 29, en sårbarhed som en svaghed, modtagelighed eller fejl ved ikt-produkter eller -tjenester, som kan udnyttes af en cybertrussel. Klausulen kan være afgrænset til sårbarheder, der udgør en risiko for kundens systemer. Det er ikke alle svagheder i jeres virksomhed, men heller ikke kun dem i det, I selv har udviklet.

Sårbarheder kan nå jer fra flere kilder: jeres egne test, kundens test, meldinger udefra, scanninger og oplysninger fra producenter af komponenter, I bruger. En klausul, der kun tænker på penetrationstest, dækker kun en del af billedet. Omvendt kan en klausul, der ikke siger noget om kilder, læses, som om I skal kende enhver sårbarhed i alt, hvad I leverer, i samme øjeblik den bliver offentligt kendt. Det kan ingen leverandør leve op til, og det er bedre at skrive, hvad I faktisk gør for at blive bekendt med sårbarheder. → Meldte sårbarheder

Spørgsmål, der bør være afklaret

Før I skriver under, er det værd at få svar på følgende:

Omfang · hvilke dele af leverancen klausulen dækker, og om tredjepartskomponenter og underleverandørers dele er med.
Kilder · om I skal opsøge sårbarheder aktivt, fx ved test og scanning, eller kun håndtere dem, I bliver bekendt med.
Vurdering · hvem der vurderer, om en sårbarhed udgør en risiko for kunden, og efter hvilken skala.
Frister · om der er frister for håndtering, og om de afhænger af alvorlighed.
Besked · om og hvornår kunden skal have besked om en sårbarhed, og hvad beskeden skal indeholde.
Dokumentation · hvad I skal kunne vise kunden bagefter, fx en statusliste.
Undtagelser · hvad der sker, når en sårbarhed ikke kan rettes, fx fordi en producent ikke leverer en rettelse.

En del af svarene kan stå i et bilag til aftalen, så selve klausulen kan forblive kort. Et bilag har den fordel, at det kan opdateres, når leverancen ændrer sig, uden at hele aftalen skal genforhandles. Har I flere NIS2-kunder, kan det samme bilag bruges som udgangspunkt for dem alle. → Kundens frister for rettelser

Håndtere er ikke det samme som rette

Ordet håndtere giver plads til mere end en rettelse. Forordningens punkt 6.10.3 beskriver for enhedens egne systemer, at der laves en plan for afhjælpning, når en sårbarheds potentielle indvirkning berettiger det, og at det ellers dokumenteres og begrundes, hvorfor den ikke kræver afhjælpning. SAMSIK’s vejledning, afsnit 5.b, bruger tilsvarende ord.

Det er en fornuftig model for klausulen: håndtering kan være rettelse, et midlertidigt tiltag eller en begrundet beslutning om ikke at rette. Det vigtige er, at kunden kan se, hvilken vej der er valgt, og hvorfor. Skriv gerne i aftalen, at en accept af risikoen, der berører kunden, forelægges kunden. → Et fund, I ikke retter

Testens plads i pligten

En penetrationstest er én af de måder, I kan finde sårbarheder på, og testresultatet med en statusliste er en af de måder, I kan vise, at I håndterer dem. Testen er ikke hele pligten. Mellem to test kommer sårbarheder til jeres kendskab fra andre kilder, og de skal håndteres efter samme klausul.

Det er derfor en god idé at bruge samme statusliste for alle sårbarheder, der berører kunden, uanset hvor de kommer fra. Så kan kunden følge håndteringen ét sted, og I kan dokumentere pligten uden at lave et nyt dokument hver gang. → Status på rettelser

Et tænkt eksempel

En leverandør af et system til tidsbestilling hos en sundhedsvirksomhed får et udkast til en ny aftale. Klausulen siger kort, at leverandøren skal håndtere sårbarheder, der udgør en risiko for kundens systemer.

Leverandøren foreslår et bilag med fire punkter: klausulen dækker leverancen inklusive tredjepartskomponenter, men ikke kundens egne systemer; leverandøren tester efter en årlig plan og scanner løbende; kritiske sårbarheder meldes til kundens sikkerhedskontakt med en plan, mens andre fremgår af en kvartalsvis statusliste; risikoaccepter, der berører kunden, forelægges kunden. Sundhedsvirksomheden tilføjer en frist for kritiske sårbarheder, og bilaget underskrives sammen med aftalen.

Det skal I lade være med

At skrive under på en klausul, I ikke ved, hvordan I opfylder · afklar omfang, frister og besked først.
At love at rette alle sårbarheder · nogle kan kun afbødes eller accepteres med begrundelse.
At glemme tredjepartskomponenter · de er en del af det, kunden modtager.
At forstå pligten som en testpligt alene · sårbarheder kommer også fra andre kilder.
At have én statusliste til test og en anden til resten · kunden vil se det samlede billede.

Hvad kan og ikke kan konkluderes

En afklaret klausul gør det muligt for jer at vise kunden, at sårbarheder i leverancen bliver opdaget, vurderet og håndteret. Den sikrer ikke, at alle sårbarheder bliver fundet, og den ændrer ikke, at kunden selv har ansvar for sine egne systemer. Hvad klausulen betyder i en konkret tvist, afgøres af aftalens ordlyd. → Kritisk fund, der berører kunden