DLP‑hændelser: hvad en DLP‑alarm dokumenterer

Forside › Netværk og logs · Gennemgået oktober 2026 · Af John Nielsen

En DLP-alarm (data loss prevention) dokumenterer, at en bestemt handling med bestemte data opfyldte betingelserne i en bestemt regel på et bestemt tidspunkt. Det er alt. Alarmen viser ikke, at data faktisk forlod organisationen, at handlingen var bevidst, eller at personen bag kontoen havde en bestemt hensigt. Som bevis er DLP-hændelser derfor et udgangspunkt for en undersøgelse, ikke en konklusion, og de skal sikres sammen med reglen, der udløste dem, og de spor, der kan bekræfte eller afkræfte forløbet.

Hvad ledelse og HR bør gøre, når alarmen går, er beskrevet på bevissikring-digitalt.dk. Her handler det om, hvad hændelsen teknisk indeholder, og hvordan den læses.

Hvordan DLP virker

DLP-produkter overvåger data på et eller flere steder:

Endpoint: handlinger på computeren, fx kopiering til USB, upload i browseren, udskrivning eller kopiering til udklipsholderen. Upload til AI-tjenester er et voksende eksempel; se Shadow AI.
Mail: udgående mails og vedhæftninger, typisk ved transporten.
Cloudlager og samarbejde: deling af filer, eksterne links og download.
Netværk: trafik gennem en proxy eller gateway.

En regel kombinerer typisk en betingelse for indhold med en betingelse for handling. Indholdet kan genkendes på mønstre som CPR-numre eller kortnumre, nøgleord, ordlister, fingeraftryk af kendte dokumenter, klassifikationsmærker eller maskinlæringsbaserede klassifikatorer. Handlingen kan være en mail til et eksternt domæne, en kopiering til flytbart medie eller en deling uden for organisationen. Reglen angiver også, hvad der skal ske: kun registrering, en advarsel til brugeren, blokering eller blokering med mulighed for at tilsidesætte med en begrundelse.

Felterne i en hændelse

Tidspunkt · Hvornår handlingen blev registreret. Kan være endpointets tid eller modtagetid.
Bruger og enhed · Konto og enhed, hvor handlingen skete. Viser kontoen, ikke personen.
Handling · Fx upload, kopiering, mail, print. Afhænger af, hvad agenten kan se.
Destination · Domæne, modtager, USB-enhed eller app. Kan være delvis eller generisk.
Fil eller objekt · Navn, sti, størrelse, evt. hashværdi. Ikke altid selve filen.
Regel og match · Regelnavn, hvilken betingelse der matchede, antal match og sikkerhedsniveau.
Udfald · Registreret, advaret, blokeret eller tilsidesat med begrundelse.

Udfaldet er særlig vigtigt. En blokeret handling betyder, at data efter produktets egen opfattelse ikke forlod systemet ad den vej. En tilsidesat advarsel betyder, at brugeren aktivt valgte at fortsætte, ofte med en indtastet begrundelse, som bør sikres ordret.

Falske positiver

DLP-regler er skrevet til at fange for meget hellere end for lidt. Typiske falske positiver:

tal, der ligner CPR-numre, fx ordrenumre, telefonnumre eller datoer,
nøgleord, der optræder i harmløs sammenhæng,
klassifikatorer, der rammer dokumenttyper bredt,
systemprocesser, synkronisering eller backup, der flytter filer og udløser endpointregler,
mails til egne datterselskaber eller samarbejdspartnere, der står som eksterne domæner.

Et match på en regel er derfor et spørgsmål, ikke et svar. Hver hændelse, der indgår i en sag, bør efterprøves: Indeholdt filen faktisk de data, reglen fandt, og var handlingen den, reglen beskriver?

Det, alarmen ikke viser

Hensigt. En alarm kan ikke skelne mellem en medarbejder, der sender en fil til sin private mail for at arbejde hjemme, og en, der tager kunder med sig. Den bredere metode står i Insider threat-undersøgelse.
Fuldstændighed. DLP ser kun det, reglerne og agenten dækker. En handling uden alarm kan være sket uden for reglernes rækkevidde, fx med fotografering af skærmen eller en kanal, agenten ikke overvåger.
Modtagelse. En upload, der er registreret, viser ikke, at filen blev gemt hos modtageren.
Indhold i sin helhed. Mange produkter gemmer kun et uddrag eller matchende tekst, ikke selve filen.

Om tolkningen af fravær, se Fravær af spor, og om skridtet fra spor til konklusion generelt, se Fra artefakt til konklusion.

Sikring

Eksportér hændelserne med alle felter i det mest komplette format, produktet tilbyder, ikke kun et skærmbillede af alarmen.
Sikr reglen i den version, der var aktiv på tidspunktet: betingelser, undtagelser, ordlister og klassifikatorer. Regler ændres ofte, og en senere version kan give et andet billede.
Sikr filen eller indholdet, hvis produktet har gemt en kopi eller et uddrag, og hent ellers filen fra kilden med versionshistorik.
Sikr den tilhørende aktivitet fra andre kilder: auditlog for filadgang, message trace for mails, proxy- eller firewalllogs for upload og USB-spor på endpointet.
Beregn hashværdier og registrér eksporten i kæden af ansvar.
Notér opbevaringen. DLP-hændelser opbevares efter produktets og licensens regler, og detaljer kan udløbe før selve alarmen. I Microsoft Purview viser aktivitetsoversigten fx kun de seneste 30 dage, mens alarmernes levetid følger organisationens politik for opbevaring af auditloggen.

Krydstjek med andre kilder

En DLP-hændelse bliver stærk, når den bekræftes af uafhængige spor:

For mail: transportens leveringsspor; se Message trace og transportlogs.
For cloudlager: download og deling i auditloggen; se Download og synkronisering i SharePoint og OneDrive.
For endpoint: filsystemets spor, USB-artefakter og browserhistorik.

Peger flere kilder på samme forløb, kan konklusionen formuleres med større sikkerhed. Peger de i forskellige retninger, skal uoverensstemmelsen forklares. Er der tale om en medarbejder, der er på vej ud, indgår DLP-hændelserne typisk i en bredere plan; se Data taget ved fratræden.

Brugerens begrundelse og advarsler

Mange DLP-løsninger viser brugeren en besked, når en regel rammer, og nogle kræver en begrundelse for at fortsætte. Både beskeden og begrundelsen er relevante beviser. Beskeden viser, hvad brugeren fik at vide på tidspunktet, fx at filen indeholdt fortrolige oplysninger. Begrundelsen er brugerens egen tekst og kan pege i begge retninger: et konkret arbejdsformål eller en standardformulering, der er indtastet for at komme videre. Sikr derfor både skabelonen for beskeden i den version, der var aktiv, og den indtastede tekst. Vær opmærksom på, at en bruger, der har fået mange advarsler for harmløse handlinger, kan have lært at klikke dem væk. Antallet af tidligere advarsler for samme konto og regel kan derfor være relevant for fortolkningen.

Mange hændelser på kort tid

En række alarmer i et kort tidsrum ser alvorlig ud i en oversigt, men kan have en enkel teknisk forklaring. Synkronisering af en hel mappe, flytning af et projekt eller en backup til et eksternt drev kan udløse hundredvis af hændelser på få minutter. Se derfor på mønsteret: Er det én handling på mange filer, eller mange selvstændige handlinger? Hvilken proces stod bag på endpointet? Svaret afgør, om forløbet ligner systemadfærd eller en bevidst udvælgelse af bestemte filer.

Persondata og proportionalitet

DLP-hændelser indeholder ofte uddrag af indhold, herunder persondata om tredjemand. Eksporten bør afgrænses til det relevante, og uddrag med følsomme data håndteres med samme omhu som andre beviskopier.

Dokumentation

Gem også en oversigt over, hvilke regler og kanaler der var aktive i perioden, og hvilke der ikke var. Det gør det muligt at vurdere, hvilke handlinger DLP-løsningen overhovedet kunne have registreret.

Rapporten bør angive produkt, version og overvågede kanaler, den aktive regel med dens betingelser, hændelsens rå felter, udfaldet, de efterprøvninger, der er foretaget, og de kilder, der bekræfter eller afkræfter forløbet. Konklusionen formuleres som det, hændelsen dokumenterer: at en handling matchede en regel. Hvad handlingen betød, kræver de øvrige spor.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Netværk og logs

Læs også: EDR-telemetri som bevis: opbevaring og eksport · TeamViewer- og AnyDesk-logs: fjernadgang i sporene

→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · 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