Udkommer softwaren hver uge, skal den tekniske dokumentation kunne følge med uden at miste sporet af de versioner, der allerede er ude. Forordning (EU) 2024/2847 kræver, at dokumentationen ajourføres og opbevares i mindst ti år, og Kommissionens FAQ beskriver, hvordan versioner og ændringer skal fremgå.
Kravene gælder fra 11. december 2027. For et softwarehus med hyppige udgivelser er udfordringen sjældent at skrive dokumentationen første gang. Det svære er at holde den sammen med koden, release efter release, og kunne finde den udgave, der gjaldt en bestemt version for flere år siden.
Tre bestemmelser om tid
Opbevaring. Artikel 13, stk. 13, kræver, at dokumentationen og EU-overensstemmelseserklæringen kan stilles til rådighed for myndighederne i ti år fra omsætningen som minimum, eller supportperioden igennem, hvis den rækker længere.
Ajourføring. Artikel 31, stk. 2, kræver løbende opdatering, hvor det er relevant, og som minimum gennem hele supportperioden. Artikel 13, stk. 7, kræver, at relevante cybersikkerhedsaspekter dokumenteres systematisk, og at risikovurderingen ajourføres.
Versionsangivelse. Bilag VII, punkt 1, litra b, beder den generelle beskrivelse nævne de versioner af softwaren, som har indflydelse på opfyldelsen af de væsentlige krav.
Sat sammen betyder det, at dokumentationen både skal være aktuel og bevare historikken. En version, der blev solgt for tre år siden, skal stadig kunne forklares.
Hvad FAQ’en siger om versioner
Kommissionens FAQ citerer i afsnit 4.1.8 Blue Guide, afsnit 4.3. Citatet handler om et produkt, der er designet om og vurderet på ny, og siger frit oversat, at dokumentationen må dække samtlige versioner, redegøre for ændringerne, forklare, hvordan versionerne kendes fra hinanden, og oplyse om de vurderinger, der er foretaget af dem.
Det er altså et citat fra Blue Guide, som FAQ’en bruger. Blue Guide er ikke læst selvstændigt til denne artikel. Citatet er skrevet til produkter, der vurderes på ny, og at det også bør styre den daglige versionering af software, er vores tolkning.
Ikke hver release er en ny vurdering
Kommissionens vejledning fra juli 2026 skelner mellem almindelige opdateringer og væsentlige ændringer. Efter vejledningens punkt 123 må dokumentation og test fra uberørte dele bruges igen ved en væsentlig ændring, og vurderingen bør samle sig om det, der er ændret.
Vejledningen siger også, at hver væsentligt ændret version skal have en erklæret supportperiode efter artikel 13, stk. 8. For et softwarehus, der udgiver ofte, betyder det, at den løbende versionsstrøm skal sorteres. Sikkerhedsopdateringer er efter vejledningen som udgangspunkt ikke væsentlige ændringer, mens nye funktioner kan være det og så udløse ny vurdering, ny supportperiode og ny erklæring. Hvordan den sortering foregår, er beskrevet i væsentlig ændring.
Dokumentationen ved siden af koden
Hvordan dokumentationen versionsstyres, er ikke reguleret. Mange softwarehuse vælger at holde den i samme system som koden, så hver release har en tilhørende udgave af dokumentationen. Andre bruger et separat dokumentstyringssystem med henvisning til versionsnumre. Begge dele kan efter vores vurdering fungere, så længe sammenhængen kan vises.
En gennemgang ser typisk efter fire ting:
- Kan dokumentationens udgave for en bestemt softwareversion findes frem?
- Er det registreret, hvilke releases der er vurderet som væsentlige ændringer, og hvorfor?
- Er ændringerne beskrevet, eller er der kun en liste over versionsnumre?
- Vil dokumentationen stadig kunne læses om ti år, uanset om værktøjet er skiftet ud?
Det sidste punkt overses let. Ti år er lang tid i et softwarehus. Kodelageret flyttes, wiki-værktøjet skiftes, og den medarbejder, der skrev dokumentationen, er måske rejst. Dokumentation, der kun kan læses i et bestemt værktøj, er sårbar over for den slags.
Et tænkt eksempel
Et softwarehus udgiver en ny version hver tirsdag. Dokumentationen ligger i kodelageret som tekstfiler, og hver release får et mærke, der også mærker dokumentationen. Fire gange om året vurderes en release som væsentlig ændring. Ved de fire lejligheder opdateres risikovurderingen, supportperioden erklæres på ny, og en ny erklæring underskrives. En gang om året eksporteres hele dokumentationen til et format, der kan læses uden særlige værktøjer, og gemmes i et arkiv med adgangskontrol.
Eksemplet viser én måde at gøre det på. Forordningen foreskriver ikke en bestemt.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at dokumentationen indgår i frigivelsesprocessen og opdateres sammen med koden. Det kræver også en beslutning om opbevaring, der holder i mindst ti år og ud over supportperiodens slutning.
Kan dokumentationen for en ældre version ikke findes, når myndigheden spørger, er den ufuldstændig. Artikel 58, stk. 1, litra f, behandler det som formel manglende overholdelse, også selv om selve softwaren er i orden.
Det skal I lade være med
- At overskrive dokumentationen ved hver release · historikken skal bevares i ti år.
- At behandle alle releases ens · nogle er væsentlige ændringer og kræver mere.
- At gemme dokumentationen i et format, kun ét værktøj kan læse · ti år er længere end de fleste værktøjers levetid.
Det skal auditten kunne vise
- ☐ En udgave af dokumentationen for hver understøttet softwareversion.
- ☐ En liste over releases vurderet som væsentlige ændringer med begrundelse.
- ☐ Beskrivelse af ændringer mellem versioner.
- ☐ En opbevaringsplan, der dækker ti år eller supportperioden.
- ☐ Et format, der kan læses uden det værktøj, dokumentationen blev skrevet i.
Kilder
- Forordning (EU) 2024/2847 om cyberrobusthed, artikel 13, stk. 7, 8 og 13, artikel 31, stk. 2, artikel 58 og bilag VII, læst 13. november 2026 i Publikationskontorets udgave af EUT-teksten.
- Europa-Kommissionen, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.1.8, læst 13. november 2026.
- Europa-Kommissionen, Commission guidance on the application of Regulation (EU) 2024/2847, C(2026) 5252, afsnit 4.4.2 og 5, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Prøv at finde dokumentationen for den version, I udgav for et år siden. Tager det lang tid, er det et tegn på, at sporet er svagt.
Læs også: En komponentliste for hver version · Den tekniske dokumentation efter bilag VII
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
