Når jeres produkt er omfattet af Cyber Resilience Act, skal test ikke kun kunne vises til kunder, men også ligge i den tekniske dokumentation, som en markedsovervågningsmyndighed kan bede om. Svaret på, hvad forordningen forventer, hviler på tre steder i teksten: kravet om afprøvning i bilag I, listen over den tekniske dokumentation i bilag VII og reglerne om overensstemmelsesvurdering i artikel 32. Forordningen nævner ikke penetrationstest. Den kræver afprøvninger og rapporter om dem, og en pentestrapport kan være én af dem.
Om produktet er omfattet, og hvornår reglerne gælder, står i oversigten. → Cyber Resilience Act: hvad softwarehuse skal holde øje med Teksten her er ikke juridisk rådgivning og lover ikke overensstemmelse.
Hvor forordningen kræver afprøvning
Bilag I har to dele. Del I indeholder de væsentlige cybersikkerhedskrav til selve produktet, fx beskyttelse mod uautoriseret adgang, beskyttelse af dataenes fortrolighed og integritet, og at angrebsfladen begrænses. Efter artikel 13, stk. 2, skal kravene anvendes på grundlag af fabrikantens egen vurdering af cybersikkerhedsrisici.
Del II handler om håndtering af sårbarheder. Punkt 3 kræver, at fabrikanten anvender effektive og regelmæssige afprøvninger og gennemgange af produktets sikkerhed. Ordlyden fastsætter hverken metode eller rytme. Det er jer som fabrikant, der skal kunne forklare, hvorfor de afprøvninger, I har valgt, er effektive for netop jeres produkt.
Rapporterne i den tekniske dokumentation
Artikel 31 kræver teknisk dokumentation, der som minimum indeholder elementerne i bilag VII. Den skal udarbejdes, før produktet bringes i omsætning, og ajourføres løbende, i det mindste i supportperioden. Efter artikel 13, stk. 13, opbevares den i mindst ti år efter, at produktet er bragt i omsætning, eller i supportperioden, hvis den er længere.
Bilag VII, punkt 6, nævner rapporter om de afprøvninger, der er foretaget for at kontrollere, at produktet og sårbarhedshåndteringsprocesserne opfylder kravene i bilag I, del I og II. Tre andre punkter har betydning for testen:
- Punkt 1, litra b · de softwareversioner, der påvirker overholdelsen af kravene. En testrapport skal derfor kunne knyttes til en version.
- Punkt 3 · vurderingen af cybersikkerhedsrisici. Testens omfang bør kunne forklares ud fra den.
- Punkt 5 · de harmoniserede standarder eller andre tekniske specifikationer, der er anvendt. Er testen gennemført efter en bestemt standard, hører den henvisning med.
Kravet om løbende ajourføring betyder, at dokumentationen følger produktet gennem supportperioden. Når en ny version ændrer noget, der påvirker kravene, skal I kunne vise, hvordan den er afprøvet. En rapport fra lanceringen kan derfor ikke stå alene, hvis produktet siden er ændret væsentligt. → Hvilke ændringer kræver en ny test?
En rapport, der er skrevet til kunder, er ikke nødvendigvis skrevet til dokumentationen. Kundeversionen kan udelade detaljer, som dokumentationen har brug for. → Version og testdatoer
Egen vurdering eller et bemyndiget organ
Artikel 32, stk. 1, lader fabrikanten vælge mellem flere procedurer, herunder intern kontrol efter modul A i bilag VIII. Ved intern kontrol udarbejder fabrikanten selv den tekniske dokumentation og erklærer på eget ansvar, at kravene er opfyldt.
For vigtige produkter er det anderledes. Artikel 7 henviser til bilag III, der deler dem i klasse I og klasse II. Klasse I omfatter bl.a. software til identitetsstyring og privilegeret adgang, browsere, VPN-produkter og operativsystemer. Efter artikel 32, stk. 2, kan et produkt i klasse I kun bruge intern kontrol, hvis fabrikanten har anvendt harmoniserede standarder, fælles specifikationer eller en certificeringsordning fuldt ud. Ellers skal et bemyndiget organ ind. For klasse II kræver stk. 3 altid en af de procedurer, hvor et bemyndiget organ medvirker, eller en certificeringsordning. Kritiske produkter i bilag IV har egne regler efter artikel 8 og artikel 32, stk. 4.
Ved EU-typeafprøvning efter modul B kan fabrikantens støttedokumentation omfatte resultater af afprøvninger, som fabrikanten eller et afprøvningslaboratorium har foretaget på fabrikantens vegne og ansvar. Det bemyndigede organ kan derudover selv foretage eller lade foretage de afprøvninger, det finder nødvendige. Jeres pentestrapport kan altså indgå i materialet, men den erstatter ikke organets egen vurdering.
Harmoniserede standarder
Artikel 27, stk. 1, giver en formodning om overensstemmelse med de krav, som en harmoniseret standard dækker, når standardens reference er offentliggjort i EU-Tidende. Samme stykke pålægger Kommissionen at bede de europæiske standardiseringsorganisationer om at udarbejde sådanne standarder. Tjek, om der er offentliggjort referencer, før I planlægger dokumentationen ud fra en bestemt standard, og spørg testeren, om testen kan tilrettelægges efter den.
Hvad en pentestrapport kan og ikke kan bidrage med
En penetrationstest kan belyse en række af kravene i bilag I, del I, i en bestemt version: om adgangskontrollen holder, om data i produktet er beskyttet mod uvedkommende, og om der er unødvendige indgange. Den kan også vise, at afprøvningen efter del II, punkt 3, faktisk finder sted.
Den kan ikke dokumentere resten af del II. Softwarekomponentlisten, politikken for koordineret offentliggørelse, kontaktadressen og distributionen af opdateringer er processer, som kræver deres egen dokumentation. Testen kan heller ikke stå alene som bevis for, at afprøvningen er regelmæssig. Det kræver en plan og en række rapporter over tid. → Et årshjul for sikkerhedstest
Bestil testen, så den kan bruges i dokumentationen
Aftal med testeren, før testen begynder, at rapporten også skal kunne bruges i den tekniske dokumentation:
- ☐ Rapporten angiver produktets navn og den testede version.
- ☐ Omfanget kan forklares ud fra jeres risikovurdering.
- ☐ Metode og eventuel standard er beskrevet.
- ☐ Fund har en status, og rettelser kan følges til en ny version.
- ☐ Rapporten kan opbevares i hele den periode, artikel 13 kræver.
- ☐ Der findes en kundeversion ved siden af den fulde rapport.
Efterprøvning af rettelser hører også med, fordi dokumentationen skal vise den version, der bringes i omsætning. → Retest efter rettelser i en ny release
Det skal I lade være med
- At kalde produktet CRA-godkendt efter en pentest · overensstemmelsesvurderingen er en procedure, ikke en test.
- At sende kundeversionen ind som dokumentation uden at se på den · den kan mangle version, metode eller fund.
- At antage, at intern kontrol altid er nok · produkter i bilag III kan kræve et bemyndiget organ.
- At lade én rapport dække flere versioner uden forklaring · bilag VII kræver versioner, der påvirker overholdelsen.
- At lade testen stå for hele sårbarhedshåndteringen · del II rummer processer, testen ikke viser.
Hvad kan og ikke kan konkluderes
Forordningens tekst viser, at fabrikanten skal afprøve produktets sikkerhed regelmæssigt, og at rapporter om afprøvningerne hører til den tekniske dokumentation. Den afgør ikke, hvilken metode der skal bruges, eller med hvilken hyppighed. En pentestrapport kan være et af bidragene, men den viser ikke overensstemmelse, og den erstatter hverken jeres egen vurdering eller et bemyndiget organs.
Kilder
- Cyber Resilience Act, forordning (EU) 2024/2847: artikel 7, stk. 1 (vigtige produkter, bilag III), artikel 8 (kritiske produkter), artikel 13, stk. 2 og 13 (risikovurdering og opbevaring i ti år eller supportperioden), artikel 27, stk. 1 (harmoniserede standarder), artikel 31, stk. 1 og 2 (teknisk dokumentation), artikel 32, stk. 1 til 4 (procedurer), bilag I, del I og del II, punkt 3, bilag III, bilag VII, punkt 1, 3, 5 og 6, og bilag VIII, del I og II (modul A og modul B). Kontrolleret i den danske tekst.
- Styrelsen for Samfundssikkerhed: Cyber Resilience Act: dansk myndighedsside om forordningen og datoerne.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om pentestrapporten
Læs også: Installation hos kunden · Bestil testen til kundebrug
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest af SaaS hos Nielco IT
