Sager hos Datatilsynet: dokumentation fra IT‑siden

En sag hos Datatilsynet kan opstå på flere måder: efter en anmeldelse af et brud på persondatasikkerheden, efter en klage fra en registreret eller ved en undersøgelse, tilsynet selv indleder. Sagens forløb og virksomhedens forpligtelser over for tilsynet er advokatens område.

For advokaten med civile sager er der en ekstra grund til at interessere sig for den tekniske dokumentation: Det, der sendes til tilsynet, og det, tilsynet når frem til, kan senere få betydning i en tvist, fx om erstatning, om en databehandlers ansvar eller i en ansættelsessag. Denne artikel ser på dokumentationen fra IT-siden med begge formål for øje.

Ansvarlighed betyder dokumentation

Databeskyttelsesforordningen bygger på, at den dataansvarlige skal kunne påvise, at reglerne overholdes. I praksis betyder det, at påstande om sikkerhed skal kunne underbygges med dokumentation. “Vi har altid haft to-faktor-login” er en påstand. En eksport af indstillingerne og en log over, hvornår de blev ændret, er dokumentation.

Hvad virksomheden typisk bør kunne fremlægge

Overblik over behandlinger · Fortegnelse over behandlingsaktiviteter, systemoversigt, dataflow
Sikkerhedsforanstaltninger · Konfigurationer, politikker, adgangsstyring, opdateringsstatus, backup
Adgang til data · Rettighedsoversigter, logdata om login og adgang
Databehandlere · Databehandleraftaler, revisionserklæringer, leverandørens hændelsesrapporter
Brud på sikkerheden · Hændelseslog, tidslinje, berørte systemer og data, foranstaltninger
Sletning · Slettepolitik og dokumentation for, at den følges

Det er ikke nok, at dokumenterne findes. De skal afspejle det, der faktisk var gældende på det relevante tidspunkt. En politik, der beskriver krav om stærke adgangskoder, siger ikke i sig selv noget om, hvordan systemerne var sat op. Hvor det er muligt, bør politikken derfor understøttes af en teknisk eksport eller en log, der viser den faktiske opsætning. Gem dokumentationen med dato, og notér, hvem der har lavet den.

Tidspunktet er afgørende

En typisk faldgrube er, at virksomheden dokumenterer situationen, som den er i dag, og ikke som den var, da hændelsen skete. Efter et brud strammes sikkerheden ofte straks. Det er fornuftigt, men det betyder, at de nuværende indstillinger ikke viser, hvordan systemet var sat op før bruddet.

Sikr derfor:

Konfigurationer og indstillinger, som de var før ændringerne, fx via eksport, skærmbilleder med dato eller ændringslogs.
Logdata fra perioden omkring hændelsen, før de overskrives. → Logfiler og logrotation
En tidslinje over, hvornår hændelsen blev opdaget, hvornår den blev stoppet, og hvornår der blev handlet.
Dokumentation for, hvem der traf hvilke beslutninger og hvornår.

Det, der skrives til tilsynet, skal kunne holde

Oplysninger til Datatilsynet gives ofte under tidspres og mens hændelsen stadig undersøges. Det er forståeligt, men det skaber en risiko: En foreløbig vurdering kan blive stående og senere blive sammenholdt med virksomhedens forklaring i en tvist.

Gode principper fra IT-siden:

Skeln mellem det, der er konstateret, og det, der formodes. “Logdata viser adgang til mappen [x]” er en konstatering. “Der er ikke tegn på, at data er kopieret” er en vurdering, der afhænger af, hvilke data der er undersøgt.
Angiv grundlaget. Hvilke logs og systemer er undersøgt, og hvilke er ikke?
Opdatér, når billedet ændrer sig, og gem hver version af redegørelsen.
Brug samme tidszone og terminologi som i den tekniske dokumentation.

Gode og dårlige formuleringer

“Ingen data er blevet kompromitteret” · “På grundlag af de undersøgte logdata fra [system] for perioden [dato] til [dato] er der ikke fundet tegn på adgang til personoplysninger. Logdata fra [system] var ikke tilgængelige”
“Bruddet skyldtes en fejl hos leverandøren” · “Leverandøren har oplyst, at [hændelse]. Virksomheden har ikke selv kunnet efterprøve oplysningen”
“Alle medarbejdere har to-faktor-login” · “To-faktor-login var aktiveret for [antal] af [antal] konti den [dato], jf. eksport af indstillinger”

Den præcise formulering beskytter mod, at en udtalelse senere viser sig at være for bred.

Når sagen bliver til en civil tvist

Dokumentationen fra Datatilsynet-sagen kan få betydning i flere typer tvister:

Erstatningskrav fra registrerede, hvor omfang, årsag og virksomhedens sikkerhedsniveau er centrale spørgsmål. → Erstatning efter persondatabrud: digitale beviser
Krav mod en databehandler eller IT-leverandør, hvor fordelingen af ansvar afhænger af, hvad hver part gjorde. → Leverandøren blev hacket
Ansættelsessager, hvis en medarbejders handlinger indgår i hændelsen.
Forsikringssager, hvor dokumentationen for hændelsen ligger til grund for dækningen.

Hvilken betydning tilsynets afgørelse kan få i en senere sag, er et juridisk spørgsmål. Fra IT-siden er pointen enkel: Den samme tekniske dokumentation bør kunne bruges begge steder, og den bør være sikret, så den kan efterprøves.

Databehandlerens dokumentation

Mange hændelser sker hos en databehandler, fx en hostingleverandør eller en leverandør af et fagsystem. Den dataansvarlige er da afhængig af leverandørens oplysninger, både over for tilsynet og i en eventuel senere tvist med leverandøren.

Bed tidligt om:

Leverandørens hændelsesrapport og tidslinje.
Logdata, der vedrører virksomhedens data og konti.
Oplysning om, hvilke sikkerhedsforanstaltninger der var aktive.
Bekræftelse af, at relevante data bevares.

Gem leverandørens svar som originale mails eller dokumenter med dato. Hvis leverandørens oplysninger senere ændrer sig, kan det være relevant at kunne vise, hvad der blev oplyst hvornår.

Hvem laver dokumentationen?

Den tekniske dokumentation laves ofte af virksomhedens egen IT-afdeling eller IT-leverandør. Det er naturligt, men det kan give et troværdighedsproblem, hvis samme leverandør har ansvar for den sikkerhed, der undersøges. Overvej, om en uafhængig gennemgang er relevant, især hvis en senere tvist med leverandøren er sandsynlig. → Uvildighed hos IT-sagkyndige

Registreredes klager

Når sagen starter med en klage fra en registreret, fx over manglende svar på en indsigtsanmodning, er dokumentationen ofte mere afgrænset: Hvornår kom anmodningen, hvem modtog den, hvad blev der søgt i, og hvad blev udleveret? Gem selve anmodningen som originalfil, notér søgningerne, og bevar en kopi af svaret. → Indsigtsanmodning efter GDPR som led i en tvist

Spørgsmål til klienten

Hvem opdagede hændelsen, hvornår, og hvordan er det registreret?
Hvilke indstillinger er ændret siden, og findes der en eksport eller ændringslog fra før?
Hvor længe gemmes logdata i de berørte systemer, og er opbevaringen forlænget?
Hvilke oplysninger er allerede sendt til tilsynet, berørte personer eller forsikringsselskabet, og hvem har skrevet dem?
Er der aftalt noget med leverandøren om bevarelse af data og udlevering af logs?
Findes der interne mails eller chats om hændelsen, som kan indeholde vurderinger, der afviger fra den officielle redegørelse?

Det sidste spørgsmål er ubehageligt, men vigtigt. Interne drøftelser skrevet i de første timer efter en hændelse er ofte mere skråsikre end den senere tekniske gennemgang. Advokaten bør kende dem, før der tages stilling til, hvad der skal fremlægges, og hvordan forskellen mellem første indtryk og senere konstateringer forklares.

Typiske fejl

Indstillinger ændres efter et brud, uden at den tidligere opsætning er dokumenteret.
Logdata overskrives, mens virksomheden venter på leverandørens svar.
Foreløbige vurderinger formuleres som endelige konklusioner.
Leverandørens oplysninger gengives som egne konstateringer.
Der findes flere versioner af tidslinjen, som ikke stemmer overens.