Ingen regel i CRA siger, hvornår et softwareprodukt skal have en uvildig gennemgang, og ingen gennemgang er lovpligtig. Tidspunktet er et valg, og tre steder i udviklingsforløbet giver mening: ved arkitekturvalget, før første frigivelse og ved væsentlige ændringer.
Hele artiklen er praksis. Den bygger på de regler i forordning (EU) 2024/2847, der binder fabrikantens egne aktiviteter til bestemte tidspunkter, og som derfor gør nogle tidspunkter mere nyttige end andre. Reglerne gælder fra 11. december 2027.
De regler, der giver tidspunkterne
Forordningen nævner ikke uvildige gennemgange. Den har til gengæld regler om, hvornår fabrikanten selv skal have noget på plads:
- Risikovurderingen skal bruges i alle faser fra planlægning og design til levering og vedligeholdelse (artikel 13, stk. 2).
- Teknisk dokumentation og overensstemmelsesvurdering skal være klar, før produktet bringes i omsætning (artikel 13, stk. 12).
- En væsentlig ændring kan kræve en ny overensstemmelsesvurdering (artikel 3, nr. 30, og betragtning 41).
- Ændringer i udviklingsprocessen, designet og de anvendte standarder skal tages i betragtning (artikel 13, stk. 14).
- Sikkerheden skal afprøves og gennemgås effektivt og regelmæssigt i supportperioden (bilag I, del II, nr. 3).
En gennemgang er nyttig, hvor den kan påvirke en af disse aktiviteter, mens fundene stadig kan nå at blive rettet.
Ved arkitekturvalget
Det tidligste tidspunkt er, når produktets opbygning lægges fast. Her kan en gennemgang se på, om risikovurderingen findes og faktisk styrer designet, om formålet er beskrevet, så det passer med det, salget vil sige, og om grænsen for produktet er trukket rigtigt, så backend-tjenester, der hører med, er med.
Fordelen er, at fund er lette at rette. En grænseflade, der ikke er bygget, er let at fjerne. Ulempen er, at der ikke er meget at prøve i praksis, så gennemgangen bliver mest en læsning af dokumenter og tegninger.
Før første frigivelse
Det mest oplagte tidspunkt er, før en ny version bringes i omsætning første gang. Her findes produktet, og dokumentationen skal være færdig. En gennemgang kan prøve en installeret kopi mod kravene i bilag I, del I, læse den tekniske dokumentation mod bilag VII og se, om sårbarhedshåndteringen i del II faktisk er i drift.
Fund her kan stadig rettes, før produktet er ude. Men tidsplanen er ofte presset, og store fund kan flytte en frigivelsesdato. Det taler for, at gennemgangen planlægges god tid før datoen.
Ved væsentlige ændringer
Den tredje anledning er en release, der kan være en væsentlig ændring. Her er spørgsmålet, om fabrikantens egen vurdering af ændringen holder, og om risikovurdering og dokumentation er opdateret for de dele, der er ændret. Betragtning 41 siger, at hvis et bemyndiget organ har vurderet produktet, bør det have besked om ændringer, der kunne føre til en væsentlig ændring.
En gennemgang ved hver release er sjældent nødvendig. Det giver mere mening at lægge den ved de releases, hvor fabrikantens egen vurdering har været i tvivl.
Samme logik i supportperioden
I supportperioden kræver bilag I, del II, nr. 3, regelmæssige afprøvninger og gennemgange. Kommissionen forstår i sin vejledning (punkt 238) “regelmæssig” som en løbende vurdering af, om nye trusler kræver nye test. En uvildig gennemgang kan være en del af det program, men den kan også stå uden for det. Hvordan og hvornår en audit af hele organisationen placeres i årshjulet, er et andet spørgsmål med andre tidspunkter.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at gennemgangen planlægges som en del af selve udviklingsforløbet. Når gennemgangen ligger fast i planen for en ny version, kan resultatet bruges, mens der stadig er tid til at handle.
Lægges gennemgangen efter frigivelsen, finder den fejl, der allerede er hos kunderne. Så bliver fundene en sag for sårbarhedshåndteringen i stedet for en rettelse før release. Ønsker I en uvildig gennemgang af produkt og udviklingsproces fra Nielco IT, kan den lægges ved et af de tre tidspunkter. 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 kalde en gennemgang lovpligtig · forordningen kræver ingen uvildig gennemgang.
- At lægge gennemgangen dagen før frigivelse · der skal være tid til at rette fund.
- At gennemgå hver release · indsatsen hører hjemme ved de releases, der kan være væsentlige ændringer.
Det skal auditten kunne vise
- ☐ En plan, der viser, hvor i udviklingsforløbet gennemgange er placeret.
- ☐ En risikovurdering, der er dateret før designet blev lagt fast.
- ☐ Teknisk dokumentation og overensstemmelsesvurdering færdige før første frigivelse.
- ☐ Vurderinger af væsentlig ændring for de releases, hvor spørgsmålet har været rejst.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 3, nr. 30, artikel 13, stk. 2, 12 og 14, bilag I, del II, nr. 3, og betragtning 41, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 238, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Tag planen for jeres næste større version, og sæt de tre tidspunkter ind i den.
Læs også: Væsentlig ændring · Regelmæssige afprøvninger og gennemgange i supportperioden
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
