Persondatabrud på 72 timer: de tekniske fakta, der skal være fastlagt

Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen

En anmeldelse af et brud på persondatasikkerheden skal efter databeskyttelsesforordningens artikel 33 ske uden unødig forsinkelse og så vidt muligt senest 72 timer efter, at den dataansvarlige er blevet bekendt med bruddet. Forordningen åbner for, at oplysninger kan gives trinvis, hvis ikke alt kendes. Den tekniske opgave i de første 72 timer er derfor ikke at have alle svar, men at have fastlagt et minimum af fakta, at kunne skelne mellem det, der er kendt, det, der er anslået, og det, der endnu er ukendt, og at dokumentere grundlaget for hvert punkt. Den juridiske vurdering af fristen og af, om der skal anmeldes, hører under rådgiverne, se også Erstatning efter persondatabrud.

Tidsplan, roller og den interne proces for virksomheden er beskrevet i Persondatabrud: dokumentationen inden for 72 timer. Her handler det om de tekniske fakta, anmeldelsen bygger på.

De tekniske spørgsmål bag anmeldelsen

En anmeldelse kræver typisk oplysninger om bruddets karakter, de berørte kategorier og det omtrentlige antal registrerede og registreringer, de sandsynlige konsekvenser, de foranstaltninger, der er truffet, og en kontaktperson. Datatilsynets anmeldelsesformular stiller en række mere detaljerede spørgsmål, og felterne kan ændre sig over tid. Bag hver af dem ligger et teknisk spørgsmål:

Hvornår skete bruddet? · Hvad er det tidligste og seneste spor?
Hvornår blev det opdaget? · Hvornår var der første gang konkret viden?
Karakter · Fortrolighed, integritet, tilgængelighed eller flere?
Kategorier og antal · Hvilke systemer og data var berørt, og hvor mange?
Var data beskyttet? · Kryptering, adgangskontrol, nøglers status
Er bruddet bragt til ophør? · Hvilke indgreb, hvornår, og virkede de?

Tidspunkterne

Hvornår blev den dataansvarlige bekendt med bruddet?

Det er et juridisk spørgsmål, men det hviler på tekniske fakta. Den tekniske dokumentation bør vise tidspunktet for den første alarm, den første henvendelse, den første bekræftelse af, at der var tale om et brud, og hvem der fik hvilke oplysninger hvornår. Kilderne er alarmsystemer, tickets, mails og indgrebsloggen. Hold tidspunkterne adskilt, så den juridiske vurdering kan foretages på et klart grundlag.

Hvornår skete bruddet?

Det tidligste og seneste spor efter uautoriseret adgang eller tab fastlægges med de metoder, der bruges ved enhver tidslinje, se Tidslinjeanalyse. Efter 72 timer er det ofte kun muligt at give et foreløbigt interval. Skriv det sådan, og angiv, hvilke kilder der endnu ikke er undersøgt.

Bruddets karakter

Et brud kan berøre fortrolighed (nogen uvedkommende har haft adgang), integritet (data er ændret) og tilgængelighed (data er utilgængelige eller tabt). Et ransomwareangreb kan berøre alle tre. Det tekniske grundlag for hver del er forskelligt:

Tilgængelighed dokumenteres ved, at data er krypteret eller slettet, og ved, om de kunne gendannes, og hvornår.
Integritet dokumenteres ved spor efter ændringer, fx i databasers auditlogs eller filers versionshistorik.
Fortrolighed er sværest. Den kræver spor efter adgang eller udtræk, og fravær af spor er ikke det samme som fravær af adgang. Se Dataudtræk før kryptering.

Omfang inden for 72 timer

Inden for 72 timer er det sjældent muligt at lave en præcis opgørelse af berørte registrerede. Det er til gengæld ofte muligt at give en øvre grænse og et realistisk interval:

Øvre grænse: Hvilke systemer og datasamlinger kunne den kompromitterede konto eller proces nå? Hvor mange registrerede indeholder de?
Bekræftet: Hvilke data er der konkrete spor af, at der er tilgået, ændret eller hentet?
Realistisk interval: En begrundet vurdering mellem de to.

Notér for hver datasamling, hvordan antallet er beregnet: et udtræk af antal rækker i en tabel, antal unikke mailadresser i en postkasse, antal filer i en mappe. Så kan tallet efterprøves og justeres. Den grundige afgrænsning, der typisk følger efter de 72 timer, er beskrevet i Hvilke persondata blev berørt?.

Var data beskyttet?

Om data var krypteret, er afgørende for vurderingen af konsekvenserne, men kræver præcision. Kryptering af en disk beskytter ikke data, der blev hentet fra et kørende system, hvor disken var låst op. Kryptering i en database beskytter ikke data, hvis angriberen havde en konto, der kunne læse dem i klar tekst. Dokumentér derfor, hvilken kryptering der fandtes, hvor nøglerne var, og om angriberen havde adgang på et niveau, hvor krypteringen ikke spillede en rolle.

Er bruddet stoppet?

Anmeldelsen spørger til de foranstaltninger, der er truffet. Det tekniske grundlag er indgrebsloggen: hvilke konti der er spærret, hvilke systemer isoleret, hvilke adgangskoder og nøgler skiftet, og hvornår. Endnu vigtigere er det at kunne vise, at indgrebene virkede, fx at der ikke er set aktivitet fra den kompromitterede konto efter spærringen. Se Log over indgreb under incident response.

Sikring i de første timer

De fakta, der skal leveres inden for 72 timer, kan kun fastlægges, hvis kilderne er sikret. Mange af dem har kort opbevaring. Prioritér derfor i de første timer, før analysen går i gang:

Logs fra de systemer, hvor data lå: auditlogs, databaselogs, filserverrevision og cloudtjenesters aktivitetslogs.
Loginlogs for de konti, der kan være kompromitteret.
Netværkslogs, der kan vise udgående trafik i perioden.
Konfigurationen af kryptering og adgangsstyring, som den var ved opdagelsen.

Beregn hashværdier af eksporterne, og notér, hvem der eksporterede hvad og hvornår. Når Datatilsynet eller de registrerede senere stiller spørgsmål, skal svarene kunne føres tilbage til de samme data, ikke til en ny eksport, der måske ser anderledes ud, fordi loggen er roteret.

Hvad der kan eftersendes

Det er normalt, at en første anmeldelse indeholder foreløbige oplysninger, og at der sendes supplerende oplysninger senere. Det tekniske arbejde bør derfor organiseres, så der ved 72 timer foreligger et dateret faktaark med tre kolonner: kendt, anslået og ukendt. Ved hver senere opdatering laves en ny version, så det kan ses, hvad der var kendt hvornår. Det beskytter både mod påstande om, at noget blev holdt tilbage, og mod, at foreløbige tal senere læses som endelige.

Fejl, der går igen

Antallet af berørte opgøres ud fra, hvad der er bekræftet, og ikke ud fra, hvad der kunne være berørt, uden at det fremgår.
Logs, der skulle afgøre omfanget, er ikke sikret og roterer, mens anmeldelsen forberedes.
Kryptering nævnes som en formildende omstændighed, selv om den ikke beskyttede mod den konkrete adgang.
Tidspunktet for opdagelse sættes til tidspunktet for ledelsens orientering, selv om tekniske alarmer lå tidligere.

Særlige brudtyper

Ikke alle brud er angreb. En fejlsendt mail, et forkert delt dokument eller en database, der har været åben mod internettet, kræver samme faktaark, men andre kilder. Ved fejlsendelse er message trace og delingslogs de primære kilder, se Fejlsendt mail og fejldeling. Ved en åben database er spørgsmålet, om adgangslogning var slået til, og om nogen faktisk tilgik data.

NIS2 og andre rapporteringer

Er virksomheden omfattet af NIS2, kan samme hændelse også skulle rapporteres efter de regler, med andre frister og andre spørgsmål. Det tekniske faktagrundlag er i vid udstrækning det samme, og det bør bygges, så det kan bruges til begge. Se NIS2: varsling og rapporter set fra logkilderne.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Forsikringstvist: dokumentation af sikkerhedsniveauet før hændelsen · Hvilke persondata blev berørt? Teknisk afgrænsning af et databrud

→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For DPO’er · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik