Forordningen foreskriver hverken en metode til risikovurdering eller en metode til at evaluere produktet, og pr. november 2026 er der ikke set offentliggjorte harmoniserede standarder til CRA. En gennemgang af udviklingsprocessen må derfor vælge sin målestok og begrunde valget, og bilag VII giver listen over det bevis, målestokken skal kunne bære.
Kravene i forordning (EU) 2024/2847 til risikovurdering, udviklingsproces og teknisk dokumentation gælder fra 11. december 2027. Det, der står her om metode, bygger på Kommissionens tjenestegrenes FAQ, som ikke er Kommissionens officielle holdning og ikke udvider pligterne.
To svar fra Kommissionens tjenestegrene
FAQ 4.1.2 handler om risikovurderingen. Forordningen kræver ingen bestemt metode. Metoden skal støtte dokumentationen af, at alle relevante risici er behandlet, så myndigheden kan efterprøve, hvordan de er identificeret, evalueret og afbødet. Trusselsmodellen skal passe til formål og forudsigelig brug. FAQ’en nævner statsaktører for produkter til kritisk infrastruktur og en lavere profil for forbrugerprodukter.
FAQ 6.5 handler om evalueringen. Ingen bestemt metode er foreskrevet, heller ikke for test. Det er almindelig praksis at bruge en passende harmoniseret standard eller teknisk specifikation. Myndigheden kan bruge samme metode eller, begrundet, en anden. FAQ’en tilføjer, at cybersikkerhedstest ikke er deterministiske. To test af samme produkt giver ikke nødvendigvis samme resultat.
Standarderne er ikke klar
Kommissionen har bedt de europæiske standardiseringsorganisationer om 41 standarder i anmodning M/606. Anmodningen blev justeret 10. november 2026. For alle vertikale og en del af de horisontale standarder fik organisationerne tre måneder mere. Kommissionens side om standardisering nævner ingen harmoniseret standard, hvis reference er offentliggjort i EU-Tidende. Datoer for, hvornår standarderne kommer, skriver vi ikke.
Det har to følger. For det første findes der ingen formodning om overensstemmelse at læne sig op ad. FAQ 4.1.7 minder om, at formodning kræver en standard, hvis reference er offentliggjort i EU-Tidende, og som dækker alle relevante risici (artikel 27). For det andet skal den tekniske dokumentation selv beskrive de løsninger, der er brugt.
Også når standarderne kommer, erstatter de ikke de væsentlige krav. Fabrikanten bærer fuldt ansvar for risikovurderingen, og dækker en standard kun en del, skal andre tekniske specifikationer eller løsninger efter almen ingeniørviden bruges (FAQ 4.1.7).
Bilag VII som bevisliste
Når der ikke er en standard at måle imod, er bilag VII det sted, forordningen selv siger, hvad dokumentationen skal indeholde. Det er vores metode at bruge det som bevisliste for en gennemgang af processen. De punkter, der handler om udviklingsprocessen, er især disse:
- Nr. 2 · Beskrivelse af design, udvikling og produktion og af sårbarhedshåndteringsprocesserne, herunder systemarkitektur, softwarekomponentliste, politik for koordineret offentliggørelse, kontaktadresse og løsningen til sikker distribution af opdateringer
- Nr. 2, litra c · Oplysninger om og specifikationer for produktions- og overvågningsprocesserne og valideringen af dem
- Nr. 3 · Cybersikkerhedsrisikovurderingen, herunder hvordan del I af bilag I bruges
- Nr. 5 · Anvendte harmoniserede standarder, fælles specifikationer eller certificeringsordninger, og hvor de ikke er anvendt, de løsninger, der er brugt, herunder en liste over andre relevante tekniske specifikationer
- Nr. 6 · Rapporter om de afprøvninger, der er foretaget for at kontrollere overensstemmelse med bilag I, del I og II
Nr. 5 er nøglen. Uden harmoniserede standarder skal fabrikanten liste de tekniske specifikationer, der faktisk er brugt. Det er den liste, en gennemgang kan måle processen op imod.
Sådan vælges og begrundes målestokken
Valget af målestok er praksis. En rimelig fremgangsmåde kan være:
- Tag udgangspunkt i det, fabrikanten selv har skrevet i bilag VII, nr. 5. Har fabrikanten valgt et anerkendt rammeværk for sikker udvikling, måles der mod det.
- Har fabrikanten ikke valgt noget, aftales en målestok før gennemgangen og skrives ind i rapporten med begrundelse.
- Kontrollér, at målestokken dækker bilag I, del I og II. Et rammeværk kan dække udviklingen godt og sårbarhedshåndteringen dårligt.
- Skriv tydeligt, at målestokken ikke giver formodning om overensstemmelse.
Navngivne rammeværk og standarder kan bruges som målestok, men ingen af dem er et krav efter forordningen, og vi rangerer dem ikke.
Kunder, der stiller krav til jeres udviklingsproces i en kontrakt, har deres egen vinkel på samme spørgsmål. Hvordan kunder kontrollerer en leverandør, er et andet emne end fabrikantens egen dokumentation.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at I vælger og skriver ned, hvilke tekniske specifikationer udviklingsprocessen følger, og at listen i bilag VII, nr. 5, svarer til virkeligheden. Valget kan ændres senere, når standarderne kommer, men det skal registreres.
Uden en valgt målestok har en gennemgang ingen fast grund at måle på, og myndigheden kan vælge sin egen. Efter FAQ 6.5 kan den bruge en anden metode end jeres, når den begrunder det.
Det skal I lade være med
- At vente på standarderne, før processen dokumenteres · bilag VII skal være på plads uden dem.
- At kalde et rammeværk for et krav · forordningen nævner ingen bestemt metode.
- At lade listen i bilag VII, nr. 5, stå tom · uden standarder skal de brugte løsninger beskrives.
Det skal auditten kunne vise
- ☐ En liste over de tekniske specifikationer, udviklingsprocessen følger, efter bilag VII, nr. 5.
- ☐ En begrundelse for valget af målestok, dateret og godkendt.
- ☐ En beskrivelse af udviklings- og sårbarhedsprocesserne efter bilag VII, nr. 2.
- ☐ Afprøvningsrapporter efter bilag VII, nr. 6.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 27 og bilag VII, nr. 2, 3, 5 og 6, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.1.2, 4.1.7 og 6.5, læst 13. november 2026.
- Europa-Kommissionen, Cyber Resilience Act: Standardisation, opdateret 12. november 2026, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Slå op, hvad der står i jeres tekniske dokumentation under bilag VII, nr. 5, og vurder, om det beskriver den proces, udviklerne faktisk følger.
Læs også: Ny byggekæde, ny proces eller ændret standard · Cybersikkerhedsrisikovurderingen for et softwareprodukt
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
