Den tidlige varsling på ENISA’s platform spørger blandt andet efter produktversioner, medlemsstater og tidspunktet for kendskab. Ingen af de svar kan findes på 24 timer, hvis de ikke allerede ligger i et register, og derfor handler forberedelsen mest om jeres egne lister.
Gennemgangen her bygger på ENISA’s glossar til platformen, version 1.6 af 21. oktober 2026. Platformen blev opgraderet den 4. november 2026, og ENISA oplyser, at dokumentationen opdateres. Kontrollér derfor glossaret, før I bruger listen.
Hvad forordningen kræver, og hvad platformen spørger om
Forordningen fastlægger indholdet i artikel 14, stk. 2 og 4. For en aktivt udnyttet sårbarhed skal den tidlige varsling i givet fald nævne de medlemsstater, hvor produktet er gjort tilgængeligt. Meddelelsen efter 72 timer skal have generelle oplysninger om produktet, udnyttelsen og sårbarheden og om foranstaltninger. Den endelige rapport skal beskrive alvor og indvirkning, ondsindede aktører, hvis oplysningerne foreligger, og sikkerhedsopdateringen.
ENISA’s glossar omsætter det til felter og angiver for hvert felt, om det er krævet, valgfrit eller ikke relevant i de tre trin. Felterne er ENISA’s udfyldningsform. Lovkravet er artikel 14.
Krævet i den tidlige varsling
Ifølge glossaret er blandt andet disse felter krævet ved den tidlige varsling:
- Type · (sårbarhed eller hændelse)
- Titel og resumé · (kort, saglig beskrivelse uden tekniske detaljer, der hjælper en angriber)
- Medlemsstater · (de lande, hvor produktet er gjort tilgængeligt)
- Produktnavn · (navnet, som det står i jeres dokumentation)
- Produktversion(er) · (nøjagtige versioner eller et interval)
- Tidspunkt for kendskab · (dato og klokkeslæt, eventuelt markeret som skøn)
- Mistanke om ulovlige eller ondsindede handlinger · (kun ved hændelse)
Tre af felterne er de svære. Hvilke lande er produktet gjort tilgængeligt i? Hvilke versioner er berørt? Og hvornår fik I kendskab? Det sidste er beskrevet i hvornår I har fået kendskab.
Krævet efter 72 timer og i den endelige rapport
Efter 72 timer kræver glossaret ved en sårbarhed generel information om sårbarheden og ved en hændelse generel information om hændelsens art og en indledende vurdering.
I den endelige rapport er blandt andet disse felter krævet: trufne foranstaltninger, foranstaltninger brugerne kan træffe, en beskrivelse af alvor og indvirkning og oplysninger om ondsindede aktører, hvis de er tilgængelige. Ved en sårbarhed kommer datoen, hvor rettelsen blev tilgængelig, og detaljer om opdateringen. Ved en hændelse kommer trusselstype eller grundlæggende årsag og de anvendte foranstaltninger.
Valgfrie felter
Glossaret har også valgfrie felter. Blandt dem er produkttype (standard, vigtig eller kritisk), klasse og kategori, om supportperioden er udløbet, navnet på en berørt komponent, om en afbødende foranstaltning ventes snart, CVE-id og EUVD-id, hvis de er tildelt, og jeres vurdering af oplysningernes følsomhed.
Valgfrit betyder, at I ikke skal udfylde dem. Kan I gøre det, giver det modtageren et bedre billede. Feltet om følsomhed er beskrevet nærmere i kan indberetningen holdes tilbage.
Registrene bag felterne
Forordningen kræver ikke bestemte registre for indberetningen. At have dem er praksis. Men for at kunne udfylde felterne inden for fristerne skal I kunne svare på fire spørgsmål hurtigt.
Hvilke versioner er i omløb? Et register over udgivne versioner med datoer og status for support. Det er det samme register, der bærer overgangsreglen og supportperioden, og det er beskrevet i hvornår softwaren er bragt i omsætning.
Hvilke lande sælges der til? En oversigt over, hvor produktet er gjort tilgængeligt. For en app i en butik med salg i hele EU er svaret enkelt. For et system solgt via forhandlere kan det kræve, at nogen spørger salgsafdelingen.
Hvem er kunderne? En kundeliste pr. produkt og version, som også skal bruges, når brugerne efter artikel 14, stk. 8, skal underrettes.
Hvilke komponenter indgår? Komponentlisten pr. version. Glossaret har et valgfrit felt til komponentnavnet, og I skal kunne afgøre, om en sårbar komponent findes i de versioner, kunderne kører.
En prøve, en gennemgang kan lave
Den mest direkte prøve er at vælge et produkt og bede om svarene på de fire spørgsmål inden for en time. En tænkt situation er, at en sårbarhed i en bestemt komponent er udnyttet, og at I skal finde berørte versioner, lande og kunder. Kan svarene findes uden at hive udviklere ud af andre opgaver, er registrene i orden. Prøven er praksis og ikke et krav.
Når svaret ikke er klar i tide
Kan et krævet felt ikke udfyldes præcist ved den tidlige varsling, er det bedre at sende det, I ved, end at lade fristen løbe ud. For tidspunktet for kendskab siger glossaret selv, at et bedste skøn kan angives og markeres som skøn. Forordningen er bygget op i trin, så 72-timers meddelelsen og den endelige rapport kan rumme det, varslingen manglede, og oplysninger, der allerede er givet, skal ikke gentages.
Viser en oplysning sig at være forkert, skal indberetningen opdateres. Punkt 4.1.8 i ENISA’s vilkår kræver en straks-opdatering, hvis der dukker ny relevant viden op, eller hvis noget allerede indsendt var forkert eller manglede. Hvordan det foregår på platformen, står i ret og opdatér en indgivet indberetning.
Hvad det kræver, og hvad det koster at lade være
Det kræver et versionsregister, en oversigt over markeder, kundelister pr. produkt og en komponentliste pr. version, holdt ajour, så de kan bruges med det samme.
Uden registrene bliver felterne i den tidlige varsling gætværk, og den endelige rapport kan ikke sige, hvem der er berørt. Et forkert versionsinterval skal rettes bagefter, og hver rettelse sendes videre til ENISA og de berørte CSIRT’er.
Det skal I lade være med
- At skrive tekniske detaljer i resuméet · feltet læses af flere modtagere, før en rettelse findes.
- At gætte versionsintervallet uden at markere det · en uklar angivelse skal rettes senere.
- At bruge en generel fortrolighedserklæring i følsomhedsfeltet · ENISA beder om en konkret vurdering.
Det skal auditten kunne vise
- ☐ Et versionsregister med udgivelsesdatoer og supportstatus.
- ☐ En oversigt over medlemsstater, hvor hvert produkt er gjort tilgængeligt.
- ☐ Kundelister pr. produkt, der kan bruges til underretning.
- ☐ Komponentlister pr. version, der kan søges i.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 14, stk. 2, 4 og 8, læst 13. november 2026.
- ENISA, CRA SRP Glossary, version 1.6 af 21. oktober 2026, felterne 1-41, læst 13. november 2026.
- ENISA, Single Reporting Platform, note om version 1.3, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Vælg ét produkt og find berørte versioner, lande og kunder for en tænkt sårbarhed, med uret i gang.
Læs også: En komponentliste for hver version · Den fælles indberetningsplatform
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
