Om leverandøren retter sårbarheder til tiden, viser leverandørens egne sager. Tag en stikprøve af registrerede sårbarheder, der har berørt jeres miljø, og følg hver af dem fra den blev kendt, over vurderingen til rettelsen. Hold tidsforløbet op mod den frist, I har aftalt.
Uden en aftalt frist er der ikke noget at måle imod. Så bliver auditten en beskrivelse af, hvordan leverandøren arbejder, og et grundlag for at aftale fristen.
Fristen skal stå i aftalen
I statens leverandørvejledning står et bilag om krav, der kan følges op. Kravene bør være tidsbestemte, med præcise tidsangivelser i minutter, timer eller dage, og ikke med ord som jævnligt. En rettefrist er netop sådan et krav.
Sikkerdigitals vejledning til leverandørskemaet giver et pejlemærke. Almindelige sikkerhedsopdateringer bør efter vejledningen installeres senest en måned efter, at de er frigivet, og der bør være en proces for hurtig installation af kritiske opdateringer. Det er vejledningens forventning. Det er ikke et lovkrav, og det er ikke det samme som det, I har aftalt.
Hvordan fristen formuleres i kontrakten, hører under sikkerhedsbilaget som auditgrundlag. Her handler det om at kontrollere, om den bliver overholdt.
Målestokken for de digitale udbydere
Udbydere af cloud- og administrerede tjenester er omfattet af gennemførelsesforordning (EU) 2024/2690. Bilagets punkt 6.6 handler om sikkerhedspatches. De skal installeres inden for en rimelig periode og testes, før de sættes i produktion. Fravælger udbyderen en patch, skal det dokumenteres og begrundes. Efter punkt 6.10 skal sårbarheder af kritisk betydning afhjælpes uden unødig forsinkelse, og ellers skal det dokumenteres og begrundes, hvorfor afhjælpning ikke er nødvendig.
Forordningen sætter ikke et antal dage. Den kræver til gengæld en begrundelse, når en sårbarhed ikke bliver rettet. Det er et godt kontrolpunkt, også hos leverandører, der ikke er omfattet. Bilagets punkt 5.1.4, litra f, nævner desuden, at udbyderens egne kontrakter kan forpligte leverandører til at håndtere sårbarheder, der er en risiko for udbyderens systemer.
Stikprøven
Metoden er praksis. Ingen kilde beskriver den.
1. Bed om leverandørens register. Listen over sårbarheder, der har berørt systemer i jeres leverance i en periode, med dato for registrering, vurderet alvor og dato for rettelse.
2. Vælg sager. Tag nogle med høj alvor og nogle almindelige. Tag gerne en, hvor rettelsen blev udskudt.
3. Følg sporet. For hver sag ser I efter:
- Kilde · Hvordan sårbarheden blev kendt: leverandørmeddelelse, scanning, anden kunde
- Vurdering · Hvem vurderede alvoren, og hvornår
- Beslutning · Rettelse, udskydelse eller accept, og hvem besluttede
- Rettelse · Dato for installation, og om den var testet først
- Lukning · Bevis for, at sårbarheden ikke længere findes
4. Mål tiden. Tiden fra kendt til rettet holdes op mod aftalens frist for den pågældende alvorsgrad.
5. Kig på undtagelserne. Sager uden rettelse skal have en begrundelse og en ansvarlig, der har godkendt den.
Sporbarhed er selve kontrollen
En leverandør kan sagtens rette det meste hurtigt og alligevel have huller. Det, der gør det svært for jer, er sager, der forsvinder: en sårbarhed, der blev nævnt i en mail og aldrig registreret, eller en rettelse, der blev planlagt og aldrig gennemført.
Et tænkt eksempel: Registret viser ti sager i jeres miljø i et halvt år. Ni er rettet inden for fristen. Den tiende står som udskudt med noten “afventer kunde”. Ingen hos jer kender sagen. Det fund handler mindre om tid og mere om, at beslutningen er lagt hos jer uden jeres viden.
Når rettelsen ikke findes endnu
Nogle gange er der ingen rettelse at installere. Producenten har ikke udsendt en, eller den kommer først om flere uger. Så måler fristen ikke det, den skulle. Spørg i stedet, hvad leverandøren gjorde i mellemtiden. Blev sårbarheden afbødet på anden vis, fx ved at lukke en adgang eller slå en funktion fra? Blev I orienteret? Og blev rettelsen installeret, da den kom?
Sager af den slags hører med i stikprøven. De viser, hvordan leverandøren handler, når den ikke selv har løsningen, og om den husker at vende tilbage til sagen.
Det, I selv skal gøre
Nogle rettelser kræver, at I godkender en nedetid eller tester jeres egen anvendelse. Kontrollér, at leverandøren ved, hvem hos jer der kan træffe den beslutning. Kundens egen håndtering af sårbarheder i en NIS2-audit er beskrevet under kundens egen sikkerhedsaudit. Den tekniske kontrol af, om systemerne faktisk er opdateret, er et teknisk kontrolpunkt.
Hvad det kræver, og hvad det koster at lade være
Det kræver en frist i aftalen opdelt efter alvor, at leverandøren fører et register, og at aftalen giver jer indsigt i det. Stikprøven kan gennemgås på et møde.
Uden en stikprøve ved I ikke, om sårbarheder i jeres miljø bliver rettet, eller om de ligger og venter på en beslutning, ingen har truffet.
Det skal I lade være med
- At bruge en vejlednings forventning som jeres frist · aftal en frist, der passer til jeres risiko.
- At nøjes med en procentsats for rettede sager · følg de enkelte sager fra kendt til lukket.
- At overse de udskudte sager · de er dér, ansvaret glider.
Det skal auditten kunne vise
- ☐ Aftalens frister for rettelse, opdelt efter alvor.
- ☐ Leverandørens register over sårbarheder for den gennemgåede periode.
- ☐ Stikprøve med kilde, vurdering, beslutning, rettelse og lukning.
- ☐ Begrundelse og godkendelse for sager, der ikke er rettet.
- ☐ Leverandørens svar på overskredne frister.
Kilder
- Center for Cybersikkerhed og Digitaliseringsstyrelsen, Cybersikkerhed i leverandørforhold, 2. udgave maj 2022, bilag 5, læst 12. november 2026.
- sikkerdigital.dk, Få overblik over din leverandørs IT-sikkerhed (leverandørpakken), pkt. 1.D, læst 12. november 2026.
- Kommissionens gennemførelsesforordning (EU) 2024/2690, bilag punkt 5.1.4, 6.6 og 6.10, læst 12. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find rettefristerne i jeres aftale, og bed leverandøren om registret over sårbarheder i jeres miljø det seneste halve år.
Læs også: Handlingsplanen efter auditten · Mellem to audits
→ Kontakt · Tlf. 70 13 63 23 · Leverandøraudit hos Nielco IT
