Software må kun behandle de data, der er tilstrækkelige, relevante og nødvendige for produktets tilsigtede formål. Kravet om dataminimering er fastsat ved bilag I, del I, nr. 2, litra g, og skal opfyldes fra 11. december 2027 og omfatter også data, der ikke er personoplysninger.
Mange softwarehuse kender dataminimering fra GDPR. I CRA er det et produktkrav, og det rammer bredere.
Ordlyden
Litra g kræver, at produktet kun behandler personoplysninger eller andre data, der er tilstrækkelige, relevante og begrænset til, hvad der er nødvendigt i forhold til det tilsigtede formål med produktet. Forordningen kalder det selv dataminimering.
Læg mærke til to ting. Kravet nævner udtrykkeligt “andre data”. Og målestokken er produktets tilsigtede formål, sådan som fabrikanten har beskrevet det. Hvad der er nødvendigt, afhænger altså af, hvad produktet er til, og ikke af, hvad det kunne være rart for fabrikanten at vide.
Som ved resten af nr. 2 er det fabrikantens risikovurdering, der viser, hvordan kravet rammer netop dette produkt.
Hvad kravet gør og ikke gør for GDPR
Kommissionens FAQ forklarer forholdet. CRA og GDPR er af forskellig art, har intet retligt overlap og kan supplere hinanden. At et produkt overholder CRA, har ingen formel betydning for de redskaber, en dataansvarlig eller databehandler bruger til at vise overholdelse af GDPR, for eksempel adfærdskodekser efter GDPR’s artikel 40 eller certificering efter artikel 42.
Det betyder i praksis, at en gennemgang efter CRA ikke er en GDPR-vurdering, og at en GDPR-vurdering ikke dækker litra g. Har I lavet en konsekvensanalyse efter GDPR, kan den bruges som input til dataoversigten, men den beviser ikke, at produktets øvrige data er begrænset. Den sidste sætning er vores tolkning.
Data, softwaren sender hjem
Forordningen og de læste vejledninger nævner ikke telemetri eller fejlrapporter ved navn. Vi bruger dem som eksempler, fordi det er der, de fleste softwareprodukter sender data, som brugeren ikke selv har bedt om. Det er en tolkning af, hvad litra g rammer.
Typiske strømme i et softwareprodukt er:
- Brugsstatistik: hvilke funktioner der bruges, hvor ofte og hvor længe.
- Fejlrapporter: stakspor, hukommelsesudtræk og systemoplysninger ved nedbrud.
- Diagnosepakker: logfiler og konfiguration, der sendes til support.
- Licens- og aktiveringskald: maskin-id, version og placering.
- Opdateringstjek: version, styresystem og installerede moduler.
For hver strøm spørger gennemgangen, hvilket formål den tjener, og om hvert felt er nødvendigt for det formål. Et hukommelsesudtræk kan indeholde alt, hvad brugeren havde åbent. En diagnosepakke kan indeholde adgangsoplysninger fra en konfigurationsfil. Ingen af delene er personoplysninger i alle tilfælde, men begge kan være mere, end formålet kræver.
Logfiler
Logning kan være nødvendig for sikkerheden og er et selvstændigt krav i litra l. Det fritager ikke logfilerne for litra g. I et af vejledningens eksempler får et produkt en ny funktion til log og diagnose, som sender udførlige systemlogge ud og lægger følsomme driftsoplysninger på disken uden kryptering. Kommissionen regner det for en mulig væsentlig ændring. Eksemplet viser, at mere logning ikke automatisk er bedre, og at indholdet skal vurderes.
Hvordan en gennemgang prøver det
En almindelig fremgangsmåde er at bruge en installeret kopi i en periode, fremprovokere en fejl og se på den trafik, produktet sender. Indholdet sammenholdes med en dataoversigt, hvor fabrikanten har skrevet hver strøm og hvert felt op med formål. Felter uden formål er fund. Det samme er strømme, der ikke står i oversigten.
Gennemgangen ser også på, om brugeren kan slå valgfri strømme fra, og om produktet stadig virker bagefter. Forordningen kræver ikke et fravalg i litra g, men et felt, der kan undværes uden at produktet holder op med at virke, er svært at kalde nødvendigt. Den slutning er vores.
Prøven er praksis. En bestemt metode er ikke foreskrevet, og vi kender ingen harmoniseret standard til forordningen, som var offentliggjort i november 2026.
Nye funktioner og nye felter
Dataminimering er ikke noget, der klares én gang. Hver ny version kan tilføje en strøm eller et felt. Et softwarehus, der frigiver ofte, har derfor brug for en enkel regel i udviklingsprocessen: ingen ny datastrøm uden en linje i oversigten med formål og felter. Reglen er en arbejdsgang, I selv vælger. Den gør det muligt at vise, hvornår et felt kom til, og hvorfor.
Det samme gælder tredjepartskomponenter. Et analysebibliotek eller et fejlrapporteringsbibliotek, der bygges ind i produktet, kan sende data, som jeres egen kode aldrig rører. De data er stadig produktets. Komponentens dokumentation bør derfor læses med litra g for øje, før den tages i brug, og dens trafik bør med i den samme sammenligning som resten.
Hvad det kræver, og hvad det koster at lade være
Det kræver en dataoversigt for hver strøm, produktet sender eller gemmer, med formål og felter, og en vurdering af nødvendighed knyttet til produktets tilsigtede formål.
Uden oversigten vokser dataindsamlingen med hver ny funktion, fordi det er let at sende et felt mere. Det er også en sikkerhedsrisiko. Data, der ikke indsamles, kan ikke lække.
Det skal I lade være med
- At afgrænse kravet til personoplysninger · litra g omfatter også andre data.
- At bruge GDPR-dokumentationen som bevis for litra g · Kommissionen beskriver de to regelsæt som uden retligt overlap.
- At sende hele logfiler, når et uddrag er nok · indholdet skal stå i forhold til formålet.
Det skal auditten kunne vise
- ☐ En dataoversigt med hver strøm, hvert felt og formålet.
- ☐ Produktets tilsigtede formål, som nødvendigheden måles imod.
- ☐ Resultat af en sammenligning mellem oversigten og den trafik, en installeret kopi sender.
- ☐ Vurdering af nye datastrømme ved hver version.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, bilag I, del I, nr. 2, litra g og l, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, eksempel 45, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 2.8.1, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv hver datastrøm, jeres produkt sender hjem, op med formål, og stryg de felter, I ikke kan begrunde.
Læs også: Sikkerhedslogning som produktkrav · Fortrolighed
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
