Den tekniske dokumentation er fabrikantens samlede bevis for, at et softwareprodukt og processerne bag det lever op til bilag I i forordning (EU) 2024/2847. Bilag VII opregner otte punkter, og fra 11. december 2027 skal dokumentationen foreligge, før produktet bringes i omsætning.
Søger man efter teknisk dokumentation til CRA for software, finder man mest skabeloner. Denne artikel følger i stedet bilag VII i forordningens egen rækkefølge og beskriver, hvad en gennemgang typisk leder efter under hvert punkt. Kravene står i artikel 31 og bilag VII. Måden at gennemgå dem på er praksis og ikke noget, forordningen foreskriver.
Hvad artikel 31 kræver
Ifølge artikel 31, stk. 1, skal dokumentationen indeholde alle relevante data eller oplysninger om de midler, fabrikanten bruger for at sikre, at produktet og processerne opfylder bilag I. Bilag VII er minimum. Efter stk. 2 skal den ligge færdig inden omsætningen og derefter holdes ajour, hvor det giver mening, mindst så længe supportperioden løber.
Artikel 13, stk. 4, føjer en vigtig detalje til. Risikovurderingen skal indgå i dokumentationen. Vurderer fabrikanten, at et af de væsentlige krav ikke er relevant for produktet, skal der stå en klar begrundelse.
Bilag VII bruger udtrykket “alt efter hvad der er relevant”. For et rent softwareprodukt falder fotos af produktet derfor bort, fordi de er tænkt til hardware.
De otte punkter set fra et softwareprodukt
Punkt 1, generel beskrivelse. Punktet rummer det tilsigtede formål, en angivelse af hvilke softwareversioner der spiller ind på kravene, og brugeroplysningerne fra bilag II. En gennemgang ser typisk efter, om formålet her stemmer med det, produktsiden lover, og om versionsangivelsen er så præcis, at en myndighed kan se, hvilken udgave dokumentationen gælder.
Punkt 2, design, udvikling, produktion og sårbarhedshåndtering. Bilaget beder om en systemarkitektur, der forklarer, hvordan softwarekomponenter bygger på eller indgår i hinanden. Punktet omfatter også sårbarhedshåndteringen med softwarekomponentlisten, politikken for koordineret offentliggørelse, en kontaktadresse til indberetning og de tekniske løsninger til sikker distribution af opdateringer. Endelig nævnes produktions- og overvågningsprocesserne og valideringen af dem. At produktion for software typisk svarer til bygge- og frigivelseskæden, er vores tolkning.
Punkt 3, risikovurderingen. Vurderingen af cybersikkerhedsrisici skal vise, hvordan kravene i bilag I, del I, finder anvendelse på netop dette produkt. En gennemgang prøver, om hvert krav enten er dækket eller har en begrundelse.
Punkt 4, supportperioden. Dokumentationen skal rumme de oplysninger, der blev taget i betragtning, da supportperioden blev fastsat. Det er altså begrundelsen for perioden, der efterspørges, og datoen alene er ikke nok.
Punkt 5, standarder og specifikationer. Her angives anvendte harmoniserede standarder, fælles specifikationer eller certificeringsordninger. Er de ikke anvendt, beskrives løsningerne og de andre tekniske specifikationer. Så længe ingen harmoniseret CRA-standard har sin reference i EUT, og i november 2026 havde ingen det, bliver punktet i praksis en beskrivelse af egne løsninger.
Punkt 6, afprøvninger. Rapporter om afprøvning af produktet og af sårbarhedshåndteringsprocesserne mod bilag I, del I og II. Forordningen kræver ingen bestemt testmetode.
Punkt 7, erklæringen. En kopi af EU-overensstemmelseserklæringen.
Punkt 8, komponentlisten til myndigheden. Softwarekomponentlisten indgår i givet fald efter begrundet anmodning fra en markedsovervågningsmyndighed. Listen hører altså til sårbarhedshåndteringen i punkt 2, og punkt 8 handler om udleveringen.
Fjerndatabehandling og andres tjenester
Bilag VII nævner ikke fjerndatabehandling med ord. Det gør Kommissionens vejledning fra juli 2026 i punkt 204. Efter vejledningen bør fabrikanten angive i dokumentationen, at produktet har løsninger til fjerndatabehandling eller bygger på tredjeparters fjernløsninger, og beskrive dem. Understøtter samme løsning flere produkter, angives den i hvert produkts dokumentation, men beskrivelsen må genbruges. Det er vejledning og ikke forordningens tekst. Hvilke dele af en backend der overhovedet hører til produktet, er behandlet i fjerndatabehandling.
Sprog, modtagere og myndighedens adgang
Kommissionens FAQ siger, at dokumentationen kan skrives på ethvert sprog. På anmodning skal den gives på et sprog, myndigheden let forstår. Til et bemyndiget organ udfærdiges den på et officielt sprog i organets land eller et sprog, organet accepterer, jf. artikel 31, stk. 4.
Der er efter FAQ’en ingen pligt til at give kunder eller offentligheden adgang. Undtagelsen er open source i bilag III, der stilles til rådighed uden betaling og selv erklærer overensstemmelse efter artikel 32, stk. 5.
Myndighedens adgang stopper ikke ved det samlede dokument. Artikel 53 giver efter begrundet anmodning adgang til data om design, udvikling, produktion og sårbarhedshåndtering, herunder den relevante interne dokumentation. Dokumentationen bør derfor kunne føres tilbage til de arbejdspapirer, den bygger på.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at nogen ejer dokumentet som helhed og ved, hvor hvert punkt hentes fra. Arkitekturen kommer fra udviklingen, supportperioden fra ledelsen og afprøvningerne fra test. Uden en ejer bliver dokumentationen en mappe med filer, der ikke hænger sammen.
Manglende eller ufuldstændig dokumentation står som et af de formelle forhold i artikel 58, stk. 1, litra f. Myndigheden kan pålægge fabrikanten at bringe forholdet til ophør, og varer det ved, kan tilgængeliggørelsen begrænses eller forbydes.
Det skal I lade være med
- At skrive “ikke relevant” uden begrundelse · et fravalgt krav skal begrundes klart efter artikel 13, stk. 4.
- At lade punkt 5 stå tomt, fordi standarderne mangler · bilaget beder så om en beskrivelse af egne løsninger.
- At lægge komponentlisten ud til alle · bilag VII forudsætter udlevering til myndigheden efter anmodning; deling med brugere er et valg.
Det skal auditten kunne vise
- ☐ Et dokument eller en samling med en indholdsfortegnelse, der følger de otte punkter.
- ☐ En entydig angivelse af de softwareversioner, dokumentationen dækker.
- ☐ En arkitekturbeskrivelse, der viser komponenternes indbyrdes afhængighed.
- ☐ Risikovurderingen, hvor hvert enkelt væsentligt krav er dækket eller begrundet fravalgt.
- ☐ Grundlaget for supportperioden og rapporter fra afprøvninger.
- ☐ En beskrivelse af fjerndatabehandling og tredjeparters fjernløsninger, hvor de findes.
Kilder
- Forordning (EU) 2024/2847 om cyberrobusthed, artikel 13, stk. 4, artikel 31, 53 og 58 samt bilag VII, læst 13. november 2026 i Publikationskontorets udgave af EUT-teksten.
- Europa-Kommissionen, Commission guidance on the application of Regulation (EU) 2024/2847, C(2026) 5252, punkt 204, læst 13. november 2026.
- Europa-Kommissionen, FAQs on the Cyber Resilience Act, version 1.4, afsnit 6.6, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Læg jeres nuværende dokumentation ved siden af de otte punkter, og skriv for hvert punkt, hvor indholdet ligger, og hvem der ejer det.
Læs også: Cybersikkerhedsrisikovurderingen for et softwareprodukt · Softwarekomponentlisten (SBOM) efter CRA
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
