Fabrikanten skal efter CRA afprøve og gennemgå produktets sikkerhed effektivt og regelmæssigt i hele supportperioden. Kommissionen læser “regelmæssig” som en tilbagevendende vurdering af, om nye trusler og sårbarheder kræver nye test, og det er den vurdering, programmet skal kunne dokumentere.
Bilag I, del II, nr. 3, i forordning (EU) 2024/2847 bærer kravet fra 11. december 2027, hvor fabrikanter skal “anvende effektive og regelmæssige afprøvninger og gennemgange af sikkerheden af produktet med digitale elementer”. Kommissionens udlægning står i vejledningen C(2026) 5252, punkt 238-240, som ikke er bindende.
Regelmæssig betyder ikke fast interval
Efter vejledningens punkt 238 kræver regelmæssighed ikke, at den samme kampagne køres igen og igen efter kalenderen. Det, der kræves, er en regelmæssig vurdering af, om nyt input, fx nye trusler eller nye sårbarheder, betyder, at testene skal opdateres, og at testene derefter udføres.
Punkt 239 siger, at hyppighed, dybde og indhold af gennemgangen står i forhold til produktets risikoprofil, dens udvikling og trusselsbilledet. Er der nyt relevant input, udvikles og udføres nye eller ændrede test. Det gælder også genkørsel af test, når produktet ændres.
Punkt 240 lukker cirklen. Findes der intet nyt input, skal der ikke udvikles nye test.
Konsekvensen er, at et program kan være regelmæssigt uden en fast kalender, og at en fast kalender ikke i sig selv gør et program regelmæssigt i forordningens forstand. Det er vores sammenfatning af de tre punkter.
Hvad programmet består af
Ingen regel beskriver, hvordan programmet dokumenteres. Det, der følger, er praksis bygget på punkt 238-240.
Indgangen. En fast måde at samle nyt input på: nye sårbarheder i produktet og dets komponenter, nye angrebsteknikker mod produkter af samme slags, ændringer i produktet og meldinger fra kunder og forskere.
Vurderingen. Med faste mellemrum, og når noget væsentligt sker, vurderer en ansvarlig, om inputtet kræver nye eller ændrede test. Vurderingen skrives ned, også når svaret er nej.
Testene. Når vurderingen siger ja, udvikles og udføres testene. Det kan være automatiske test i byggekæden, regressionstest efter ændringer, manuelle gennemgange af design eller kode eller penetrationstest. Forordningen nævner ingen bestemt testform.
Opfølgningen. Resultaterne føres tilbage til risikovurderingen. FAQ 4.1.8 siger, at vurderingen skal opdateres efter test og gennemgange, når der kommer relevante oplysninger frem.
Programmet er ikke selv en test
Det er let at forveksle programmet med de test, det udløser. En stak testrapporter viser, at der er testet. Den viser ikke, at nogen har spurgt, om der skulle testes noget nyt. Det er netop det spørgsmål, punkt 238 lægger vægt på.
Derfor er det vurderingen, der er det bærende bevis. En gennemgang af programmet kan se, om vurderingerne findes, om de er foretaget, når nyt input kom, og om de førte til test, når de burde.
Systemer, der bruges til test, er ikke fjerndatabehandling og dermed ikke en del af produktet (vejledningens punkt 182). Testmiljøet hører til fabrikantens egen drift. Hvordan sikkerhedstest og audit af organisationens egne systemer planlægges, er et andet emne.
Et tænkt program
Et softwarehus med en skrivebordsapp og en backend kunne have et program som dette:
- Indgang · (sårbarhedsovervågning af komponenter, meldinger via politikken for koordineret offentliggørelse, interne ændringsanmodninger)
- Vurderingsmøde · (hver måned og ved hver release med ny grænseflade)
- Faste test · (automatiske test i byggekæden ved hver release)
- Udløste test · (målrettet gennemgang, når en ny type angreb mod lignende apps bliver kendt)
- Spor · (referat af vurderingsmødet med beslutning og henvisning til testrapport)
Test ved ændringer
Punkt 239 nævner genkørsel af test, når produktet ændres. For software med hyppige releases kan automatiske regressionstest i byggekæden dække en stor del af det. De viser, at kendte fejl ikke vender tilbage, og at sikkerhedsfunktioner stadig virker efter en ændring.
Regressionstest siger derimod intet om trusler, som ingen har testet for endnu. Derfor udgør de én del af programmet. Vurderingen af nyt input er den anden, og det er den, der får programmet til at følge truslerne.
Hvad det kræver, og hvad det koster at lade være
Det kræver en ansvarlig, en indgang for nyt input og en skrevet vurdering, der kobler input til test. Meget af testarbejdet kan allerede findes. Det, der kan mangle, er det skrevne led imellem.
Uden vurderingen kan programmet ikke vise, at testene følger truslerne. Et softwarehus, der tester grundigt hvert år, men aldrig har spurgt, om et nyt angreb krævede nye test, kan have svært ved at vise, at kravet i bilag I, del II, nr. 3, er opfyldt.
Det skal I lade være med
- At gentage samme testkampagne og kalde det regelmæssigt · punkt 238 kræver en vurdering af nyt input.
- At springe vurderingen over, når der intet nyt er · et skrevet nej er også bevis.
- At lade testresultater blive i testafdelingen · de skal tilbage til risikovurderingen.
Det skal auditten kunne vise
- ☐ En beskrivelse af programmet med indgang, vurdering, test og opfølgning.
- ☐ Daterede vurderinger af nyt input med beslutningen om test.
- ☐ Testrapporter, der kan kobles til en vurdering.
- ☐ Spor fra testresultater til ændringer i risikovurderingen.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, bilag I, del II, nr. 3, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 182 og 238-240, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.1.8, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find den seneste nye angrebsteknik, der kunne ramme jeres produkt, og se, om nogen har vurderet, om den krævede nye test.
Læs også: Hvornår i udviklingsforløbet skal gennemgangen ligge? · CRA foreskriver ingen metode
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
