Et væsentligt krav i bilag I kan være uden relevans for jeres software, men så skal den tekniske dokumentation rumme en klar begrundelse. Begrundelsen holder kun, hvis den passer med det, softwaren faktisk gør, og det er det, en gennemgang prøver.
Reglen findes i artikel 13, stk. 4, i forordning (EU) 2024/2847, og den får virkning den 11. december 2027. Ordlyden er kort: “Hvis visse væsentlige cybersikkerhedskrav ikke er relevante for produktet med digitale elementer, medtager fabrikanten en klar begrundelse herfor i den tekniske dokumentation.”
Hvilke krav kan være uden relevans?
Kravene i bilag I, del I, nr. 2, gælder på grundlag af risikovurderingen og “hvor det er relevant”. Det er dem, der kan fravælges med en begrundelse. Del II af bilag I om sårbarhedshåndtering gælder derimod altid i hele supportperioden. Dem kan man ikke kalde irrelevante (FAQ 4.1.3).
Kommissionens tjenestegrenes FAQ nævner to grunde til, at et krav kan være uden relevans. Kravet kan være uforeneligt med produktets karakter, som betragtning 55 beskriver, eller der findes ingen risici, som kravet skulle afbøde. FAQ’en giver et eksempel. Et produkt, hvis formål og forudsigelige brug ikke omfatter personoplysninger, behøver ikke særlige foranstaltninger for dem. Kan softwaren teknisk set alligevel bruges til personoplysninger, og kan det give betydelige risici ved forudsigelig fejlanvendelse, kan brugeroplysningerne skulle nævne det (bilag II, nr. 5).
Betragtning 55 tilføjer en vigtig grænse. Også når et krav ikke finder anvendelse, skal de risici, fabrikanten har fundet, imødegås på anden vis.
Fire typer begrundelser
Typerne nedenfor er vores egen opdeling. De er valgt, fordi de ligger tæt på de undtagelser og eksempler, kilderne selv nævner. Listen er ikke udtømmende, og ingen kilde opstiller den.
1. Ingen grænseflade. “Produktet har ingen netværksgrænseflade, så kravet om begrænsede angrebsflader er ikke relevant.” Kravet i litra j omfatter eksterne grænseflader. Begrundelsen holder kun, hvis en installeret kopi faktisk ikke lytter på nogen port, ikke åbner lokale sokler, ikke har en fejlsøgningsflade og ikke kalder ud til tjenester, der kan svare. Et program kan have en grænseflade, som ingen har tænkt over, fx en lokal webserver til konfiguration eller en kanal til opdateringer.
2. Ingen data. “Produktet behandler ingen fortrolige data.” Prøven er, hvad softwaren gemmer og sender i praksis, også logfiler, fejlrapporter, cache og telemetri. Et program uden brugerdata kan stadig gemme adgangsnøgler, tokens eller konfiguration, der giver adgang til andre systemer.
3. Komponent til integration. “Biblioteket integreres af andre, så kravet om automatiske opdateringer gælder ikke.” Her har begrundelsen støtte i kilderne. Betragtning 56 undtager produkter, hvis primære formål er at indgå som komponent i andre produkter, fra kravene om automatiske opdateringer. FAQ 4.2.4 siger, at sikker standardkonfiguration kun gælder komponenten, som den leveres. Begrundelsen holder ikke for de øvrige krav. Et bibliotek skal stadig være uden kendte udnyttelige sårbarheder og have sikre standardværdier i det, det leverer.
4. Professionelt miljø. “Produktet bruges kun i lukkede industrinet, så automatiske opdateringer er ikke relevante.” Betragtning 56 nævner produkter, hvor brugerne ikke med rimelighed kan forvente automatiske opdateringer, herunder produkter til professionelle IKT-net, navnlig kritiske og industrielle miljøer. Begrundelsen holder, hvis formålet i dokumentation og salgsmateriale faktisk er afgrænset til den slags miljøer. Sælges samme software også til almindelige kontorer, falder begrundelsen.
Prøven mod produktets adfærd
Det, de fire typer har til fælles, er, at begrundelsen er en påstand om softwaren. En gennemgang prøver påstanden mod en installeret kopi og mod de andre dokumenter. Det er praksis og ikke et lovkrav, men artikel 13, stk. 4, kræver en klar begrundelse, og en begrundelse, der ikke passer med produktet, er ikke klar.
I praksis kan prøven bestå af tre trin. Først læses begrundelsen. Så kontrolleres den mod produktets egen adfærd, fx hvilke porte der er åbne, hvilke filer der skrives, og hvilke forbindelser der oprettes. Til sidst sammenholdes den med formålet i brugeroplysninger og salgsmateriale.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at hver begrundelse skrives konkret nok til at kunne efterprøves, og at nogen har kontrolleret den mod softwaren. En linje som “ikke relevant for dette produkt” opfylder ikke kravet om en klar begrundelse.
Uden den kontrol kan et krav, der var relevant, stå som fravalgt i dokumentationen. Det kan opdages, så snart nogen installerer produktet og ser, hvad det gør.
Det skal I lade være med
- At kalde krav i bilag I, del II, irrelevante · sårbarhedshåndteringen gælder altid.
- At bruge komponentbegrundelsen på alle krav · den bærer kun bestemte krav.
- At skrive “ikke relevant” uden forklaring · artikel 13, stk. 4, kræver en klar begrundelse.
- At glemme risikoen bag et fravalgt krav · betragtning 55 kræver, at den imødegås på anden vis.
Det skal auditten kunne vise
- ☐ En liste over de litraer i del I, nr. 2, der er vurderet som ikke relevante.
- ☐ En konkret begrundelse for hvert fravalg i den tekniske dokumentation.
- ☐ Et spor af, at begrundelsen er kontrolleret mod en installeret kopi.
- ☐ For fravalgte krav med identificerede risici: de foranstaltninger, der imødegår dem.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 4, bilag I, bilag II, nr. 5, og betragtning 55 og 56, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.1.3 og 4.2.4, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find alle steder i jeres tekniske dokumentation, hvor der står “ikke relevant”, og læs begrundelsen mod en frisk installation.
Læs også: Kravet kan ikke opfyldes fuldt · Biblioteker, SDK’er og komponenter solgt særskilt
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
