Persondata ligger sjældent kun i “systemet”. I praksis gemmer det sig i driftens spor, som små brødkrummer efter helt normale handlinger: en login-fejl, en support-sag, en backup, en chatbesked, en udskrift.
Hvis du har ekstern IT service, eller du selv står for netværk, WiFi og daglig drift, er det her vigtigt, fordi driftssystemer tit har bred adgang og lang historik. Det er også her, læk sker, når nogen “bare lige” eksporterer en liste, tager et screenshot eller logger hele request payloaden.
Målet er ikke at gøre alt tungt. Målet er GDPR IT-drift med styr på hvor data lander, hvem der kan se det, og hvornår det forsvinder igen.
De 10 skjulte datalagre i driften (og hvad du gør ved dem)
Logfiler (OS, firewall, apps)
Syslog, Windows Event Logs og applikationslogs kan indeholde brugernavne, IP-adresser, e-mail, telefonnumre og i værste fald CPR. Faldgruben er “log hele payloads” ved fejl. Løsning: log kun nødvendige felter, slå debug fra i drift, og brug maskering (redaction) før logs ryger i SIEM.Backups, snapshots og “glemte” restore-punkter
Backups er en tidsmaskine, også for data du troede var slettet. Snapshots på VM’er, NAS-replikering og cloud-backup kan bevare gamle persondata længe. Løsning: sæt retention pr. backup-job, dokumentér sletteflow (også for offsite-kopier), og test at sletning faktisk slår igennem ved restore.Monitoring og observability (APM, traces, Kubernetes logs)
APM og distributed tracing kan opsamle headers, cookies, querystrings og fejlstacktraces. I Kubernetes ser man ofte, at en pod logger hele request body ved 500-fejl. Løsning: slå “capture body” fra, scrub felter som email/telefon, og begræns adgang til observability-værktøjer på samme måde som produktionsdata.Ticketsystem og support-noter
Sager ender med screenshots af mail, lønsedler, pas, eller bare en hel skærm med kundedata. Noter kan også være mere følsomme end selve systemet. Løsning: indfør en “ingen persondata i fritekst” regel, brug skabeloner, og giv support en enkel rutine for at sløre eller slette vedhæftninger.E-mail, delte postkasser og vedhæftninger
E-mail er ofte virksomhedens største ustrukturerede arkiv. Delte postkasser og auto-forwarding gør det svært at styre, hvor data ender. Løsning: brug retention og etiketter i M365 eller Google Workspace, og aftal at følsomme bilag skal ligge i et styret dokumentområde, ikke i indbakken. Hvis I bruger Microsoft 365, kan et samlet setup og politikker typisk hænge sammen med jeres GDPR-venlig e-mail og samarbejdsværktøjer.Chat, Teams, Slack og “hurtige beskeder”
Chat føles som en samtale, men det er lagring. Folk deler CPR i en Teams-tråd, eller sender en kundeliste som fil “for en sikkerheds skyld”. Løsning: sæt chat-retention, begræns gæsteadgang, og gør det nemt at dele sikkert (links med adgangsstyring i stedet for filer i tråden).Cloud storage og shadow IT
SharePoint, OneDrive, Google Drive og Dropbox-lignende tjenester kan have deling ud af huset, gamle links og mapper uden ejer. Shadow IT dukker op, når en afdeling “bare lige” opretter et nyt SaaS-værktøj. Løsning: kør regelmæssig delings-rapport, kræv godkendelse af nye SaaS, og følg Datatilsynets råd om leverandørstyring i cloud, se Datatilsynets vejledning om cloud.IAM, AD og HR-provisioning metadata
Brugeroprettelser, adgangsgrupper, “manager”-felter og audit trails kan afsløre ansættelsesforhold, fratrædelser og interne roller. Løsning: minimer HR-felter der synkroniseres, sæt separate admin-roller, og gennemgå adgangsgrupper som en fast drift-opgave. Fysisk adgang er også persondata, og her giver Salto Smart Access, effektiv nøgleadministration en god anledning til at tænke retention og adgang i adgangslogs.Endpoints: MDM, browser cache og temp-filer
Bærbare pc’er gemmer mere end man tror: autofill, downloads, Teams-cache, OneDrive sync og midlertidige eksportfiler. Løsning: MDM-politikker for kryptering, skærmlås og sletning ved fratrædelse, plus en enkel politik om “ingen lokale eksportfiler”, når data kan ligge sikkert centralt.Print, scan og multifunktionsprintere
MFP’er har ofte harddisk og joblogs, og “scan-to-mail” skaber nye kopier. Løsning: slå lagring fra hvor muligt, sæt admin-adgang stramt, og planlæg sletning ved service eller udskiftning.
Retention som driftværktøj, ikke kun jura
Retention handler om at vælge en standard, så driften ikke ender som “gem alt for en sikkerheds skyld”. Brug det som startpunkt, og justér efter behov, lovkrav og risiko (fx bogføring, ansættelsesret eller igangværende sager).
| Datatype i driften | Startpunkt for retention | Drift-nært tip |
|---|---|---|
| SIEM/sikkerhedslogs (firewall, auth) | 90 dage aktivt, op til 12 mdr. arkiv | Split “hot” og “cold”, begræns søgeadgang |
| Applikationslogs | 30 til 90 dage | Maskér felter, drop request body |
| Kubernetes/containers logs | 14 til 30 dage | Centraliseret logning, undgå debug i prod |
| Ticketing-sager | 12 til 24 mdr. | Slet vedhæftninger, brug skabeloner |
| 24 til 36 mdr. | Retention policies, undgå PST-arkiver | |
| Chatbeskeder | 90 til 180 dage | Undtag kun udvalgte teams/projekter |
| Backups (daglige) | 30 dage | Sørg for sletning også på offsite |
| Backups (månedlige) | 12 mdr. | Kryptering og adgangsstyring pr. job |
| Print/scan joblogs | 7 til 30 dage | Ryd ved service, begræns admin-login |
To klassiske faldgruber: eksportfiler (CSV/Excel) der bliver liggende i “Downloads”, og testmiljøer der får en kopi af produktion “for at spare tid”. Begge dele kræver faste rutiner, ikke gode intentioner.
Mini data discovery i praksis (og to korte cases)
Når man skal finde persondata i IT-drift, virker det bedst at starte der, hvor data flytter sig og kopieres.
- Start med driftens centrale knudepunkter: SIEM/logserver, backup-platform, ticketing, M365/Google Workspace, samt endpoint-management.
- Lav en kort “hvad kan indeholde persondata?” liste: logs, vedhæftninger, exports, dumps, chats, delte drev, printere.
- Spørg leverandører konkret: Hvilke datatyper? Hvor lagres de (region)? Hvem er underdatabehandlere? Hvordan slettes data (inkl. backups)? Er der tredjelandsoverførsel via support eller SaaS?
- Tjek adgang i praksis: Hvem kan søge i SIEM? Hvem kan se tickets? Hvem kan genskabe backups?
- Dokumentér i fortegnelsen (art. 30): system, formål, kategorier, modtagere, retention, sikkerhedsforanstaltninger, og ansvarlig kontakt. For skabeloner og nationalt materiale kan du finde indgange via EDPBs Danmark-side med ressourcer.
Case 1, dansk håndværksvirksomhed (35 ansatte)
En support-sag om lønindberetning endte med screenshots af CPR og lønoplysninger i ticketsystemet. Sagen blev senere eksporteret til Excel til “overblik” og lå på en fælles mappe. Løsningen blev en simpel regel: bilag uploades kun til et styret område med adgang, tickets må kun indeholde reference og sagsnummer, og vedhæftninger slettes efter 30 dage.
Case 2, lokal virksomhed med webapp i Kubernetes
Ved fejl loggede API’en hele request body, inklusive kunders adresser og telefonnumre. Logs røg i en central syslog og videre i SIEM med 12 måneders retention. Løsningen: ændret logging (kun ID’er), redaction i logpipeline, 30 dages app-log retention, og adskilt adgang til driftlogs og fejlsøgning.
Konklusion: gør det lille, der virker hver dag
De mest oversete steder er sjældent “hackermål”, de er bare driftens vaner: logs, tickets, backups, exports og chats. Start med at kortlægge de 10 steder, sæt retention, og stram adgang, så data ikke lever evigt i skyggen. Når først rutinerne sidder, bliver GDPR IT-drift mindre noget man frygter, og mere noget man styrer. Hvor ville det være mest oplagt at starte hos jer, SIEM, backup eller tickets?
