Politik for koordineret offentliggørelse og det centrale kontaktpunkt: gennemgang af praksis

En politik for koordineret offentliggørelse af sårbarheder er et krav i Cyber Resilience Act, og forordningen bruger ordene “indføre og håndhæve”. Det afgørende i en gennemgang er derfor, om meldinger faktisk bliver modtaget, besvaret og lukket, som jeres politik (også kaldet CVD-politik) beskriver.

Kravene gælder fra 11. december 2027. Hos mange softwarehuse findes der allerede en side med en sikkerhedsadresse. Spørgsmålet er, om den bærer et eftersyn.

De tre steder, kravet står

Bilag I, del II, nr. 5, kræver, at fabrikanten indfører og håndhæver en politik for koordineret offentliggørelse af sårbarheder. Nr. 6 handler om at gøre det let at udveksle oplysninger om mulige sårbarheder, både i jeres egen kode og i komponenter fra andre, blandt andet ved at oplyse en kontaktadresse til indberetning.

Artikel 13, stk. 8, sidste afsnit, gentager, at fabrikanten skal have passende politikker og procedurer, herunder politikken for koordineret offentliggørelse. Efter bilag VII, nr. 2, litra b, hører en beskrivelse af politikken til den tekniske dokumentation, sammen med dokumentation for kontaktadressen.

Dertil kommer brugersiden. Bilag II, nr. 2, kræver, at oplysningerne til brugeren angiver det centrale kontaktpunkt, hvor sårbarheder kan indberettes og oplysninger modtages, og hvor politikken kan findes.

Det centrale kontaktpunkt

Artikel 13, stk. 17, kræver, at fabrikanten udpeger et centralt kontaktpunkt, så brugerne kan kommunikere direkte og hurtigt med fabrikanten, også når de vil indberette en sårbarhed. Kontaktpunktet skal være let at finde. Brugeren skal kunne vælge sit foretrukne kommunikationsmiddel, og fabrikanten må ikke nøjes med automatiserede værktøjer som eneste kommunikationsmiddel.

En chatbot eller en formular, der kun sender et automatisk svar, opfylder derfor næppe kravet alene. Det er vores læsning af stykket. Der skal være en vej, hvor et menneske kan tage imod.

Hvad lovteksten ikke siger

Forordningen fastsætter ingen svartid, ingen frist for at lukke en sag og ingen bestemt form for politikken. Den nævner heller ikke filen security.txt. Den tyske retningslinje TR-03183-2 nævner kun en henvisning til komponentopretterens security.txt som et valgfrit felt i komponentlisten. En security.txt er en udbredt teknisk løsning. Forordningen kræver den ikke.

Svartider og lukning er derfor det, jeres egen politik lover. En gennemgang holder praksis op mod de løfter. Lover politikken svar inden for et bestemt antal arbejdsdage, er det løftet, der måles på.

Kommissionens vejledning (punkt 131) tilføjer, at pligterne om politik og informationsdeling fortsat gælder for alle efterfølgende væsentligt ændrede versioner. Det gælder også, når afhjælpning kun sker i den seneste version. Vejledningen er ikke bindende.

Sådan efterprøves praksis

Gennemgangen af praksis følger ofte fire trin. Ingen af dem er foreskrevet i forordningen.

Find kontaktpunktet som en bruger. Kan det findes fra produktet, fra brugeroplysningerne og fra hjemmesiden uden at kende det i forvejen?
Læs politikken mod dokumentationen. Står den samme politik i den tekniske dokumentation efter bilag VII, og passer den til det, brugerne ser?
Følg indkomne meldinger. Et udvalg af meldinger fra den seneste periode følges fra modtagelse til svar og lukning. Fik melderen kvittering? Blev sagen ført ind i sårbarhedsregistret? Blev løftet om svartid holdt?
Prøv kanalerne. Er der mindst én vej, der ikke er et automatisk værktøj, og fungerer den?

Hvis der aldrig er kommet en melding, er det i sig selv en oplysning. Det kan betyde, at kontaktpunktet er svært at finde.

Politik og register hører sammen

Politikken og sårbarhedsregistret efter artikel 13, stk. 7, er to sider af samme sag. Når en melding kommer ind gennem kontaktpunktet, er det naturligt, at den får et id i registret samme dag, så forløbet kan følges derfra. En politik kan også beskrive, hvordan melderen holdes orienteret, og hvornår fundet bliver offentliggjort. De løfter kan holdes op mod pligten i bilag I, del II, nr. 4, til at offentliggøre oplysninger om afhjulpne sårbarheder, når rettelsen er ude.

Et tænkt eksempel på en politik, der ikke holder

Et tænkt softwarehus har en side med en sikkerhedsadresse og et løfte om svar inden for fem arbejdsdage. Adressen videresendes til en fælles supportkø, hvor sikkerhedsmeldinger blandes med spørgsmål om licenser. Ingen af de tre seneste meldinger blev registreret som sårbarheder. Politikken findes. Den håndhæves ikke, og det er netop det ord, bilag I, del II, nr. 5, bruger.

Hvad det kræver, og hvad det koster at lade være

Det kræver en politik, som nogen ejer, en kanal, der når frem til de rigtige personer, og en vane med at føre hver melding ind i registret. Arbejdet ligger mest i at forbinde kontaktpunktet med den interne sagsgang.

Uden den forbindelse kan meldinger gå tabt, og en forsker, der ikke får svar, kan vælge at offentliggøre på egen hånd. Over for myndigheden står I med en politik på papir og ingen spor af, at den blev fulgt.

Det skal I lade være med

At lade sikkerhedsmeldinger lande i den almindelige supportkø · de forsvinder mellem licenssager.
At gøre en chatbot til eneste indgang · artikel 13, stk. 17, udelukker det.
At skrive svartider i politikken, I ikke kan holde · det er dem, der måles på.

Det skal auditten kunne vise

☐ Politikken beskrevet i den tekniske dokumentation efter bilag VII, nr. 2, litra b.
☐ Kontaktpunktet angivet i brugeroplysningerne efter bilag II, nr. 2.
☐ Mindst én kanal, der ikke er et automatiseret værktøj.
☐ Meldinger fulgt fra modtagelse til lukning og ført ind i registret.

Kilder

Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 8 og 17, bilag I, del II, nr. 5-6, bilag II, nr. 2, og bilag VII, nr. 2, litra b, læst 13. november 2026.
Europa-Kommissionen, vejledning C(2026) 5252, punkt 131, læst 13. november 2026.
BSI, TR-03183-2, version 2.1.0, afsnit 5.2.5, læst 13. november 2026.

Senest gennemgået: november 2026.

Næste skridt

Find jeres eget kontaktpunkt fra produktet, som en ny bruger ville gøre, og send en prøvemelding gennem den kanal, der ikke er automatisk.

Læs også: Når rettelsen er ude · Sårbarhed i en andens komponent

→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

Skal jeres software gennemgås?

Skriv kort, hvilket produkt det drejer sig om, og hvad der sætter det i gang. Så vender jeg tilbage. Gennemgangen er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.