Cyber Resilience Act forlanger ingen rettelse af hver eneste fejl i jeres softwareprodukt. Den kræver, at hver sårbarhed bliver vurderet og håndteret straks i forhold til risikoen, og at I kan dokumentere, hvad der skete.
Der står ingen rettefrist i dage i forordningen. De frister, et softwarehus arbejder efter, er dets egne. Det gør dem ikke mindre vigtige, for det er dem, en gennemgang holder op mod de faktiske sager. Kravene i bilag I, del II, gælder fra 11. december 2027.
Hvad forordningen selv siger
Bilag I, del II, nr. 1, pålægger fabrikanten at identificere og dokumentere sårbarheder og komponenter i produktet. Nr. 2 siger, at sårbarheder i forbindelse med risiciene straks skal håndteres og afhjælpes, herunder ved sikkerhedsopdateringer. Nr. 3 handler om at prøve og gennemgå produktets sikkerhed effektivt og med jævne mellemrum.
Artikel 13, stk. 8, sidste afsnit, kræver passende politikker og procedurer til at håndtere og afhjælpe potentielle sårbarheder, der indberettes fra interne eller eksterne kilder. Kommissionens FAQ (punkt 4.1.3) lægger til, at kravene i del II skal opfyldes i hele supportperioden, uanset hvad risikovurderingen ellers siger om del I.
Ordet “straks” er altså lovens. En bestemt længde på “straks” er det ikke.
Kommissionens skel mellem at vurdere og at rette
Kommissionens FAQ (punkt 4.3.1) svarer, at der i supportperioden ikke skal laves en rettelse for hver eneste sårbarhed. Fabrikanten tager stilling til relevans og risiko og går i gang med at afhjælpe uden ophold. Afhjælpning kan have flere former:
- straksrettelser
- en meddelelse om en midlertidig løsning, fulgt op af en opdatering
- ændrede brugervejledninger
- konfigurationsvejledning, der slår den berørte funktion fra
FAQ’en giver tre tænkte eksempler. En smart home-hub med en fejl, der tillader fjernudførelse af kode, får en straksrettelse og vejledning. En router med en sårbarhed i et bibliotek, der ikke bruges, kan nøjes med dokumentation og eventuelt ingen særskilt opdatering. En printer med en fejlsøgningsgrænseflade, der kræver fysisk indgreb, får dokumentation, opdateret teknisk dokumentation og anbefalinger til brugerne.
Svarene i FAQ’en er foreløbige og binder ingen. De viser alligevel, hvordan reglen læses i Bruxelles, og det er den læsning, en gennemgang tager udgangspunkt i.
Registret efter artikel 13, stk. 7
Efter artikel 13, stk. 7, skal fabrikanten føre en systematisk og forholdsmæssig dokumentation af produktets relevante cybersikkerhedsforhold. Den omfatter sårbarheder, fabrikanten får kendskab til, og hvad tredjeparter oplyser af betydning. Risikovurderingen skal ajourføres efter behov. Lovteksten bruger ikke ordet register. Vi kalder den systematiske dokumentation for sårbarhedsregistret her, fordi det er sådan, de fleste softwarehuse fører den.
Hvilke felter registret har, bestemmer I selv. Et tænkt minimum, som gør registret brugbart som bevis:
- Id og kilde · (intern test, kundemelding, offentlig database)
- Dato for kendskab · (datoen, meldingen kom ind)
- Berørte versioner · (alle versioner fra 4.2 og frem)
- Vurdering · (kan udnyttes over netværket uden login)
- Beslutning og begrundelse · (rettes i næste sikkerhedsopdatering)
- Afhjælpning og dato · (opdatering frigivet, meddelelse sendt)
Registret er også stedet, hvor oplysninger udefra samles, som meldinger fra komponentleverandører, poster i offentlige sårbarhedsdatabaser og henvendelser fra kunder. Stykke 7 nævner udtrykkeligt oplysninger fra tredjeparter. En sårbarhed i en afhængighed hører derfor med på lige fod med en fejl i jeres egen kode.
Uden en beslutning med begrundelse er registret en liste over fund. Med den bliver det et spor, der kan følges.
Egne frister holdt op mod sagerne
Mange softwarehuse fastsætter interne frister efter alvor. Det er praksis og ikke et lovkrav. Fristerne er nyttige, fordi de gør “straks” målbart for jer selv, og fordi en gennemgang kan sammenligne dem med virkeligheden.
I en gennemgang er det almindeligt at trække et antal lukkede og åbne sager fra registret og følge hver fra dato for kendskab til afhjælpning. Spørgsmålene er enkle. Blev sagen vurderet? Fulgte forløbet jeres egen frist? Hvis ikke, står der en begrundelse? Blev risikovurderingen opdateret, hvor fundet rokkede ved den?
Kommissionens FAQ nævner en kommende horisontal standard om sårbarhedshåndtering. I november 2026 har vi ikke set dens reference offentliggjort i EU-Tidende, så der er endnu ingen standard, der giver formodning om overensstemmelse på dette punkt. Gennemgangen måler derfor mod lovteksten og jeres egne procedurer.
Hvordan en kunde stiller krav til leverandørens rettetider i kontrakten, er et andet spørgsmål og hører til kundens kontrol af IT-leverandøren. Den almene metode for en audit står under den almene auditmetode.
Hvad det kræver, og hvad det koster at lade være
Det kræver et register, hvor hver sag får en vurdering og en beslutning, og en procedure, der siger, hvem der beslutter. Det kræver også, at fristerne er skrevet ned, så de kan holdes op mod sagerne.
Mangler registret, kan I ikke vise markedsovervågningsmyndigheden, at sårbarheder er håndteret straks. Efter artikel 13, stk. 22, har myndigheden ret til på begrundet anmodning at få al dokumentation for overensstemmelse med bilag I. Et svar uden spor er svært at forsvare.
Vil I have registret og fristerne efterprøvet af en uafhængig part før december 2027, er det den slags gennemgang, Nielco IT laver. Hvad der påvirker prisen, og hvordan I får et tilbud, står under pris og tilbud.
Det skal I lade være med
- At love kunderne en rettelse af alt · forordningen kræver vurdering og afhjælpning efter risiko.
- At skrive frister ind, I ikke følger · gennemgangen sammenligner dem med sagerne.
- At lukke en sag uden begrundelse · beslutningen er en del af beviset.
Det skal auditten kunne vise
- ☐ Dokumentation efter artikel 13, stk. 7, med vurdering og beslutning pr. sårbarhed.
- ☐ En skriftlig procedure for indkomne meldinger fra interne og eksterne kilder.
- ☐ Interne frister og stikprøver, der viser, om de blev holdt.
- ☐ Ajourført risikovurdering, hvor et fund ændrede billedet.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 7, 8 og 22, bilag I, del II, nr. 1-3, læst 13. november 2026.
- Europa-Kommissionen, FAQs on the Cyber Resilience Act, version 1.4, punkt 4.1.3, 4.3.1 og 6.10, læst 13. november 2026.
- Europa-Kommissionen, Cyber Resilience Act: Standardisation, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Træk fem lukkede sager fra jeres register og se, om hver har en vurdering, en beslutning og en dato.
Læs også: Sårbarheden kan ikke rettes · Politik for koordineret offentliggørelse
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
