Software skal beskytte fortroligheden af de data, den gemmer, sender og behandler, og kryptering er forordningens eget eksempel på, hvordan det kan ske. Kravet hører hjemme under bilag I, del I, nr. 2, litra e, med virkning fra 11. december 2027 og omfatter både personoplysninger og andre data.
Kravet er et designvalg, der skal holde i hele supportperioden. Derfor ser en gennemgang både på det, produktet gør i dag, og på, om det kan følge med, når en algoritme bliver forældet.
Ordlyden
Litra e kræver, at produktet beskytter fortroligheden af opbevarede, videresendte eller på anden måde behandlede personoplysninger eller andre data, såsom ved at kryptere relevante data i hvile eller i transit ved brug af mekanismer på det aktuelle tekniske niveau og ved brug af andre tekniske midler.
Ordet “såsom” er vigtigt. Kryptering er et eksempel. Forordningen siger ikke, at alle data altid skal krypteres. Den siger, at fortroligheden skal beskyttes, og at kryptering af relevante data er en måde. Hvilke data der er relevante, og hvilke midler der passer, skal fremgå af risikovurderingen.
“Aktuelle tekniske niveau” er heller ikke defineret med tal eller navngivne algoritmer. Da vi så efter i november 2026, var der heller ikke offentliggjort en harmoniseret standard, der kunne udfylde begrebet. Fabrikanten må derfor selv begrunde, hvad det aktuelle niveau er.
Hvilke data har softwaren?
En gennemgang begynder med et kort over data. Hvad gemmer softwaren lokalt? Hvad sender den, og hvortil? Hvad ligger i midlertidige filer, caches og logfiler? Hvad udveksles med andre systemer?
For hver datatype spørger gennemgangen, om fortroligheden er vurderet, og om beskyttelsen svarer til vurderingen. Et typisk fund er data, der er krypteret under transport, men ligger ubeskyttet i en lokal cache. Et andet er nøgler, der ligger i samme mappe som de data, de beskytter. Begge er tænkte eksempler. Fælles for dem er, at beskyttelsen er god det ene sted og fraværende det andet, fordi ingen har set på helheden.
Platformens kryptering
Kommissionens vejledning har et eksempel, der passer på mange softwarehuse. Et program til professionel brug kører på administrerede enheder og gemmer følsomme data lokalt. Fabrikanten bruger styresystemets indbyggede kryptering og nøglehåndtering i stedet for at bygge sin egen, fordi platformens funktioner er modne og bliver vedligeholdt.
Eksemplet viser, at det kan være et godt valg at bygge på platformen. Det flytter ikke ansvaret. Risikovurderingen skal stadig beskrive, hvilken funktion der bruges, og hvad produktet forudsætter om platformen. Kører produktet også på platforme uden den funktion, skal det fremgå, hvad der så sker.
Skift af algoritme
Det, der er det aktuelle tekniske niveau i dag, er det ikke nødvendigvis om fem år. Vejledningen bruger to eksempler, der viser, hvorfor det betyder noget at forudse skiftet.
I det ene slår en sikkerhedsopdatering en forældet algoritme fra og aktiverer en stærkere, som produktet allerede understøttede. Det er ikke en væsentlig ændring, når risikovurderingen forudså udfasningen og byggede produktet til at kunne skifte. I det andet flytter fabrikanten nøglehåndteringen til en ekstern tjeneste hos en tredjepart. Det er en væsentlig ændring, fordi afhængigheder og datastrømme ændres.
For en gennemgang er spørgsmålet derfor, om produktet er bygget, så algoritmer kan udskiftes, og om risikovurderingen siger noget om, hvornår det skal ske. Det kaldes ofte kryptografisk smidighed.
Hvad gennemgangen gør
En almindelig fremgangsmåde er at sammenholde datakortet med en installeret kopi. Gennemgangen ser på, hvilke forbindelser der er krypterede, hvordan certifikater valideres, hvor nøgler ligger, og hvad der står i lokale filer. Den ser også i dokumentationen efter, hvordan en algoritme kan slås fra med en opdatering. Kryptering i organisationens egen drift er et emne for den almene sikkerhedsaudit, og de tekniske kontrolpunkter i driften hører til teknisk kontrol af kryptering.
Data, der forlader produktet
Fortrolighed handler også om det, softwaren sender videre. Fejlrapporter, diagnosepakker og eksportfiler kan indeholde data, ingen tænkte på som følsomme, da funktionen blev bygget. Vejledningen nævner som eksempel en ny log- og diagnosefunktion, der eksporterer detaljerede systemlogge og gemmer følsomme driftsdata ukrypteret, og som derfor kan være en væsentlig ændring. Når en gennemgang kortlægger data, tager den derfor også de veje med, hvor data forlader produktet ad en sidedør.
Hvad det kræver, og hvad det koster at lade være
Det kræver et kort over de data, softwaren håndterer, en vurdering af fortrolighed for hver datatype og et design, der kan skifte algoritme med en almindelig sikkerhedsopdatering.
Uden kortet bliver beskyttelsen ujævn, og uden smidigheden kan et algoritmeskift senere blive så stort, at det tæller som en væsentlig ændring med de følger, det har for overensstemmelsesvurderingen.
Det skal I lade være med
- At læse litra e som et krav om at kryptere alt · teksten bruger kryptering som eksempel.
- At bygge egen kryptografi, hvor platformen har en moden funktion · Kommissionens eksempel peger den anden vej.
- At låse produktet til én algoritme · supportperioden er lang, og niveauet flytter sig.
Det skal auditten kunne vise
- ☐ Et kort over data, softwaren gemmer, sender og behandler.
- ☐ En vurdering af fortrolighed pr. datatype i risikovurderingen.
- ☐ Beskrivelse af kryptering og nøglehåndtering, herunder hvad der hviler på platformen.
- ☐ En plan for udfasning af algoritmer, og hvordan skiftet kan ske med en opdatering.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, bilag I, del I, nr. 2, litra e, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 108-109, eksempel 48, 50 og 67, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Tegn et kort over de data, jeres produkt gemmer og sender, og markér, hvor kryptering bruges, og hvor den ikke gør.
- Bilag I, del I: softwarens egenskaber krav for krav
- Væsentlig ændring: de fire spørgsmål, hver release skal igennem
Læs også: Integritet · Dataminimering i softwaren
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
