24 timer til ENISA: hvem i softwarehuset gør hvad?

Siden 11. september 2026 skal en fabrikant efter Cyber Resilience Act give tidlig varsling inden for 24 timer efter at have fået kendskab til en aktivt udnyttet sårbarhed eller en alvorlig hændelse, der påvirker produktets sikkerhed. Pligten gælder også en lørdag i et team på fem. Det afgørende er derfor, at det er besluttet på forhånd, hvem der opdager, hvem der vurderer, og hvem der har adgang til platformen. Først skal I vide, om produktet overhovedet er omfattet. Artiklen er en praktisk vejledning og ingen juridisk rådgivning.

Fristerne

• Tidlig varsling: inden for 24 timer efter kendskab.
• Underretning: inden for 72 timer efter kendskab.
• Slutrapport for en sårbarhed: senest 14 dage efter, at en rettelse eller afhjælpning er klar.
• Slutrapport for en hændelse: inden for en måned efter 72-timers-underretningen.

Indberetningen går via ENISA’s Single Reporting Platform til CSIRT i landet med jeres hovedvirksomhed. ENISA er EU’s agentur for cybersikkerhed, og CSIRT er den enhed, der tager imod sikkerhedsmeldinger.

Pligten omfatter også produkter, som kom på markedet før hovedkravene. Der er ingen tilbagevirkning. Sårbarheder, hvis aktive udnyttelse I kendte før 11. september 2026, skal ikke indberettes. Bliver udnyttelsen først kendt efter datoen, skal den.

Mikro- og små virksomheder kan ikke pålægges administrative bøder for at overskride 24-timers-fristerne. De har stadig pligten.

Hvad tæller?

Pligten handler om aktivt udnyttede sårbarheder og alvorlige hændelser. En sårbarhed, I selv finder, og som ingen har udnyttet, skal håndteres og rettes, men den udløser ikke 24-timers-fristen.

Tredjepartskomponenter kræver en vurdering. Bliver fejlen i en komponent aktivt udnyttet i jeres produkt, er indberetningen jeres. Kan den ikke udnyttes hos jer, eller er det ikke sket, har I ingen pligt til at indberette. En frivillig melding er mulig, og komponentens vedligeholder skal orienteres. Se tredjepartsbiblioteker, SBOM og byggepipeline.

Fire roller, som også et lille team kan dække

Rollerne kan godt samles på få personer, men de skal have navne. Hver rolle skal have en stedfortræder.

1. Modtageren. En fast adresse til meldinger og en, der læser den hver dag. Meldinger kommer også fra overvågning, support og kunder, og alle i kundevendte roller skal vide, hvor de sender dem hen.
2. Vurderingspersonen. Oftest lead developeren eller CTO’en. Afgør, om der er tale om en aktiv udnyttelse, og om klokken er begyndt at gå.
3. Indberetteren. Har adgang til platformen og sender. Den person retter sjældent også fejlen.
4. Beslutningstageren. Direktøren eller en stedfortræder, der kan træffe beslutninger om kommunikation til kunder og om at lukke en funktion.

Tænk over, hvornår klokken starter. Reglerne taler om kendskab. Beslut, hvem der vurderer det, og skriv tidspunktet ned, så I bagefter kan vise, hvordan I handlede. Er I i tvivl om en konkret sag, så tal med en advokat.

Weekenden

Et team på fem har ingen sikkerhedsvagt døgnet rundt. To enkle løsninger dækker det meste:

• En aftalt vagtplan, hvor én person holder telefonen tændt, og hvor der er en liste over, hvad vedkommende skal gøre. Den kan gå på omgang med den tekniske vagt, der er beskrevet i overvågning, vagt og driftshændelser.
• En kort stigevej. Svarer den første ikke inden for en aftalt tid, ringer systemet til den næste.

Adgang til platformen skal være på plads, før I får brug for den, og den må ikke hænge på én persons konto eller telefon. Læs platformens egen vejledning om adgange og oprettelse, og afprøv login med to personer. Det gælder også, når CTO’en holder ferie eller stopper.

En skabelon til det interne notat

Platformen bestemmer, hvilke felter der skal udfyldes. Det her er vores forslag til et internt notat, så I har svarene, når I logger ind:

• Hvornår fik vi kendskab, og hvordan?
• Hvilket produkt og hvilke versioner er ramt?
• Hvad ved vi om udnyttelsen?
• Hvad har vi gjort for at begrænse den?
• Findes der en rettelse eller afhjælpning?
• Hvem har vi orienteret, og hvem mangler?
• Hvad ved vi endnu ikke, og hvornår ved vi mere?

Den sidste linje er vigtig. Den tidlige varsling skal gå af sted, selv om I ikke kender det hele. Brug samme notat, når I skriver til kunderne, se besked til kunderne under nedbrud, og tag samtidig stilling til, om andre regler kræver meddelelser. NIS2-underretning har sit eget forløb, som hvem beslutter NIS2-underretningen beskriver.

Øv det to gange om året

Sæt en halv time af. Tag et tænkt eksempel: En kunde skriver fredag aften, at et kendt bibliotek i jeres app bliver angrebet. Stil så spørgsmålene:

• Hvem får beskeden, og hvor hurtigt?
• Hvilke versioner har vi komponenten i?
• Hvem kan logge ind på platformen lige nu?
• Hvad skriver vi til kunderne?
• Hvad skete der med klokken?

Skriv det ned, der ikke virkede, og ret det. Øvelsen viser hurtigt, om jeres komponentliste pr. version rent faktisk findes.

Vil I have rollerne, øvelsen og koblingen til køreplanen sat op af en erfaren person, kan en fractional CTO-opgave hos Nielco IT dække ledelsen af det, mens rettelserne ligger hos jeres udviklere.

Det skal I lade være med

• At vente med at varsle, til alt er klarlagt · den første besked må gerne være foreløbig.
• At lade adgangen ligge på én persons konto · så er pligten låst til vedkommendes ferie.
• At blande varsling og pressemeddelelse sammen · de har forskellige modtagere.

Det skal I kræve af den eksterne

• ☐ Fire navngivne roller med stedfortrædere.
• ☐ En prøvet adgang til platformen.
• ☐ En stigevej, der også virker i weekender.
• ☐ Et internt notat, der kan udfyldes på få minutter.
• ☐ En øvelse med referat.

Kilder

• Kommissionen: CRA-indberetning: frister og platform.
• Kommissionen: nyhed af 11. september 2026: start af pligten.
• Kommissionens vejledning C(2026) 5252: ikke bindende, nr. 217 og 218.
• Kommissionens FAQ: afsnit 1.4, 5.3 og 5.4.
• Høringsportalen: udkast til dansk lov: gengiver art. 64, stk. 10.

Senest gennemgået: november 2026.

Næste skridt

• Sikkerhed i produktet og i udviklingsprocessen
• Cyber Resilience Act: hvad betyder den for jeres produkt?

Læs også: Sikker softwareudvikling i et lille team · Regler for softwarevirksomheder

→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT