Pligt til at underrette kunden om sårbarheder

En kontraktbestemmelse om, at leverandøren skal underrette kunden om sårbarheder, lyder enkel, men den rejser straks tre spørgsmål: hvilke sårbarheder, hvornår, og med hvilket indhold. Om I kan opfylde den, afhænger af, om I har en proces, der fanger sårbarhederne, vurderer dem og sender besked til de rigtige kunder, også når det sker midt i en ferie. Kravet bør derfor læses sammen med den proces, I har, og ordlyden bør passe til den. Teksten er ikke juridisk rådgivning.

Underretning om sårbarheder er ikke det samme som underretning om hændelser. En sårbarhed er en svaghed, der kan bruges. En hændelse er noget, der er sket. Kontrakten kan have bestemmelser om begge dele, og de skal læses hver for sig.

Hvorfor kunderne beder om det

Kundens krav kan have rod i kundens egne forpligtelser. NIS2-direktivet, direktiv (EU) 2022/2555, nævner i artikel 21, stk. 2, forsyningskædesikkerhed og håndtering og offentliggørelse af sårbarheder blandt de foranstaltninger, omfattede virksomheder skal have. Artikel 21, stk. 3, siger, at virksomhederne skal tage hensyn til de sårbarheder, der er specifikke for hver direkte leverandør. En kunde, der er omfattet, har altså en grund til at ville vide, når jeres produkt har en svaghed. → Kunder omfattet af NIS2: hvad betyder det for jeres produkt?

For finansielle kunder kræver DORA, forordning (EU) 2022/2554, artikel 30, stk. 3, litra b, at kontrakter om IKT-tjenester, der understøtter kritiske eller vigtige funktioner, indeholder indberetningsforpligtelser for leverandøren, herunder underretning om udvikling, der kan have væsentlig indvirkning på leverandørens evne til at levere tjenesten. Om en bestemt sårbarhed falder ind under den formulering, afhænger af aftalen og af kundens vurdering.

Læs, hvad bestemmelsen kræver

Del bestemmelsen op i dens elementer, før I accepterer den.

Udløser · alle sårbarheder, kun dem med høj alvorlighed, kun dem, der berører kundens data, eller kun dem, der bliver udnyttet.
Kilde · kun det, I selv finder, eller også fund fra kunder, forskere og leverandører af komponenter.
Tidspunkt · når sårbarheden er kendt, når den er bekræftet, eller når en rettelse er klar.
Indhold · beskrivelse, berørte versioner, risiko, hvad kunden selv kan gøre, og hvornår rettelsen kommer.
Modtager · hvem hos kunden der skal have besked, og ad hvilken vej.

En bestemmelse om alle sårbarheder uden nærmere afgrænsning kan i værste fald betyde, at hver mindre fejl i en komponent skal meldes. Foreslå en afgrænsning efter alvorlighed og efter, om kunden er berørt. Spørg også kunden, hvad beskeden skal bruges til. En kunde, der skal vurdere sin egen risiko, har brug for andre oplysninger end en kunde, der blot skal kunne dokumentere over for sin revisor, at leverandøren melder sårbarheder.

Timing: besked før eller efter rettelsen

En besked, der kommer, før en rettelse er klar, kan give kunden mulighed for at beskytte sig selv, men den kan også fortælle mere, end godt er, til en bred kreds. En besked efter rettelsen er mere sikker, men kunden har været udsat i mellemtiden.

Aftal en fremgangsmåde for begge situationer. Som udgangspunkt kan beskeden komme, når rettelsen er klar, mens kunder med en særlig risiko får besked tidligere med en midlertidig foranstaltning. Det kræver, at I kan vurdere, hvilke kunder der er berørt, fx ud fra version, modul og opsætning, og at den vurdering kan laves hurtigt. → Testen finder noget alvorligt: skal kunderne have besked?

Processen, der skal bære løftet

Et løfte om underretning holder kun, hvis det har en ejer og en vej. Sørg for, at sårbarheder fra alle kilder lander ét sted: jeres egne test, automatiske kontroller, kundernes test, forskere og meddelelser fra leverandører af komponenter. Hver sårbarhed vurderes, og vurderingen afgør, om kontrakten udløser en besked.

Hold en liste over, hvilke kunder der har en underretningsbestemmelse, og hvad den siger. Hvis bestemmelserne er forskellige, må beskeden måske sendes på forskellige tidspunkter til forskellige kunder. Det er en grund til at ønske én fælles bestemmelse. → Jeres egne sikkerhedsvilkår frem for kundens

Selve beskeden bør have et fast format, så den kan skrives hurtigt og læses af en kunde, der ikke er tekniker. → Sikkerhedsmeddelelse til kunderne

Fund fra jeres egen penetrationstest

Bestemmelsen kan også ramme fundene i jeres årlige test. Hvis kontrakten kræver underretning om sårbarheder med høj alvorlighed, kan et højt fund i rapporten udløse en besked, før kunden får rapporten eller resuméet. Læg derfor underretningen ind i planen for testen, så den ikke kommer som en overraskelse, når rapporten lander.

Det kan være en fordel at aftale, at fund fra den planlagte test meldes samlet, fx sammen med kundeversionen af rapporten og en status på rettelserne, medmindre et fund berører kunden så alvorligt, at der skal handles med det samme. Så får kunden ét samlet billede i stedet for en række enkeltbeskeder, og I undgår at skulle formulere en besked for hvert fund, mens udviklerne stadig vurderer dem. → Åbne fund i rapporten til kunden

Et tænkt eksempel

Et softwarehus leverer et faktureringssystem til vognmænd. En kundekontrakt kræver underretning om alle sårbarheder inden for kort tid efter, at de er kendt. Softwarehuset foreslår i stedet underretning om sårbarheder med høj alvorlighed, der berører kundens data eller drift, senest når en rettelse eller en midlertidig foranstaltning er klar, og med en status, hvis rettelsen trækker ud.

Kunden accepterer. Softwarehuset tilføjer underretningen som et trin i sin proces for sårbarheder og lægger listen over kunder med bestemmelsen ved siden af.

Det skal I lade være med

Acceptere en underretning om alle sårbarheder · afgræns efter alvorlighed og berøring.
Glemme sårbarheder fra andres komponenter · de er en del af produktet.
Sende detaljer om udnyttelse i beskeden · beskriv risiko og handling, ikke fremgangsmåde.
Love underretning, I ikke har en proces for · løftet gælder også i ferien.
Blande sårbarheder og hændelser sammen · de har forskellige bestemmelser.
Give forskellige kunder forskellige løfter uden at registrere dem · så bliver nogen glemt.

Hvad kan og ikke kan konkluderes

En overholdt underretningspligt viser, at kunden får besked om de sårbarheder, I kender. Den siger intet om dem, I ikke kender. Hvilke regler der gælder ud over kontrakten, fx for producenter af produkter med digitale elementer, er et spørgsmål for sig. → Cyber Resilience Act: hvad softwarehuse skal holde øje med

Tjekliste til underretningsbestemmelsen

☐ Er udløseren afgrænset efter alvorlighed og berøring?
☐ Er det klart, hvornår beskeden skal sendes?
☐ Er indhold og modtager hos kunden aftalt?
☐ Lander sårbarheder fra alle kilder ét sted hos jer?
☐ Har I en liste over kunder med bestemmelsen?
☐ Findes der et fast format for beskeden?

Kilder

NIS2-direktivet (EU) 2022/2555: artikel 21, stk. 2, litra d og e, om forsyningskædesikkerhed og håndtering og offentliggørelse af sårbarheder, og stk. 3 om sårbarheder, der er specifikke for hver direkte leverandør.
DORA, forordning (EU) 2022/2554: artikel 30, stk. 3, litra b, om leverandørens indberetningsforpligtelser og underretning om udvikling med væsentlig indvirkning.

Senest gennemgået: oktober 2026.