Kundens frister for rettelser: når fristen står i aftalen

En frist i aftalen er et løfte, I har givet kunden, og ikke et krav fra NIS2. Hverken direktivet, den danske NIS 2-lov eller gennemførelsesforordning 2024/2690 fastsætter et bestemt antal dage, hvor et fund hos en leverandør skal være rettet. Når en NIS2-kunde alligevel skriver frister ind, kommer de fra kundens egen risikovurdering og politik, og det er aftalens ordlyd, der afgør, hvad I har forpligtet jer til.

Svaret hviler derfor på to spor: hvad lovteksterne beder kunden om, og hvad I selv kan levere. Teksten er ikke juridisk rådgivning.

Hvor kundens frister kommer fra

Forordning 2024/2690 gælder direkte for bestemte digitale udbydere, fx cloud, datacentre og administrerede tjenester. Bilagets punkt 6.10.2, litra c, beder de enheder afhjælpe sårbarheder, de har konstateret som kritiske for deres drift, uden unødig forsinkelse. SAMSIK’s vejledning om foranstaltninger bruger samme tanke for de øvrige enheder under loven: kritiske sårbarheder bør håndteres uden unødige forsinkelser.

Uden unødig forsinkelse er ikke et tal. Kunden oversætter det til frister i sin egen politik, og når en del af kundens drift ligger hos jer, ender fristerne i leverandøraftalen. Forordningens punkt 5.1.4, litra f, nævner netop en kontraktlig pligt for leverandøren til at håndtere sårbarheder, der udgør en risiko for kundens systemer. → Pligt til at håndtere sårbarheder i leverandøraftalen

Læs klausulen før underskriften

En frist kan være skrevet på forskellige måder. Før I skriver under, bør I kunne svare på disse spørgsmål:

Hvad udløser fristen · testrapportens dato, jeres egen konstatering eller kundens besked til jer?
Hvilken skala gælder · testerens alvorlighed, kundens egen skala eller en bestemt score?
Hvad tæller som overholdt · rettelsen udrullet, et midlertidigt tiltag eller en efterprøvet rettelse?
Hvad omfatter fristen · kun jeres egen kode, eller også komponenter fra andre?
Hvad sker der ved overskridelse · besked, ny plan, eller et vilkår med økonomiske følger?

Det sidste punkt er et spørgsmål for jeres jurist, ikke for testeren. Klausulens skala er derimod et teknisk spørgsmål, og den har stor betydning. Måler kunden på en score, kan et fund skifte frist, alene fordi det vurderes anderledes. → CVSS i kundens krav

Kontraktfrister og jeres egne frister

Nogle leverandører har allerede interne frister for rettelser, fastsat ud fra deres egen risiko. Har I det ikke, er en kundeklausul en god anledning til at lægge dem fast. Sammenlign dem med kundens:

Kundens frist er længere · I følger jeres egen, og kunden får rettelsen tidligere end lovet.
Fristerne passer sammen · I kan henvise til samme proces over for alle kunder.
Kundens frist er kortere · I skal enten ændre jeres proces eller forhandle klausulen.

Har I flere NIS2-kunder med hver deres frister, bliver den korteste i praksis styrende for den fælles platform. Overvej det, før I accepterer en frist, der er strammere end det, I kan levere til alle. → Flere NIS2-kunder med forskellige krav

Når en frist ikke kan holdes

Det kan ske, at en rettelse kræver en producents opdatering, en større ændring eller en driftspause, kunden selv skal godkende. Så er det tidspunktet for besked, før fristen udløber, ikke bagefter.

En god besked indeholder årsagen, et midlertidigt tiltag, der mindsker risikoen, og en ny dato, som I kan stå inde for. Kunden kan så tage stilling i sin egen risikostyring. Skriv beskeden, så den kan læses af en person hos kunden, der ikke kender fundet i detaljer, fordi den kan ende i kundens dokumentation over for ledelsen eller tilsynet. Gem kundens svar sammen med fundet, så det senere kan ses, at den nye dato var aftalt og ikke blot skrevet ind. Forordningens punkt 6.10.3 beskriver, at en sårbarhed enten skal have en plan for afhjælpning eller en dokumenteret begrundelse for, at den ikke kræver det. Den logik passer også på jeres forklaring til kunden. → Midlertidige tiltag, når en rettelse tager tid

Det, rapporten skal give jer til fristen

En frist regnet fra rapportens dato stiller krav til selve rapporten. Bed testeren om tre ting, som gør det muligt at overholde og dokumentere fristen:

En entydig dato · for hvornår rapporten er endelig, så fristens start ikke kan diskuteres.
En alvorlighed pr. fund · på en skala, I kan oversætte til kundens, med en kort begrundelse.
Et nummer pr. fund · som følger fundet gennem statuslisten og retesten.

Kommer fund til jer løbende under testen, så aftal med kunden, om fristen starter ved den løbende besked eller ved den endelige rapport. Uden den aftale kan samme fund få to startdatoer. Er der tvivl om et funds alvor, skal den afklares hurtigt, fordi tvivlen ellers spiser af fristen. → Hvad I skal bede testleverandøren om

Et tænkt eksempel

Et softwarehus leverer et journalsystem til en privat klinikkæde, der er omfattet af NIS2. Aftalen siger, at kritiske fund skal være rettet inden for en frist regnet fra rapportens dato. Softwarehuset får en rapport med ét kritisk fund, som sidder i en komponent, hvor producenten endnu ikke har en rettelse.

Softwarehuset giver straks klinikkæden besked, slår den berørte funktion fra og foreslår en ny dato knyttet til producentens udgivelse. Klinikkæden accepterer skriftligt og noterer den nye dato i sin egen opfølgning på leverandøren. Statuslisten viser den oprindelige frist, den nye dato og begrundelsen. Da rettelsen er på plads, efterprøves den, og fundet lukkes. → Status på rettelser

Det skal I lade være med

At acceptere en frist uden at kende skalaen · samme fund kan få to forskellige frister.
At love kortere frister end jeres proces kan bære · overskridelser bliver reglen.
At melde overskridelsen, når fristen er gået · kunden skal kunne nå at reagere.
At regne et midlertidigt tiltag som en rettelse · skriv tydeligt, hvad der er gjort.
At kalde en frist et NIS2-krav · fristen står i aftalen, ikke i loven.

Hvad kan og ikke kan konkluderes

Overholdte frister viser kunden, at fund fra en bestemt test er håndteret i det tempo, I har lovet. De viser ikke, at leverancen er uden svagheder, og en overskredet frist er ikke i sig selv et brud på NIS2. Hvad overskridelsen betyder i aftalen, afgør aftalens ordlyd. Generel viden om at fastsætte egne frister findes på penetrationtest.dk.

Tjekliste til fristklausulen

☐ Ved I, hvad der starter fristen?
☐ Ved I, hvilken skala alvorligheden måles på?
☐ Er det skrevet, hvad der tæller som overholdt?
☐ Er fund i andres komponenter behandlet i klausulen?
☐ Passer fristen til jeres interne frister og andre kunders krav?
☐ Er det aftalt, hvordan I melder en frist, der ikke kan holdes?

Kilder

Gennemførelsesforordning (EU) 2024/2690: bilagets punkt 5.1.4, litra f, 6.10.2, litra c, og 6.10.3. Gælder for de digitale udbydere, der er nævnt i artikel 1.
SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 4 om aftaler med leverandører og afsnit 5.b om kritiske sårbarheder.
NIS 2-loven, lov nr. 434 af 6. maj 2025: § 6, stk. 1, nr. 4 og 5, om forsyningskædesikkerhed og håndtering af sårbarheder.

Senest gennemgået: oktober 2026.