Databeskyttelse gennem design betyder, at hensynet til personoplysninger er bygget ind i produktet fra starten, og at de mest skånsomme indstillinger er standard. Reglen står i databeskyttelsesforordningens artikel 25, og den er rettet mod den dataansvarlige, som ofte er jeres kunde. Producenter af software er ifølge Det Europæiske Databeskyttelsesråd ikke direkte omfattet, men kunderne må kun behandle personoplysninger med systemer, hvor databeskyttelsen er integreret. For et softwarehus er det derfor et produktkrav. Tre steder giver oftest problemer: sletning, logs og testdata. Artiklen handler om teknikken. Roller og aftaler mellem parterne er et spørgsmål til jeres rådgiver.
Hvem har ansvaret?
Rollerne afhænger af, hvad I laver. For jeres egne kundekonti og markedsføring er I selv dataansvarlig, og så gælder artikel 25 jer direkte. For de oplysninger, jeres kunder lægger ind i produktet, er kunden som regel den dataansvarlige, og den skal kunne opfylde sine pligter med det, I har bygget. Rollen er forklaret i den dataansvarlige er virksomheden.
Databeskyttelsesrådets retningslinjer opfordrer producenter til at bruge deres ekspertise til at vejlede kunderne og opbygge tillid. Det er også et salgsargument, for den samme kunde spørger til det i sit spørgeskema om produktet.
Saml kun det, I skal bruge
Det enkleste felt at beskytte er det, der ikke findes. Spørg ved hver ny funktion: Hvilke personoplysninger kræver den, hvorfor, og hvor længe? Lad standardindstillingerne være de skånsomme. Giv kunden mulighed for at slå ekstra indsamling til, og lad den være fravalgt fra start. I praksis gennemgår I felterne i datamodellen og fjerner dem, ingen bruger.
Sletning pr. kunde
Sletning er ofte det, der er sværest at eftermontere, for data ligger flere steder end i hovedtabellen. Efter artikel 5, stk. 1, litra e, må personoplysninger ikke gemmes i identificerbar form længere end nødvendigt. Den dataansvarlige fastsætter og dokumenterer fristerne, og produktet skal kunne udføre dem.
Tegn et kort over, hvor en persons oplysninger kan ligge: hoveddatabase, filer, søgeindeks, cache, analyseværktøj, mail- og supportsystem, backup og logs. Tre krav bør så kunne opfyldes:
- Slet én person. Det skal ske uden at bryde andre data, og uden at en udvikler skal skrive et script til hver sag.
- Slet en hel kunde. Når en kunde stopper, skal hele kundens data kunne fjernes ud fra en samlet procedure. Kunden vil også have sine data med ud, se jeres SaaS skal kunne forlades.
- Vis, at det er sket. Sletning, der kører automatisk, skal kunne følges op, for fejl i et sletteprogram opdages ellers sent.
Har I forskellige frister for forskellige typer data, skal det stå i designet. Datatilsynet nævner, at nogle oplysninger skal gemmes efter anden lovgivning, fx bogføringsreglerne, mens andre kan slettes tidligere.
Backup
Datatilsynet mener, at personoplysninger skal slettes fra backup, hvis det er teknisk muligt. Går det ikke, skal I sikre, at oplysninger, der er slettet i det kørende system, også fjernes, hvis en backup genskabes. Det kan kræve en log over sletninger, og den log bør ikke indeholde direkte identificerbare oplysninger. Der kan fx stå, at en bestemt række blev slettet på et bestemt tidspunkt. Tænk det ind i gendannelsesøvelsen, for ellers kommer slettede oplysninger tilbage den dag, I får brug for backuppen.
Logs
Logs er til for at finde fejl og misbrug, og de kan selv indeholde personoplysninger. Der skal derfor også være frister for dem, og Datatilsynet angiver ingen fast længde. Fristen afhænger af formålet. Længere opbevaring kan være nødvendig for at undersøge angreb eller en konkret hændelse.
For teamet er reglerne enkle:
- Skriv ikke mere i loggen, end formålet kræver. E-mailadresser, tokens og hele forespørgsler hører sjældent hjemme dér.
- Sæt automatisk sletning op, så loggen ikke vokser for evigt.
- Beskyt loggen, og begræns adgangen, så de samme personer ikke kan rette i både system og log.
- Tjek eksterne overvågningsværktøjer. Det, der sendes dertil, er også data, I skal kende.
Datatilsynet anbefaler desuden, at systemer logger brugernes anvendelse af personoplysninger, og at logningen er slået til som standard fra idriftsættelsen. Større kunder vil spørge til det, se kravene om SSO og logning.
Testdata
En kopi af produktionsdatabasen til et udviklermiljø er bekvem, men Datatilsynet er klart: Personoplysninger har samme beskyttelse, når de bruges til test. Produktionsdata kan være velbegrundet i begrænset omfang, fx ved afsluttende integrationstest, eller når retvisende anonyme testdata er svære at lave. Tidligt i udviklingen bør det alene ske med få oplysninger til fejlsøgning.
Bruger I rigtige oplysninger, gælder tilsynets krav. Der skal være et behandlingsgrundlag, I må kun bruge det nødvendige, I skal fastsætte og dokumentere slettefrister, og testmiljøet bør som udgangspunkt have samme sikkerhed som produktionen, især om adgangsstyring, logning, sikker overførsel og opdateringer. Oplysninger, der alene er brugt til test, skal slettes, før løsningen går i produktion. Pseudonymisering, hvor navne og andre identifikatorer erstattes, er særlig relevant her.
Den bedste løsning er konstruerede testdata, som teamet kan genskabe automatisk. Det kræver et stykke arbejde én gang og sparer en vanskelig diskussion hver gang. AI-funktioner rejser det samme spørgsmål, se kundedata i AI-funktionen.
Det skal I lade være med
- At kopiere produktionsdata til udviklernes maskiner · brug konstruerede data.
- At behandle sletning som en senere opgave · den er dyr at eftermontere.
- At lade logs vokse uden frist · de kan selv rumme personoplysninger.
Det skal I kræve af den eksterne
- ☐ Et kort over, hvor personoplysninger ligger i produktet.
- ☐ En sletteprocedure pr. person og pr. kunde, som er prøvet.
- ☐ En plan for backup, der tager højde for sletning.
- ☐ Frister og automatisk sletning for logs.
- ☐ En regel for testdata, der gælder alle udviklere og leverandører.
Kilder
- Databeskyttelsesforordningen (EU) 2016/679: art. 5, stk. 1, litra e, art. 25 og betragtning 78.
- Det Europæiske Databeskyttelsesråd: Retningslinjer 4/2019 om artikel 25: anvendelsesområde og henstillinger til producenter.
- Datatilsynet: Testdata: personoplysninger ved udvikling og test.
- Datatilsynet: Sletning: frister, backup og logs.
- Datatilsynet: Logning af brugernes anvendelser: indhold og opbevaring.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Hvor ligger data? Det tekniske svar til kunden · Før kunden kræver en pentest af produktet
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
