Når uvedkommende har haft adgang til jeres systemer, er spørgsmålet, hvad de har set. Bevisbyrden ligger hos jer, og svaret findes i jeres logs eller slet ikke. Datatilsynet stiller fire betingelser, hvis logs skal kunne vise, at adgangen ikke er udnyttet. Kan I ikke leve op til dem, bør I tage afsæt i det værst tænkelige, og så bliver et brud, der måske var harmløst, til en anmeldelse og måske en underretning af alle berørte. Logs kan altså ikke købes bagefter. De skal være slået til, gemt og beskyttet, før noget sker.
Hvad en log betyder for vurderingen
En log er systemets notat om, hvem der gjorde hvad og hvornår. Efter et brud bliver den til bevis.
Vejledningen om brud fra maj 2025 bruger logs på tre måder. I eksempel 6 om ransomware er det logs, der kan dokumentere, at ingen har haft adgang til oplysningerne, og at intet er trukket ud. I eksempel 13 om for bred adgang afgør logs, om adgangen er brugt. Og i afsnit 3.2.6 kan I sænke risikoen ved et langvarigt brud, hvis I kan dokumentere, hvad der skete i perioden.
Har uvedkommende kunnet tilgå oplysninger, er der tale om uautoriseret adgang, uanset hvad loggen viser. Loggen påvirker det næste spørgsmål, nemlig om bruddet skal anmeldes.
De fire betingelser
Afsnit 3.7 i vejledningen beskriver, hvad der skal til, før en dataansvarlig kan bevise, at en uautoriseret adgang ikke er udnyttet. Omskrevet til spørgsmål lyder det sådan:
- Er loggen troværdig, og dækker den alle? Den skal registrere alles adgang til de pågældende data. Logger systemet kun administratorer, eller kun login uden læsning af filer, er der huller.
- Dækker den hele perioden? En log, der kun går en måned tilbage, kan ikke sige noget om en fejl, der har stået åben i et halvt år.
- Ved I, at den ikke er manipuleret? En angriber med administratorrettigheder kan ændre sporene, hvis loggen ligger samme sted som data.
- Viser den, at ingen uautoriserede har været inde? Det er først her, indholdet tæller.
Mangler ét led, står I i afsnit 3.2.5 i stedet: manglende viden øger den mulige risiko, og I bør regne med det værst tænkelige. Vejledningen peger selv på netværksovervågning og logning som det, der kan forhindre situationen. Dertil kommer tidsfristen. Kan I ikke undersøge følgerne inden for de 72 timer, vil det normalt betyde, at I ikke kan sige, at en risiko er usandsynlig.
Hvad det betyder i praksis
En tænkt situation: En ekstern konsulent har ved en fejl beholdt adgang til et fildrev med personalesager i otte måneder. Virksomheden opdager det ved en oprydning.
Med en log, der viser filadgang for hele perioden, og som ligger adskilt fra drevet, kan virksomheden se, at kontoen ikke er brugt. Den kan vurdere risikoen som lav, begrunde det og skrive det i brudloggen.
Uden den log står virksomheden med otte måneders uvished om personalesager. Hvis den ikke kan afklare det på anden vis, peger vejledningen på anmeldelse, og risikoen for de ansatte må vurderes ud fra det værste.
Forskellen ligger i et valg om opsætning, der blev truffet længe før.
Det, der skal være slået til
Datatilsynets katalog over foranstaltninger har en side om logning af brugernes anvendelser af personoplysninger, opdateret 20. oktober 2025. Siden siger, at behovet afgøres af en risikovurdering efter art. 32, og at risikoen stiger med mængden af oplysninger og antallet med adgang. Herfra kan vi læse fem krav, der er nyttige at holde op mod jeres systemer.
Hvad der logges. Al brug af personoplysninger: læsning, tilføjelse, søgning med søgekriterier, ændring, udtræk og sletning.
Fra hvornår. Logning bør være aktiv, senest når systemet går i drift, og slået til som standard efter art. 25.
Hvor den ligger. Sikkert, fx på en logserver, der er adskilt fra de privilegerede administratorer.
Hos hvem. I skal let kunne få logs fra databehandlere. Spørg, hvad leverandøren gemmer, og hvad I selv kan hente. Det gælder også skytjenester, hvor standardindstillinger kan være kortere end jeres behov.
Personhenførbart. Handlinger skal kunne knyttes til enkeltpersoner, så undgå fælles konti.
Spørg også, om logning er testet, og om nogen kan læse resultatet. Datatilsynet nævner test og vejledning i at tolke logs som tiltag.
Hvor længe logs skal gemmes
Der findes ingen fast frist. Datatilsynet siger, at perioden sættes efter formålet og er en konkret vurdering. Den hænger ofte sammen med, hvor tit adgange gennemgås: finder I en fejl, skal logs kunne gå mindst tilbage til forrige gennemgang. Undersøgelser af angreb eller mistanke om misbrug kan kræve længere tid.
Logs er selv personoplysninger. Der skal automatisk sletning til efter en fastlagt periode, jf. dataminimeringen i art. 5, stk. 1, litra c. Det er derfor en afvejning, og den skal skrives ned. Hvilke beslutninger ledelsen skal tage om opbevaring og adgang, står under logning som ledelsesbeslutning. Her er pointen, hvad der skal kunne bevises efter et brud.
En prøve, I kan lave nu
Vælg det system med flest følsomme oplysninger. Stil spørgsmålet: Hvis en konto havde haft for bred adgang i seks måneder, kunne vi så vise, hvad den har set? Lad IT finde svaret i praksis. Resultatet viser, om I står med en reel kontrol eller med en antagelse. DPO’en kan bede om den slags kontrol og rådgive om, hvor logning mangler, mens IT sætter den op.
Det skal I lade være med
- At regne med leverandørens ord · bed om at se en konkret log.
- At gemme logs sammen med data · en angriber kan ændre dem.
- At forlænge logperioden uden begrundelse · logs er også persondata.
- At vente med prøven · et brud er et dårligt tidspunkt at finde hullet.
Det skal I kræve af den eksterne
- ☐ Kontrol af, om logs lever op til de fire betingelser.
- ☐ En skriftlig begrundelse for perioden, logs gemmes.
- ☐ Afklaring af, hvad leverandørerne gemmer, og hvordan I får det.
- ☐ En prøve på, om et konkret spørgsmål kan besvares ud fra logs.
Kilder
- Datatilsynet: Håndtering af brud på persondatasikkerheden, maj 2025: eksempel 6 og 13, afsnit 3.2.5, 3.2.6 og 3.7.
- Datatilsynet: Logning af brugernes anvendelser af personoplysninger, opdateret 20. oktober 2025: læst 5. november 2026.
- Forordning (EU) 2016/679, dansk tekst: art. 5, stk. 1, litra c, art. 25, 32 og 33.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Ransomware som persondatabrud · Brudloggen
→ Kontakt · Tlf. 70 13 63 23 · Ekstern DPO hos Nielco IT