En funktion, der allerede er beskrevet, vurderet og afbødet i risikovurderingen, gør efter Kommissionens vejledning ikke den senere release til en væsentlig ændring. Derfor kan det betale sig at skrive roadmappen ind i risikovurderingen fra første version.
Kommissionens vejledning er ikke bindende, og forordningens krav gælder fra 11. december 2027. Men den viser, hvordan et softwarehus kan planlægge sin udvikling, så hver ny funktion ikke kræver en ny overensstemmelsesvurdering.
Hvad vejledningen siger
Kommissionens vejledning (punkt 106) skriver, at en fabrikant gradvist kan indføre nye funktioner, der allerede indgår i risikovurderingen. Det forudsætter, at udviklingen var forudset, at risiciene var beskrevet og vurderet, og at afbødningerne var gennemført. Opdateringer af den slags er ikke væsentlige ændringer.
Ræsonnementet hænger sammen med definitionen i artikel 3, nr. 30. En væsentlig ændring påvirker overensstemmelsen eller ændrer det tilsigtede formål. Hvis funktionen allerede er en del af det vurderede formål og den vurderede risiko, ændrer releasen ingen af delene.
Kommissionens to eksempler
Vejledningen giver to tænkte eksempler, der viser, hvornår det virker.
Beskedappen (eksempel 42). En app starter med beskeder mellem to personer. Risikovurderingen dækker allerede senere gruppebeskeder, herunder den mere komplekse routing. Da gruppechat med værktøjer til administratorer og moderation kommer, var den forudset, og det er ikke en væsentlig ændring.
Overvågningssystemet (eksempel 43). Et system leveres med skrivebeskyttede dashboards, og styringsfunktionerne er slået fra. Risikovurderingen dækker udtrykkeligt, at styringen senere aktiveres, inklusive de sikkerhedsforanstaltninger, der hører til. Den senere aktivering er ikke en væsentlig ændring.
Og to modeksempler
Vejledningen (punkt 105, eksempel 40 og 41) giver også to tilfælde, hvor det modsatte gælder. Et dashboard får ny styring af maskiner, som ikke var med i vurderingen. En app til personlige data får automatisk profilering. Begge ændrer formålet og er væsentlige ændringer.
Det, der skiller dem fra de to første eksempler, er, at funktionerne ikke stod i vurderingen fra start.
Hvor konkret skal det skrives?
Kilderne siger ikke mere om detaljeringsgraden end det, eksemplerne viser. Det følgende er vores tolkning af eksemplerne.
I begge positive eksempler er tre ting til stede. Funktionen er navngivet. De risici, den bringer med sig, er beskrevet. Og de foranstaltninger, der skal afbøde dem, er besluttet eller allerede bygget ind. I eksempel 43 er styringsfunktionerne endda leveret, bare slået fra.
En linje i roadmappen om “flere funktioner til teams” vil næppe være nok. En beskrivelse af gruppebeskeder med routing, adgangsstyring for administratorer og de trusler, det åbner for, ligner mere det, Kommissionen beskriver.
Et tænkt afsnit i en risikovurdering kunne have disse felter:
- Planlagt funktion · (deling af rapporter med eksterne modtagere)
- Forventet tidspunkt · (inden for supportperiodens første del)
- Nye trusselsvektorer · (link, der kan nås uden login)
- Risici og vurdering · (uautoriseret adgang til delte rapporter)
- Foranstaltninger · (tidsbegrænsede links, adgangskode, logning af åbninger)
- Status · (foranstaltninger bygget ind, funktionen slået fra)
Det, der stadig skal gøres ved releasen
Selv om funktionen var forudset, skal risikovurderingen og den tekniske dokumentation holdes ajour efter forordningens regler om løbende ajourføring (artikel 13, stk. 7, samt artikel 31, stk. 2). Ved releasen er det naturligt at kontrollere, om den funktion, der faktisk blev bygget, svarer til den, der blev vurderet.
Har udviklingen undervejs tilføjet en ny grænseflade eller en ny ekstern afhængighed, som ikke stod i vurderingen, skal releasen igennem de fire prøvesten som alle andre.
Når roadmappen ændrer sig
Roadmaps ændrer sig. En planlagt funktion kan blive droppet, og en ny kan komme til. Det første giver ingen problemer for overensstemmelsen. Det andet betyder, at den nye funktion ikke er forudset og skal vurderes ved releasen. Derfor er det en god idé at gennemgå risikovurderingens afsnit om planlagte funktioner, hver gang roadmappen revideres, og tilføje nye funktioner, så snart de er konkrete nok til, at risici og foranstaltninger kan beskrives. Det er praksis. Forordningen kræver ikke den rytme.
Kommissionens eksempel 43 viser en nyttig teknik. Funktionen leveres fra start, slået fra og med sine foranstaltninger. Det, der senere aktiveres, er så allerede en del af den vurderede og leverede kode.
Hvad gennemgangen ser efter
Gennemgangen kan sammenligne risikovurderingen fra første version med de funktioner, der siden er udgivet. For hver ny funktion stilles to spørgsmål. Stod den i vurderingen med risici og foranstaltninger? Og svarer den udgivne funktion til beskrivelsen?
Gennemgangen ser også på, om de foranstaltninger, vurderingen lovede, faktisk kom med i den udgivne kode.
Funktioner, der kom uden at stå i vurderingen, skal have en selvstændig vurdering ved releasen. Mangler den, er det et fund.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at produktchef og sikkerhedsansvarlig skriver roadmappen ind i risikovurderingen med en konkret beskrivelse af funktioner, risici og foranstaltninger. Det er mere arbejde ved første version, og det giver mindre arbejde ved de næste.
Uden det kan hver ny funktion udløse spørgsmålet om væsentlig ændring og dermed en ny overensstemmelsesvurdering af de ændrede dele. Det kan forsinke en release, der ellers var klar.
Det skal I lade være med
- At skrive en vag roadmap ind og regne med, at den dækker · Kommissionens eksempler er konkrete.
- At udvide funktionen undervejs uden at opdatere vurderingen · det, der blev bygget, skal svare til det vurderede.
- At regne en ny formålsændring for forudset · modeksemplerne viser grænsen.
Det skal auditten kunne vise
- ☐ Planlagte funktioner beskrevet i risikovurderingen med risici og foranstaltninger.
- ☐ Sammenligning af udgivne funktioner med vurderingens beskrivelse.
- ☐ Selvstændig vurdering af funktioner, der ikke var forudset.
- ☐ Ajourført teknisk dokumentation efter hver release.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 3, nr. 30, artikel 13, stk. 7, og artikel 31, stk. 2, læst 13. november 2026.
- Europa-Kommissionen, vejledning C(2026) 5252, punkt 105 og 106 med eksempel 40 til 43, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Tag de tre funktioner, der står øverst på jeres roadmap, og skriv for hver de risici og foranstaltninger, I allerede kender.
- Sårbarhedshåndtering, opdateringer og supportperiode
- Cybersikkerhedsrisikovurderingen for et softwareprodukt
Læs også: Væsentlig ændring · Tilsigtet formål og forudsigelig brug
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
