Fund, der også rammer andre kunder

En test bestilt af én kunde kan finde en svaghed i noget, som også andre kunder bruger: en fælles platform, en standardopsætning, en delt komponent eller et værktøj, I bruger til at drifte dem alle. Spørgsmålet er så, hvem der skal have besked, i hvilken rækkefølge og med hvilket indhold. Svaret er, at de berørte kunder skal kunne handle på fundet, uden at nogen af dem får oplysninger om de andre, og at rækkefølgen bestemmes af risiko og aftaler, ikke af hvem der betalte for testen.

Det hviler på jeres aftaler med hver kunde og på den fortrolighed, I skylder dem alle. NIS2-reglerne giver ikke en fælles opskrift for leverandører; de beskriver, hvad den enkelte kunde kan kræve af jer. Teksten er ikke juridisk rådgivning.

Hvorfor sagen ikke kun angår den kunde, der bestilte testen

Gennemførelsesforordning 2024/2690 er bindende for en afgrænset kreds af digitale udbydere, fx cloud, datacentre og administrerede tjenester. Bilagets punkt 5.1.4 nævner, hvad sådanne kunders aftaler med leverandører kan indeholde, bl.a. en pligt til at håndtere sårbarheder, der udgør en risiko for kundens systemer (litra f), og til at underrette om hændelser (litra d). SAMSIK’s vejledning om foranstaltninger har lignende punkter for de øvrige enheder under NIS 2-loven.

Har flere kunder sådanne klausuler, kan et fund i en fælles del udløse en pligt over for hver af dem. Testens bestiller har ikke forrang i den forstand. Bestilleren har ret til rapporten; de andre kunder kan have ret til at kende risikoen. → Pligt til at håndtere sårbarheder i leverandøraftalen

Find ud af, hvem der faktisk er berørt

Før nogen får besked, skal I vide, hvem der er udsat. Det kræver et overblik, som testeren ikke kan give, fordi testeren kun har set den bestilte del:

Samme version · kører de andre kunder den version, hvor fundet blev gjort?
Samme opsætning · findes den indstilling eller funktion, fundet afhænger af, hos dem?
Samme adgangsvej · kan svagheden nås på samme måde i deres miljø?
Fælles værktøjer · rammer fundet noget, I bruger til at drifte flere kunder, fx et administrationsværktøj eller en fjernadgang?

Gør undersøgelsen skriftligt, og gem den. Hvis en kunde senere spørger, hvorfor den ikke fik besked, er notatet om versioner og opsætninger svaret. Svaret kan være, at kun en del af kunderne er udsatte. Så skal kun de have besked om risikoen, og resten kan få en kort orientering, hvis aftalerne kræver det. → Kundespecifik opsætning eller fælles platform

Rækkefølgen af beskeder

Rækkefølgen bør afgøres af to forhold: hvem der er mest udsat, og hvad aftalerne siger om frister for besked. En praktisk rækkefølge kan se sådan ud:

Afgør, om fundet kan udnyttes nu · er det tilfældet, haster et midlertidigt tiltag for alle berørte, før beskederne skrives færdige.
Kunder med kort frist eller høj eksponering · fx kunder, hvor den svage del er tilgængelig fra internettet.
Øvrige berørte kunder · samme indhold, tilpasset deres opsætning.
Testens bestiller · får den fulde rapport som aftalt, uanset hvornår de andre orienteres.

Bestilleren behøver ikke komme sidst. Pointen er, at bestillerens rapport ikke må blive den kanal, de andre kunder hører om fundet gennem.

Indholdet i beskeden til de andre kunder

De andre kunder har ikke bestilt testen og skal ikke have rapporten. De har brug for en kort, selvstændig besked:

Hvad der er berørt · den del af leverancen, der er tale om, med deres egne navne på den.
Hvad risikoen er · i et sprog, kundens sikkerhedsansvarlige kan bruge i sin egen vurdering.
Hvad I har gjort · midlertidigt tiltag og plan for rettelse.
Hvad kunden selv skal gøre · hvis noget.
Hvornår næste status kommer · med en dato.

Beskeden må ikke afsløre, hvem der bestilte testen, eller noget om bestillerens systemer. Skriv heller ikke, at fundet stammer fra en kundes test, hvis aftalen med bestilleren gør selve testen fortrolig. Det er nok at skrive, at svagheden er konstateret ved en sikkerhedstest. Skriv beskederne ud fra én fælles tekst, som tilpasses den enkelte kunde, så indholdet ikke glider fra hinanden, og så I bagefter kan vise, at alle berørte fik de samme oplysninger. → Samme rapport til flere kunder

Når I selv er omfattet af NIS 2-loven

Er I selv en væsentlig eller vigtig enhed, fx som udbyder af administrerede tjenester, har I også egne pligter. NIS 2-lovens § 15, stk. 2, beskriver, at sådanne enheder uden unødigt ophold oplyser de modtagere af deres tjenester, som potentielt er berørt af en væsentlig cybertrussel, om foranstaltninger, modtagerne kan træffe. Om et testfund er en væsentlig cybertrussel i lovens forstand, er en vurdering, I selv skal foretage og kunne begrunde. → MSP og NIS2

Et tænkt eksempel

En leverandør af et fælles bookingsystem til flere regionale færgeoperatører får testet systemet på bestilling fra én af dem. Testen finder en svaghed i en funktion, som alle operatører bruger, men som kun tre har gjort tilgængelig for passagerer.

Leverandøren lukker funktionen for passagerer samme dag. De tre udsatte operatører får hver en besked om risikoen, tiltaget og datoen for næste status. De øvrige får en kort orientering om, at en svaghed er rettet, og at deres opsætning ikke var udsat. Bestilleren får rapporten som aftalt. Ingen af beskederne nævner, hvem der bestilte testen. → Delte platforme hos MSP’en

Det skal I lade være med

At sende bestillerens rapport til andre kunder · den er bestillerens og kan indeholde oplysninger om bestillerens miljø.
At vente med de andre, til bestilleren har læst rapporten · deres risiko venter ikke.
At give alle kunder samme besked uden at undersøge udsathed · uudsatte kunder bruger tid på en risiko, de ikke har.
At nævne andre kunders navne · heller ikke for at berolige.
At lade beskederne være uden dato · ingen kan se, hvornår de var orienteret.

Hvad kan og ikke kan konkluderes

Et fund i en fælles del viser, at svagheden fandtes i den version og opsætning, testen dækkede. Det viser ikke, at alle kunder er udsatte på samme måde, og det siger intet om dele, testen ikke så. Hvad den enkelte kunde skal gøre ud fra jeres besked, afgør kunden i sin egen risikovurdering.

Tjekliste, når et fund rammer flere kunder

☐ Er det undersøgt, hvilke kunder der kører den berørte version og opsætning?
☐ Er der et midlertidigt tiltag for alle udsatte?
☐ Er rækkefølgen af beskeder begrundet i risiko og aftaler?
☐ Er beskederne uden oplysninger om bestilleren og andre kunder?
☐ Har hver besked en dato for næste status?
☐ Har I vurderet, om I selv har pligter efter NIS 2-loven?

Kilder

Gennemførelsesforordning (EU) 2024/2690: bilagets punkt 5.1.4, litra d og f. Gælder for de digitale udbydere, der er nævnt i artikel 1.
NIS 2-loven, lov nr. 434 af 6. maj 2025: § 15, stk. 2, om oplysning til modtagere af tjenester ved væsentlige cybertrusler.
SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 4 om aftaler med leverandører.

Senest gennemgået: oktober 2026.