Udgaver af jeres software, der adskiller sig i komponenter, konfiguration eller aktiverede funktioner, er efter Kommissionens vejledning særskilte produkter, når de bringes i omsætning. Deler de arkitektur, sikkerhedsrelevant design og formål og står over for de samme risici, kan de alligevel dele risikovurdering, teknisk dokumentation, overensstemmelsesvurdering og én EU-overensstemmelseserklæring.
Spørgsmålet er altså todelt. Først om varianterne er forskellige produkter, og dernæst hvor meget af papirarbejdet de kan have fælles.
Varianter er særskilte produkter
Kommissionens vejledning C(2026) 5252 (ikke bindende) siger i punkt 14, at varianter, der adskiller sig i komponenter, konfigurationer eller aktiverede funktioner, ikke er kopier af samme produkt. Vejledningen nævner selv builds til forskellige styresystemer og pakker med forskellige funktioner som eksempler. De behandles som særskilte produkter, når det handler om at bringe dem i omsætning.
For et softwarehus betyder det efter vores læsning, at en udgave til to styresystemer, en standard- og en professionel udgave og en lokal og en cloudtilknyttet installation hver for sig er produkter. Hver har sin dato for, hvornår den er bragt i omsætning.
Hvornår papirarbejdet kan deles
Vejledningens afsnit 7.4, punkt 174 til 177, åbner for genbrug. Deler varianterne arkitektur, sikkerhedsrelevant design og tilsigtet formål og er udsat for de samme risici, kan fabrikanten bruge én risikovurdering, ét sæt teknisk dokumentation og én overensstemmelsesvurdering. Fabrikanten kan også udstede én EU-overensstemmelseserklæring, når den klart identificerer varianterne.
Det afgørende er efter vejledningen, om forskellene er relevante for cybersikkerheden. Vejledningen nævner fire slags forskelle, der skal afspejles.
- Kommunikationsgrænseflader · Nye veje ind i produktet
- Softwarestakke · Andre komponenter og andre sårbarheder
- Opdateringsmekanismer · Anden sikring af distributionen
- Fjernforbindelse · Andre angrebsscenarier
Indfører en ny variant nye risici, skal risikovurdering og dokumentation opdateres (punkt 177).
Tre spørgsmål til hver variant
Det er praksis at stille de samme spørgsmål til hver ny variant, før den lægges ind under en eksisterende familie. Spørgsmålene er afledt af punkt 174 til 177.
- Har varianten den samme arkitektur og det samme sikkerhedsrelevante design som familien?
- Har den det samme tilsigtede formål og den samme forudsigelige brug?
- Har den grænseflader, komponenter, opdateringsveje eller fjernforbindelser, som familien ikke har?
Er svaret ja til de to første og nej til det sidste, kan varianten efter vejledningen dele familiens papirer. Ellers skal forskellen beskrives og vurderes.
Et tænkt eksempel
Et softwarehus har et kasseprogram til butikker i tre udgaver. Basisudgaven kører lokalt. Pro-udgaven har den samme kode, men flere rapporter slået til. Kæde-udgaven har derudover en forbindelse til en central server, hvor priser og lagertal synkroniseres, og en fjernadgang for support. Basis og Pro deler arkitektur, formål og risici, og efter vejledningen kan de have én risikovurdering og én erklæring, der nævner begge. Kæde-udgaven har en ny grænseflade, en fjernforbindelse og formentlig fjerndatabehandling. Den kan godt være med i familien, men forskellene skal beskrives og vurderes for sig, og risikovurderingen skal opdateres, før den bringes i omsætning. Eksemplet er tænkt.
Klasse følger kernefunktionen
Et produkt kan kun have én kernefunktion i forhold til klassificering som vigtigt eller kritisk produkt (punkt 144). Varianter, der har samme kernefunktion, havner i samme klasse. Sælger I et modul for sig, kan det få sin egen klasse, og det står i artiklen om tillægsmoduler solgt særskilt.
Erklæringen skal kunne skelne
Bruger I én EU-overensstemmelseserklæring for en familie, skal den klart identificere de varianter, den dækker. Hertil kommer artikel 13, stk. 15, hvorefter hvert produkt skal kunne identificeres, fx med et typenummer. I software løses det som regel med produktnavn, udgave og version.
Erklæringen er fabrikantens egen og underskrives af fabrikanten. En uvildig gennemgang kan efterprøve, om varianterne er beskrevet, og om forskellene er vurderet, men den kan ikke stå inde for erklæringen.
Hvad det kræver, og hvad det koster at lade være
Det kræver en oversigt over alle udgaver og builds, som de faktisk leveres, og en vurdering af, hvad der adskiller dem. For softwarehuse med mange konfigurationer er det oversigten, der tager tid.
Lægges alle varianter under ét sæt papirer uden vurdering, kan en variant med en ekstra grænseflade eller en anden opdateringsvej stå uden risikovurdering. Skrives en fuld dokumentation for hver, bruges kræfter på gentagelse, som vejledningen ikke kræver.
Det skal I lade være med
- At regne alle builds for samme produkt · varianter er særskilte produkter efter punkt 14.
- At dele risikovurdering uden at se på forskellene · grænseflader, stakke, opdateringer og fjernforbindelse skal afspejles.
- At udstede én erklæring, der ikke nævner varianterne · den skal identificere dem klart.
Det skal auditten kunne vise
- ☐ En oversigt over udgaver og builds med deres forskelle.
- ☐ For hver familie en begrundelse for, at varianterne deler design, formål og risici.
- ☐ Afspejling af sikkerhedsrelevante forskelle i risikovurdering og dokumentation.
- ☐ En erklæring, der klart identificerer de varianter, den dækker.
Kilder
- Forordning (EU) 2024/2847, dansk tekst, artikel 13, stk. 15, læst 13. november 2026 i Publikationskontorets kopi.
- Kommissionens vejledning C(2026) 5252, punkt 14, 144 og 174 til 177, ikke bindende, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Lav en oversigt over jeres udgaver og builds, og stil de tre spørgsmål til hver.
Læs også: Hvornår er softwaren bragt i omsætning? · EU-overensstemmelseserklæringen for software
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
