Et softwareprodukts risikovurdering er ikke færdig ved første frigivelse, for den skal følge produktet hele supportperioden igennem. Ajourføringen udløses af nye oplysninger, fx sårbarheder, meddelelser fra tredjeparter, testresultater og ændringer i trusselsbilledet, og versionshistorikken er det, der viser bagefter, at det er sket.
Pligten følger af artikel 13, stk. 3 og 7, i forordning (EU) 2024/2847, der på dette punkt anvendes fra 11. december 2027. Kommissionens tjenestegrenes FAQ 4.1.6 og 4.1.8 og Kommissionens vejledning C(2026) 5252 uddyber den. Ingen af de to er bindende.
To bestemmelser i artikel 13
Artikel 13, stk. 3, kræver, at vurderingen skrives ned og opdateres, i det omfang det er relevant, så længe supportperioden løber.
Artikel 13, stk. 7, er mere konkret. Fabrikanten skal systematisk og forholdsmæssigt dokumentere relevante cybersikkerhedsforhold, herunder sårbarheder, fabrikanten bliver bekendt med, og alle relevante oplysninger fra tredjeparter, og ajourføre risikovurderingen, når det er relevant.
Sammen betyder de, at vurderingen er et levende dokument. Indholdet er behandlet i artiklen om cybersikkerhedsrisikovurderingen for et softwareprodukt. Her handler det om vedligeholdelsen.
Anledningerne, kilderne nævner
Kilderne nævner en række anledninger. Listen her samler dem.
- Nye sårbarheder, fabrikanten bliver bekendt med · Artikel 13, stk. 7
- Relevante oplysninger fra tredjeparter · Artikel 13, stk. 7
- Resultater af regelmæssige test og gennemgange · FAQ 4.1.8
- Ændringer i trusselsbilledet over produktets levetid · FAQ 4.1.6
- Brugeroplysninger, som vurderingen bygger på, skal ændres tilsvarende · FAQ 4.1.6
- Ændringer hos en tredjepartsudbyder, produktet hviler på · Vejledningen, punkt 208
- En ny variant, der indfører nye risici · Vejledningen, punkt 177
- Begrænsninger, der skal genvurderes periodisk · Vejledningen, punkt 32
- Softwareopdateringer, også når de ikke er væsentlige ændringer · Vejledningen, punkt 113
Det sidste punkt fortjener opmærksomhed. Vejledningen siger, at risikovurdering og teknisk dokumentation skal holdes ajour, uanset om en opdatering er en væsentlig ændring. En release, der ikke udløser ny overensstemmelsesvurdering, kan altså stadig kræve en opdateret vurdering.
Forholdsmæssigt og relevant
Ordene “i relevant omfang” og “forholdsmæssigt” betyder, at ikke hver ny oplysning kræver en ny version af vurderingen. En sårbarhed, der er vurderet og ikke gælder produktet, kan registreres uden at ændre vurderingen. En ny type angreb mod produktets slags software kan derimod kræve, at en risiko vurderes på ny.
Det er en skønssag, og det er praksis at skrive skønnet ned. En kort note om, at en oplysning er set og ikke giver anledning til ændring, viser, at vurderingen er holdt ajour, også når den ikke er ændret.
Versionshistorikken som bevis
Ingen regel siger, hvordan ajourføringen skal dokumenteres. Versionshistorik er praksis, men den passer til kravene. FAQ 4.1.8 gengiver Kommissionens Blue Guide, der siger, at dokumentationen ved redesign skal afspejle alle versioner. Den tekniske dokumentation, herunder risikovurderingen, har en opbevaringstid på ti år efter omsætning som minimum, og tiden forlænges, når supportperioden varer længere (artikel 13, stk. 13).
En brugbar historik har for hver ændring:
- dato og versionsnummer,
- anledningen, med henvisning til sagen, testen eller meddelelsen,
- hvad der er ændret i vurderingen,
- om brugeroplysninger eller teknisk dokumentation også er ændret,
- hvem der har godkendt ændringen.
Markedsovervågningsmyndigheden kan efter artikel 53 på begrundet anmodning få adgang til intern dokumentation (FAQ 4.1.8). Historikken er det, der viser, at vurderingen har fulgt produktet.
Kobling til sårbarhedsregistret
Artikel 13, stk. 7, nævner både sårbarheder og risikovurderingen i samme sætning. Det er derfor nyttigt, at sårbarhedsregistret har et felt, der siger, om sagen har ført til en ændring i vurderingen. Så kan en gennemgang følge sporet begge veje. Det er praksis.
Et tænkt eksempel
Et softwarehus har vurderet sit program til brug på interne kontornet. En større kunde fortæller, at programmet nu også bruges af medarbejdere hjemmefra over en almindelig internetforbindelse. Det er en oplysning fra en tredjepart efter artikel 13, stk. 7.
Ejeren af vurderingen tager stilling. Er brugen forudsigelig, skal den med i vurderingen som forudsigelig anvendelse, og brugeroplysningerne skal måske ændres. Er den i strid med formålet, kan den være forudsigelig fejlanvendelse, som skal nævnes efter bilag II, nr. 5. I begge tilfælde ender oplysningen som en dateret ændring i versionshistorikken, og sporet kan følges fra kundens melding til den nye version af vurderingen.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at nogen ejer vurderingen i hele supportperioden, og at de anledninger, kilderne nævner, sendes til ejeren. For de fleste softwarehuse betyder det en kobling fra sårbarhedshåndtering, test og release til den, der vedligeholder vurderingen.
En vurdering, der er skrevet ved første frigivelse og aldrig rørt siden, viser ikke, at fabrikanten har fulgt med. Efter nogle års support kan den beskrive et produkt, der ikke længere findes.
Det skal I lade være med
- At lade vurderingen ligge urørt efter første frigivelse · stk. 3 kræver ajourføring i supportperioden.
- At springe ajourføring over, fordi en release ikke er en væsentlig ændring · vejledningen forventer den alligevel (punkt 113).
- At ændre vurderingen uden at gemme den gamle · historikken er beviset.
Det skal auditten kunne vise
- ☐ En navngiven ejer af risikovurderingen for hvert produkt i support.
- ☐ Versionshistorik med dato, anledning og godkendelse for hver ændring.
- ☐ Spor fra sårbarhedssager og testresultater til vurderingen.
- ☐ Noter om oplysninger, der er set uden at give anledning til ændring.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 3, 7 og 13, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.1.6 og 4.1.8, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 32, 113, 177 og 208, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Åbn versionshistorikken for jeres risikovurdering, og tæl, hvor mange ændringer der er sket siden første frigivelse.
Læs også: Væsentlig ændring · Supportperioden
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
