Skal I lave en DPIA før lanceringen?

Før en ny digital tjeneste lanceres, dukker spørgsmålet ofte op for sent: Skal vi lave en DPIA? En konsekvensanalyse vedrørende databeskyttelse er GDPR’s værktøj til at fange risici for privatlivet før de bygges ind, og for visse tjenester er den et lovkrav. Laves den i tide, er den en støtte der former en bedre tjeneste. Laves den for sent, bliver den en stresset formalitet. Denne guide hjælper dig med at afgøre om din tjeneste udløser kravet og hvordan du gennemfører analysen så den gør reel nytte.

De kriterier der udløser kravet

Grundreglen i GDPR er at en DPIA kræves når en behandling af personoplysninger sandsynligvis vil indebære en høj risiko for fysiske personers rettigheder og frihedsrettigheder. Det lyder abstrakt, men i praksis er der en række konkrete kriterier der vejer tungt, og jo flere der rammer, desto tydeligere er kravet.

• Følsomme oplysninger. Behandling af oplysninger om helbred, etnisk oprindelse, religion, seksuel orientering eller lignende særligt beskyttelsesværdige kategorier.
• Kortlægning og profilering. Systematisk vurdering af personer, f.eks. scoring, adfærdsanalyse eller automatiske afgørelser.
• Behandling i stort omfang. Store mængder oplysninger eller et stort antal registrerede.
• Overvågning. Systematisk overvågning af offentlige eller halvoffentlige områder.
• Sårbare grupper. Oplysninger om børn, patienter eller andre i et afhængighedsforhold.
• Ny teknologi. Løsninger hvis konsekvenser for privatlivet er svære at overskue på forhånd.

Rammer kun ét af kriterierne en smule, kan en enklere vurdering være nok. Kombineres flere, f.eks. en app der profilerer brugere i stort omfang eller en tjeneste med følsomme oplysninger om børn, er en DPIA næsten altid nødvendig. Er I i tvivl, er grundholdningen enkel: Lav en overordnet vurdering af risikoen, og lander den højt, så lav en fuld DPIA.

Processen trin for trin og hvem der skal med

En DPIA er ikke en enkelt blanket, men en gennemgang i flere trin. Målet er at forstå behandlingen, afveje dens risici og beslutte hvordan de mindskes. Alt sammen før noget bliver bygget.

1. Beskriv behandlingen. Hvilke oplysninger indsamles, hvorfor, hvordan flyder de, og hvor længe opbevares de?
2. Vurder nødvendighed og proportionalitet. Er alle oplysningerne virkelig nødvendige for formålet, eller kan der indsamles færre?
3. Identificer risiciene. Hvad kan gå galt for de registrerede: læk, misbrug, uønsket kortlægning?
4. Beslut foranstaltninger. Hvordan mindskes risiciene: færre data, kortere opbevaring, kryptering, strammere adgangsrettigheder?
5. Rådfør jer ved fortsat høj risiko. Hvis risikoen forbliver høj trods foranstaltningerne, skal tilsynsmyndigheden høres før start.

Lige så vigtigt som trinene er hvem der deltager. Den dataansvarlige leder arbejdet, databeskyttelsesrådgiveren giver råd og gennemgår, forretningen forklarer formålet, og de teknisk ansvarlige beskriver hvordan oplysningerne faktisk håndteres. Uden det tekniske perspektiv bliver analysen let et skrivebordsprodukt der ikke afspejler virkeligheden. En DPIA er heller ikke et engangsdokument: Ændres tjenesten væsentligt, skal den opdateres.

Sådan styrer resultatet designbeslutningerne

Det der adskiller en meningsfuld DPIA fra et skuffedokument, er hvornår den laves. Gennemføres den tidligt mens tjenesten stadig tegnes, bliver den et designværktøj. Gennemføres den efter at systemet er bygget, bliver den i bedste fald en bekræftelse af problemer som nu er dyre at rette.

En tidlig DPIA fører ofte til konkrete valg: Måske behøver I slet ikke at indsamle et bestemt felt, måske er pseudonymiserede data nok til formålet, måske skal opbevaringstiden forkortes eller adgangen begrænses hårdere. Den slags beslutninger er trivielle at træffe på tegnebrættet, men kostbare at bygge om bagefter. Det er selve tanken bag databeskyttelse gennem design: at beskyttelsen af privatlivet bygges ind i tjenesten fra begyndelsen i stedet for at blive lappet på til sidst. En udbredt misforståelse er at en DPIA bare er jura og papirarbejde. I virkeligheden er den en af de bedste lejligheder til at træffe klogere tekniske beslutninger, netop fordi den tvinger spørgsmålet “har vi virkelig brug for den her oplysning?” frem før koden skrives.

Et konkret scenarie

En organisation planlagde en tjeneste der skulle følge brugernes aktivitet over tid for at give personlige anbefalinger. Behandlingen indebar profilering i et vist omfang, og en overordnet risikovurdering landede højt. En fuld DPIA var begrundet, og den blev lavet før udviklingen gik i gang.

Analysen førte til flere designændringer. En del oplysninger som oprindelig skulle indsamles, viste sig at være unødvendige for formålet og blev strøget. Det der var brug for, blev pseudonymiseret, opbevaringstiden blev forkortet, og adgangen blev begrænset til nogle få roller. Ændringerne blev lavet på tegnebrættet uden omkostninger til ombygning. Var DPIA’en først blevet lavet efter lanceringen, havde de samme indsigter i stedet betydet at en færdig tjeneste skulle bygges om: dyrere, langsommere og med en periode med unødig risiko imellem.

Lav analysen i tide

En DPIA er ikke noget man skal skubbe foran sig til lige før lanceringen. Afgør tidligt om tjenesten udløser kravet, inddrag både jura, forretning og teknik, og lad konklusionerne forme designet mens det stadig er billigt. Så bliver analysen ikke en bremse, men en støtte der giver både bedre beskyttelse af privatlivet og klogere tekniske valg.

Hos Weapp bygger vi med databeskyttelse gennem design som udgangspunkt og bidrager gerne med det tekniske perspektiv i en DPIA som en del af vores ydelser. Planlægger I en tjeneste der håndterer personoplysninger? Kontakt os, så drøfter vi om en DPIA er nødvendig og hvordan den bedst væves ind tidligt i projektet.