Software skal levere sikkerhedsrelaterede oplysninger ved at registrere og overvåge relevante interne aktiviteter, og brugeren skal kunne fravælge det. Kravet er litra l i bilag I, del I, nr. 2. Fra 11. december 2027 er en sikkerhedslog derfor en egenskab ved produktet, som fabrikanten skal kunne dokumentere.
Hvad en kunde ønsker af revisionsspor i sin egen drift, er et andet spørgsmål. Her er det lovkravet til selve produktet og efterprøvningen af det.
Ordlyden
Litra l kræver, at produktet leverer sikkerhedsrelaterede oplysninger ved at registrere og overvåge relevante interne aktiviteter, herunder adgang til eller ændring af data, tjenester eller funktioner, med en fravalgsmekanisme for brugeren.
Tre led er værd at skille ad:
- Registrere og overvåge. Det rækker ud over at skrive en fil. Overvågning antyder, at nogen eller noget kan bruge oplysningerne.
- Relevante interne aktiviteter. Teksten nævner adgang til og ændring af data, tjenester og funktioner som eksempler. Hvad der ellers er relevant, afgøres i risikovurderingen.
- Fravalg for brugeren. Brugeren skal kunne slå registreringen fra.
Som ved de øvrige punkter er det risikovurderingen, der viser, hvordan kravet passer til produktet.
Hvad kilderne ikke siger
Hverken forordningen eller Kommissionens vejledning siger, hvor længe logge skal gemmes, eller præcis hvilke hændelser der skal registreres. Og der var i november 2026 ikke kommet en harmoniseret standard, der giver svaret. Vi sætter derfor ingen tal på. Den, der lover en bestemt opbevaringstid som CRA-krav, har ikke belæg i teksten.
Det betyder ikke, at alt er frit. Risikovurderingen skal begrunde, hvad produktet registrerer, og hvorfor det er nok til at levere sikkerhedsrelaterede oplysninger. En begrundelse kan for eksempel tage udgangspunkt i de trusler, vurderingen allerede har beskrevet. Står der i vurderingen, at stjålne adgangsoplysninger er en væsentlig risiko, er det naturligt, at mislykkede og usædvanlige login bliver registreret. Står der, at uautoriserede ændringer af konfigurationen er en risiko, bør de ændringer kunne ses bagefter. Sammenhængen mellem trusler og logning er vores forslag til, hvordan valget kan gøres efterprøveligt.
Kommissionens eksempler
Vejledningen nævner sikkerhedsrelevante logposter eller alarmer ved unormal adfærd som eksempel på en foranstaltning i produktet mod risici fra systemer uden for det. Det er et eksempel, ikke et krav.
Vejledningen viser også den anden side. En ny funktion til log og diagnose, der eksporterer udførlige logge og gemmer følsomme driftsdata ukrypteret, kan efter Kommissionens eksempel være en væsentlig ændring. Logningen kan altså selv skabe risiko. Indholdet skal vurderes efter kravene om fortrolighed i litra e og dataminimering i litra g.
Hvad en gennemgang ser efter
Et forslag til kontrolpunkter følger. Listen er vores tolkning af ordlyden og ikke en opremsning fra forordningen.
- Registreres vellykkede og mislykkede login?
- Registreres ændringer af rettigheder, konfiguration og sikkerhedsindstillinger?
- Registreres adgang til følsomme data eller funktioner?
- Kan logposterne ændres eller slettes af den, de handler om?
- Indeholder logposterne adgangskoder, tokens eller andre data, der ikke burde stå der?
- Kan oplysningerne hentes ud eller sendes videre, så de kan overvåges?
Fravalget
Fravalget er den del af litra l, der oftest mangler. Teksten kræver en fravalgsmekanisme for brugeren. En gennemgang ser på, om den findes, om brugeren kan finde den, og hvad der sker, når den bruges.
Det sidste er vigtigt. Slår fravalget al registrering fra, også den, produktet bruger til at melde mulig uautoriseret adgang efter litra d? Eller slår det kun den udvidede registrering fra? Forordningen siger ikke, hvordan det skal afvejes. Vores tolkning er, at risikovurderingen bør beskrive, hvad fravalget omfatter, og hvad brugeren mister ved at bruge det, og at brugeroplysningerne bør sige det samme.
Prøven i en installeret kopi
En almindelig fremgangsmåde er at udføre en række handlinger i en installeret kopi, for eksempel et mislykket login, en ændring af en rettighed og en ændring af en konfiguration, og derefter se, om handlingerne er registreret, og hvordan. Bagefter bruges fravalget, og prøven gentages. Gennemgangen noterer også, om logposterne indeholder data, der ikke burde være der.
Prøven er praksis. Hvordan kundens egen drift bruger logge og overvågning, hører under teknisk kontrol af logning i driften.
Hvad det kræver, og hvad det koster at lade være
Det kræver en beslutning om, hvilke aktiviteter produktet registrerer, begrundet i risikovurderingen, en måde at hente oplysningerne ud på, et fravalg, der er beskrevet og afprøvet, og en vurdering af, at logningen ikke selv skaber nye risici.
Uden det kan hverken I eller kunden se, hvad der skete, når noget går galt. Det gør også jeres egen sårbarhedshåndtering sværere, fordi der ikke er spor at følge.
Det skal I lade være med
- At love en bestemt opbevaringstid som lovkrav · forordningen nævner ingen.
- At skrive adgangskoder og tokens i logposterne · logningen skal også leve op til litra e og g.
- At gemme fravalget i en fil, kun udviklerne kender · fravalget er en mekanisme for brugeren.
Det skal auditten kunne vise
- ☐ En liste over de aktiviteter, produktet registrerer, med begrundelse i risikovurderingen.
- ☐ Resultat af en prøve i en installeret kopi med og uden fravalg.
- ☐ En beskrivelse af, hvad fravalget omfatter, også i brugeroplysningerne.
- ☐ En vurdering af logposternes indhold efter litra e og g.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, bilag I, del I, nr. 2, litra d, e, g og l, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 169 og eksempel 45, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Lav et mislykket login og en rettighedsændring i en testinstallation, og se, hvad jeres produkt har registreret.
Læs også: Dataminimering i softwaren · Integritet
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
