Privacy-by-Design Engineer

En Privacy-by-Design engineer sørger for, at persondata behandles forsvarligt i selve systemet. Ikke som et lag lagt ovenpå bagefter. Du arbejder i koden, datamodellen og infrastrukturen.

Rollen sidder tæt på udviklingsteams. Ofte i et platform-, sikkerheds- eller compliance-team. Du oversætter juridiske krav til tekniske løsninger, som udviklere kan bruge i praksis.

Typiske opgaver

• Gennemgå nye features for unødvendig indsamling af persondata
• Lave privacy threat modeling, typisk med LINDDUN-metoden
• Designe pseudonymisering, tokenisering og kryptering af følsomme felter
• Bygge opbevaringsfrister og automatisk sletning ind i databaser og batchjobs
• Automatisere svar på indsigts- og sletteanmodninger fra brugere
• Bygge samtykke- og cookiestyring, så brugerens valg slår igennem i hele systemet
• Levere den tekniske del af en konsekvensanalyse (DPIA)
• Fjerne persondata fra logs, testmiljøer og analysedata
• Vurdere leverandører og overførsel af data ud af EU

En almindelig arbejdsdag
Formiddagen går ofte med design review af en ny feature. Du stiller det samme spørgsmål igen og igen: hvorfor har vi brug for det felt? Efter frokost skriver du selv kode. Det kan være dynamisk maskering i et datawarehouse eller en regel i CI-pipelinen. Sidst på dagen forklarer du en DPO eller jurist, hvordan behandlingen reelt foregår teknisk.

En del af jobbet er at sige fra. Du er den, der beder teamet droppe et datafelt tre dage før release.

Hvor arbejder man?
Brancherne er dem med meget persondata. Sundhedstech, fintech og bank, forsikring, telebranchen, adtech og HR-tech. Regioner, kommuner og statslige styrelser ansætter også. Større SaaS-virksomheder har ofte et decideret privacy engineering-team.

Karriereveje
De fleste kommer fra en udviklerrolle eller fra it-sikkerhed. Derfra går vejen mod privacy architect, security architect eller teamlead for privacy engineering. Nogle skifter til DPO-rollen, hvis de vil tættere på juraen. Andre bliver selvstændige rådgivere for flere kunder.

Hvilken lovgivning dækker denne rolle?
Rollen findes primært på grund af artikel 25 i EU's databeskyttelsesforordning (GDPR). Den kræver databeskyttelse gennem design og gennem standardindstillinger. Artikel 32 stiller krav om passende tekniske sikkerhedsforanstaltninger, og artikel 35 kræver konsekvensanalyse ved høj risiko. Det Europæiske Databeskyttelsesråd har uddybet artikel 25 i retningslinjer 4/2019. Datatilsynet fører tilsyn i Danmark og udgiver vejledninger om blandt andet kryptering, logning og sletning. Arbejder du med onlinetjenester, gælder også cookiebekendtgørelsen, og udvikler du AI-systemer, kommer der krav fra EU's AI-forordning.

Der findes ingen dansk uddannelse, der hedder Privacy-by-Design engineer. Rollen bygger på to ben: softwareudvikling og databeskyttelse. Det første lærer du på skolebænken, det andet typisk på jobbet.

Den typiske vej

• Datamatiker på erhvervsakademi, 2,5 år. Adgangskrav er en gymnasial eksamen med matematik C eller en relevant erhvervsuddannelse.
• Professionsbachelor i softwareudvikling som overbygning, 1,5 år oven på datamatiker.
• Diplomingeniør i softwareteknologi, 3,5 år, blandt andet på DTU og SDU.
• Bachelor og kandidat i datalogi eller cybersikkerhed, i alt 5 år. Udbydes blandt andet på DTU, Aalborg Universitet, Aarhus Universitet og Københavns Universitet.

De fleste arbejder et par år som udvikler, dataingeniør eller sikkerhedsspecialist først. Privacy-delen kommer ovenpå.

Certificeringer
Faget kræver ingen autorisation. Men certificeringer fylder meget i jobopslag.

• CIPT fra IAPP er den mest direkte. Den er skrevet til teknikere, ikke jurister.
• CIPP/E fra IAPP dækker den europæiske databeskyttelsesret.
• CISSP fra ISC2 bruges bredt i sikkerhedsmiljøet.
• Lead implementer-kursus i ISO/IEC 27701, hvis du også skal bygge ledelsessystemet.

Alternative veje ind

• Backend- eller dataudvikler, der overtager privacy-opgaverne i sit eget team.
• It-sikkerhedsspecialist, der læser databeskyttelsesret oveni.
• DPO eller jurist med reel teknisk kunnen. Sjældnere, men det sker.
• Selvlært udvikler med portefølje og en CIPT-certificering.

Hvis du skal hyre en
Kig efter kode i cv'et, ikke kun paragraffer. En kandidat, der kan forklare forskellen på pseudonymisering og anonymisering, og som selv har bygget en sletterutine, er den rigtige. Datatilsynets vejledninger og ENISA's materiale om privacy by design bruges som fælles referenceramme i faget.

Værktøjskassen ligner en udviklers, plus et lag af privacy-specifikke redskaber.

Kode og platform

• Python, Java, Go eller TypeScript til selve implementeringen
• SQL og datamodellering i for eksempel PostgreSQL, Snowflake eller BigQuery
• Azure, AWS eller Google Cloud, med fokus på EU-regioner og datalokation
• Terraform og policy as code, for eksempel Open Policy Agent

Kryptering og adgang

• Nøglehåndtering i HashiCorp Vault, Azure Key Vault eller AWS KMS
• Row level security og dynamisk maskering direkte i databasen
• Biblioteker til tokenisering og hashing

Find og klassificér persondata

• Microsoft Purview, Amazon Macie eller Google Cloud DLP
• BigID eller Collibra i store datalandskaber

Anonymisering

• ARX Data Anonymization Tool til k-anonymitet
• Biblioteker til differential privacy, for eksempel OpenDP

Samtykke og governance

• OneTrust, Cookiebot eller Usercentrics til samtykke og cookies
• Skabeloner til DPIA og fortegnelser, ofte i et GRC-værktøj eller Confluence

Trusselsmodellering og test

• LINDDUN som metode, tegnet i OWASP Threat Dragon eller IriusRisk
• Semgrep, Snyk eller SonarQube til at fange persondata i koden
• OpenTelemetry og logværktøjer med filtrering af personoplysninger

Som rammeværk bruges typisk ENISA's rapporter om privacy by design og NIST Privacy Framework. Arbejder virksomheden også med ISO/IEC 27701, ligger meget af dokumentationen der.