En digital enhed under forordning 2024/2690 må vælge ikke at installere en sikkerhedspatch, hvis ulemperne ved den er større end fordelene for sikkerheden. Afgørelsen skal dokumenteres og begrundes. Det samme gælder en sårbarhed, enheden vurderer, ikke kræver afhjælpning.
Begrundelserne er det, der adskiller en styret patchproces fra en, der halter. Ingen enhed installerer alt med det samme. Auditten ser efter, om det, der ikke er installeret, er et valg, nogen har truffet og skrevet ned.
Patchstyring i punkt 6.6
Punkt 6.6.1 kræver procedurer, der sikrer, at sikkerhedspatches:
- anvendes inden for en rimelig periode
- testes, før de anvendes i produktionssystemer
- stammer fra pålidelige kilder og kontrolleres for integritet
- suppleres med yderligere foranstaltninger og accept af resterende risici, hvor en patch ikke er tilgængelig eller ikke anvendes.
Listen er forenklet gengivet. Forordningen sætter ikke et antal dage. “Rimelig periode” skal enheden selv fastlægge, typisk efter alvorlighed og efter risikovurderingen. Det sidste er en tolkning.
Punkt 6.6.2 siger, at enheden kan vælge ikke at anvende en given sikkerhedspatch, hvis ulemperne ved at anvende den er større end cybersikkerhedsfordelene. Afgørelsen skal behørigt dokumenteres og begrundes.
Sårbarhedshåndtering i punkt 6.10
Efter punkt 6.10.2 skal enheden bl.a.:
- overvåge oplysninger om sårbarheder fra CSIRT’er, myndigheder og leverandører
- udføre sårbarhedsscanninger med planlagte intervaller, hvor det er relevant, og dokumentere resultaterne
- uden unødig forsinkelse afhjælpe sårbarheder af kritisk betydning
- have en procedure for offentliggørelse af sårbarheder efter den nationale koordinerede politik.
Efter punkt 6.10.3 udarbejdes en plan for afhjælpning, hvor indvirkningen af en sårbarhed berettiger det. I andre tilfælde dokumenterer og begrunder enheden årsagen til, at sårbarheden ikke kræver afhjælpning.
To slags fravalg
Forordningen har altså to steder, hvor enheden må lade være og skal begrunde det. Det ene er en patch, der ikke installeres efter 6.6.2. Det andet er en sårbarhed, der ikke afhjælpes efter 6.10.3. Begge kan forekomme samtidig, fx når en leverandør har en rettelse, der ødelægger en funktion, kunderne har brug for.
Et tænkt eksempel er en udbyder, hvis kundeportal kører på en version, hvor den seneste patch bryder integrationen til et faktureringssystem. Begrundelsen beskriver konflikten, risikoen ved den åbne sårbarhed, den midlertidige foranstaltning, fx en regel i firewallen, der begrænser adgangen, og datoen for, hvornår sagen tages op igen. Den, der har ansvaret for risikoen, godkender den.
Sådan prøver auditor punkterne
Det følgende er almindelig auditpraksis.
Auditor læser procedurerne og ser efter, hvordan “rimelig periode” er defineret. Dernæst beder auditor om resultater af de seneste sårbarhedsscanninger og om en oversigt over manglende patches på et udvalg af systemer.
For hvert fund på oversigten ser auditor efter én af tre ting: at patchen er installeret inden for den fastsatte periode, at der er en plan for afhjælpning, eller at der er en dokumenteret begrundelse for at lade være. Et fund uden nogen af de tre er en mangel.
Ved de begrundede fravalg ser auditor efter, at begrundelsen er forståelig, at den nævner den kompenserende foranstaltning, og at den er godkendt. Kravet om forståelige begrundelser står i artikel 2, stk. 2, og er beskrevet i begrundelserne efter artikel 2, stk. 2.
Kritiske sårbarheder får særlig opmærksomhed. Auditor måler tiden fra offentliggørelse til afhjælpning for nogle kritiske sårbarheder og vurderer, om den passer med “uden unødig forsinkelse”.
Den tekniske kontrol af, om patches faktisk er installeret på hver maskine, hører til en teknisk gennemgang af systemerne. Lovens tilsvarende krav er beskrevet i audit af sårbarhedshåndtering.
Fra advarsel til sag
Kravet om at følge med i sårbarhedsoplysninger nævner tre kilder: CSIRT’er, myndigheder og leverandører. Auditor spørger, hvem der læser advarslerne, hvor ofte, og hvordan en relevant advarsel bliver til en sag i driften. En abonnementsliste, ingen reagerer på, viser ikke overvågning. Et spor fra en konkret advarsel til en lukket sag er et stærkt bevis.
Hvad det kræver, og hvad det koster at lade være
Det kræver procedurer med en defineret periode for patches, en plan for scanninger, en oversigt over åbne sårbarheder og en skabelon til begrundelser. Den, der ejer risikoen, skal godkende fravalgene, og fravalgene skal tages op igen.
Uden begrundelserne ser hver manglende patch ud som en forglemmelse. Med dem kan enheden vise, at den har vejet sikkerhed mod drift og truffet et valg. Kritiske sårbarheder, der står åbne uden plan, er et af de punkter, der hurtigst skader kundernes tillid, hvis de bliver udnyttet.
Det skal I lade være med
- At lade “rimelig periode” stå udefineret · procedurerne skal sige, hvad den er.
- At udskyde en patch uden skriftlig begrundelse · punkt 6.6.2 kræver den.
- At scanne uden at dokumentere resultaterne · punkt 6.10.2 kræver det.
Det skal auditten kunne vise
- ☐ Procedurer for patchstyring med en defineret periode og test før produktion.
- ☐ Dokumenterede sårbarhedsscanninger med planlagte intervaller.
- ☐ En plan for afhjælpning eller en begrundelse for hver åben sårbarhed.
- ☐ Begrundede afgørelser om patches, der ikke installeres, med kompenserende foranstaltninger.
- ☐ Tid fra offentliggørelse til afhjælpning for kritiske sårbarheder.
- ☐ En procedure for offentliggørelse af sårbarheder.
Kilder
- Kommissionens gennemførelsesforordning (EU) 2024/2690 af 17. oktober 2024, artikel 2 og bilaget punkt 6.6 og 6.10, https://publications.europa.eu/resource/celex/32024R2690, læst 12. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Tag de tre ældste manglende patches på jeres vigtigste servere, og find begrundelsen for hver af dem.
Læs også: Risikostyring efter punkt 2.1 · Tekniske stikprøver i en NIS2-audit
→ Kontakt · Tlf. 70 13 63 23 · NIS2-audit hos Nielco IT
