En frist for sikkerhedsopdateringer kan kun efterprøves, hvis den er skrevet i dage og målt fra en bestemt dato. Forordningen siger “inden for en rimelig periode”, og det er driftens opgave at omsætte det til tal, som man bagefter kan måle opdateringerne imod.
De tal, andre ordninger bruger, er et godt sted at begynde. De binder ikke danske virksomheder, men de viser, hvilket niveau myndigheder i andre lande har fundet rimeligt, og de gør jeres valg lettere at begrunde.
Hvad loven og vejledningerne siger
For de omfattede enheder kræver bilaget til forordning 2024/2690 i punkt 6.6.1, at sikkerhedspatches lægges på inden for en rimelig periode efter udgivelsen. De testes før produktion og stammer fra pålidelige kilder. Hvor en patch ikke findes eller ikke anvendes, træffes yderligere foranstaltninger, og en restrisiko accepteres. Punkt 6.6.2 giver lov til at vælge en patch fra, hvis ulemperne er større end fordelene, men valget skal dokumenteres og begrundes. Og punkt 6.10.2, litra c, kræver, at kritiske sårbarheder rettes uden unødig forsinkelse.
For finansielle enheder skal procedurerne efter artikel 10 i DORA’s tekniske standard fastsætte frister for installation af korrektioner og opdateringer, og fejlafhjælpningsprocedurer, hvis fristerne ikke kan overholdes. Standarden kræver også nødprocedurer for korrektion. Den sætter ingen dagetal.
SAMSIK’s Cyberforsvar der virker siger, at der skal fastlægges frister for, hvor hurtigt sikkerhedsopdateringer idriftsættes efter frigivelse. Vejledningen er en anbefaling, og den sætter heller ikke tal på.
De tal, der findes
Fire tal er læst til denne artikel. De står her side om side som sitets sammenstilling, hver med sin egen afgrænsning.
- Statens tekniske minimumskrav, september 2025 · Frist: 30 dage · Gælder for: Egenudviklet software på internetvendte tjenester, regnet fra myndigheden har færdigtestet opdateringen
- Cyber Essentials v3.3, april 2026 (Storbritannien) · Frist: 14 dage · Gælder for: Opdateringer, der retter sårbarheder, leverandøren kalder kritiske eller høje, med CVSS v3 basisscore 7 eller derover, eller hvor leverandøren ikke oplyser niveauet
- NCSC, februar 2024, gennemgået maj 2026 (Storbritannien) · Frist: 5 dage · Gælder for: Internetvendte tjenester og software
- NCSC, samme vejledning · Frist: 7 dage, automatisk · Gælder for: Styresystem og applikationer
- NCSC, samme vejledning · Frist: 14 dage · Gælder for: Interne eller luftgabsadskilte tjenester
Statens 30 dage er obligatoriske for statslige myndigheder, men kun for egenudviklet software på internetvendte tjenester. Cyber Essentials anbefaler 14 dage for alle opdateringer, men kræver det kun for de alvorlige. NCSC’s tal er bedste praksis og gælder alle opdateringer uanset alvorlighed. NCSC tilføjer, at fristerne er for lange, når en sårbarhed bliver aktivt udnyttet.
Fra tal til jeres egne frister
En brugbar fristpolitik har få kategorier, som driften kan genkende. Et tænkt eksempel kunne dele efter eksponering, sådan som NCSC gør: internetvendte systemer, klienter og interne servere. Til hver kategori hører en frist i dage og en særlig, kortere frist for sårbarheder, der er kendt udnyttet.
Det vigtigste er startdatoen. Regnes fristen fra producentens udgivelse, fra den dag driften fik besked, eller fra den dag testen var færdig? Statens vejledning regner for egenudviklet software fra færdigtestet opdatering. For andet software er udgivelsesdatoen den, der er lettest at efterprøve, fordi den står hos producenten.
Fristerne skal skrives ned, godkendes og være kendt af dem, der opdaterer. Først da kan de måles.
Sådan måles fristen
Målingen bygger på to datoer pr. opdatering: hvornår den blev tilgængelig, og hvornår den var installeret på maskinerne. Den første kommer fra producenten, den anden fra maskinerne selv eller fra en uafhængig scanning. Forskellen i dage holdes op mod fristen for maskinens kategori.
Resultatet kan vises enkelt: for en periode, hvor mange opdateringer der blev installeret inden for fristen, og hvilke der ikke gjorde. De sene er fundene, og for hver af dem er spørgsmålet, om der findes en dokumenteret undtagelse.
Nødproceduren
En almindelig frist passer ikke, når en sårbarhed bliver aktivt udnyttet. NCSC skriver, at fristerne da er for lange, og DORA’s standard kræver nødprocedurer for korrektion. Gennemgangen spørger derfor, om der findes en skrevet vej for de hastende tilfælde: hvem der kan beslutte at opdatere uden for det normale vindue, hvordan testen afkortes, og hvordan beslutningen dokumenteres bagefter. Bilagets punkt 6.4.3 om nødændringer beder om, at sådanne ændringer dokumenteres med begrundelse. Den dokumentation er beviset for, at nødvejen blev brugt, og at den ikke blev en genvej til at springe testen over i almindelighed.
Undtagelser og fravalg
Både forordningen og DORA’s standard regner med, at en frist ikke altid kan holdes. Forordningen kræver, at et fravalg dokumenteres og begrundes. DORA’s standard kræver en procedure for, hvad der sker, når fristen overskrides. NCSC placerer et fravalg af en opdatering hos ledelsen som en risikobeslutning.
En undtagelse bør derfor have en begrundelse, en kompenserende foranstaltning, en ejer på ledelsesniveau og en udløbsdato. En undtagelse uden udløb er i praksis en ny, permanent frist, som ingen har besluttet.
Når opdateringen afhænger af en leverandør, flytter spørgsmålet sig til aftalen. Kundens kontrol af leverandørens håndtering hører til leverandøraudit. Hvor fristpolitikken passer ind i en bredere gennemgang af sikkerheden og NIS2, står dér.
Hvad det kræver, og hvad det koster at lade være
Det kræver en skrevet fristpolitik, en måde at hente installationsdatoen fra maskinerne og en undtagelsesliste, der bliver holdt ved lige. Det tunge arbejde er første opgørelse. Derefter kan den gentages.
Uden frister i dage kan ingen vise, om opdateringerne kommer rettidigt. “Rimelig periode” bliver det, der nu engang skete, og forsinkelserne bliver først synlige, når en sårbarhed er blevet udnyttet.
Det skal I lade være med
- At overtage et andet lands tal som et dansk krav · tallene er målestokke, I selv vælger at bruge.
- At sætte en frist uden en startdato · så kan den ikke måles.
- At give undtagelser uden udløb · de bliver til permanente frister, ingen har besluttet.
Det skal gennemgangen kunne vise
- ☐ En godkendt fristpolitik i dage pr. kategori med startdato.
- ☐ En måling af installationstid holdt op mod fristen for en afgrænset periode.
- ☐ En liste over overskridelser med dokumenteret begrundelse.
- ☐ En undtagelsesliste med kompenserende foranstaltning, ejer og udløb.
Kilder
- Gennemførelsesforordning (EU) 2024/2690, dansk tekst, bilagets punkt 6.4.3, 6.6.1, 6.6.2 og 6.10.2, læst 13. november 2026.
- Delegeret forordning (EU) 2024/1774, artikel 10, stk. 4, litra b og d, læst 13. november 2026.
- SAMSIK, Cyberforsvar der virker, 4. udgave juli 2023, område 1, læst 13. november 2026.
- Vejledning til de tekniske minimumskrav til it-sikkerhed i staten, september 2025, afsnit 3.9, læst 13. november 2026.
- NCSC, Cyber Essentials: Requirements for IT Infrastructure v3.3, april 2026, Security Update Management, læst 13. november 2026.
- NCSC, Put in place a policy to update by default, læst 13. november 2026.
- NCSC, Vulnerability management, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Vælg én kritisk opdatering fra sidste måned, og mål antallet af dage fra udgivelse til installation på jeres internetvendte systemer.
Læs også: Undtagelseslisten · Kantudstyr først
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
