Der er kun en lille måned til Persondataforordningen eller ‘GDPR’ træder i kraft, og vi er derfor i fuld gang med at implementere de værktøjer, som gør det muligt for ‘Data subject’ at udøve sine 8 rettigheder. Du kan læse mere om disse rettigheder i mit tidligere blogindlæg “GDPR: Hvordan håndterer vi samtykke i apps?“.
“For at være i tråd med loven skal man sikre sig, at man varetager brugernes otte fundamentale rettigheder.”
Men hvordan gør man egentlig det? I denne artikel vil jeg prøve at komme med et bud på, hvordan de kan sikres. I mange tilfælde gør vi allerede en stor del af dét, som Persondataforordningen nu kommer til at sætte som krav, men det er stadig vigtigt, at der laves et tjek på de løsninger, som håndterer persondata, så vi ikke overtræder loven.
Information
I blogindlægget “GDPR: Hvordan håndterer vi samtykke i apps?” kan du læse om, hvordan man sikrer, at brugerens rettighed “information” implementeres og overholdes. Derfor vil jeg blot knytte en ekstra kommentar til denne, som omhandler dét at give sit samtykke eller ‘Consent’ til f.eks GPS-positionering, kamera, mikrofon (osv.), som vi jo så ofte gør i apps. Samtykke til disse features gives først, når vi som udvikler skal bruge adgang til funktionen, som derfor typisk ikke en del af signup-flowet.
Hvis du har brug for GPS i din app, skal du nu være meget mere tydelig omkring hvorfor, hvordan og i hvilket omfang featuren skal bruges. I min optik er det ikke længere nok blot at få standard-dialogen fra iOS – den skal helst have en forudgående forklaring, gerne med en simpel tegning, og noget medhørende tekst. Dette gælder også, når vi ønsker adgang til f.eks mikrofonen. Brugeren skal oplyses om hvorfor, hvordan og i hvilket omfang den skal bruges.
Access
Brugeren skal have adgang til sine data. Det gør du ved at oprette en brugerprofil inde i appen, hvor du til enhver tid kan hente data på brugeren.
Rectification
Brugeren har ret til opdaterede data. Det kan du sørge for på samme måde som forrige punkt – nemlig via brugerprofilen. Det vil dog ikke være hensigtsmæssigt at lade brugeren ændre oplysninger, som har konsekvenser for dem, f.eks. størrelsen på et lån – det vil normalt skulle igennem en juridisk procedure.
Erasure
Brugeren har ret til at blive glemt. Et af de store emner i GDPR er retten til at blive glemt. Det er ikke altid nemt at slette en bruger i visse databasesystemer, og det er derfor helt ok at overskrive en brugers persondata med anonymiseret information, f.eks. XXX.
Husk, at en bruger kun har krav på at få slettet data, som du ikke ved lov er bundet af, og som er direkte personhenførbart. Brugeren har heller ikke ret til at få slettet afledt data, f.eks. lister over produkter som brugeren kunne være interesseret i.
Restriction of processing
Brugeren har ret til begrænset databehandling. En bruger har ret til at gøre indsigelse mod, at dennes data bruges. Men okay, det er måske ikke noget, som direkte skal håndteres i din app. Her vil man blot skulle kunne udøve sin ret ved at komme i kontakt med dig (f.eks. via en kontaktformular) og påråbe sig retten.
Notification obligation
Brugeren har ret til at få besked om sikkerhedsbrist. Hvis en brugers persondata kan have været kompromitteret, skal denne have besked. Det vil man nok typisk gøre via email eller en anden mere holdbar løsning, men teknisk set kunne det godt gøres via en push-besked.
Data portability
Brugeren har ret til at få sine data udleveret. Brugeren har ret til flytning og download af data samt udlevering i et maskinlæsbart format, f.eks. json eller xml. I nogle tilfælde kunne man godt implementere en ‘send mig mine data’-knap. Det ville i hvert fald være god kundeservice, så man ikke skal igennem en standard support-procedure.
Object
Brugeren har ret til at frabede sig information. Hvis du sender information til en bruger, som denne ikke har bedt om, så har han/hun rettet til at sige stop – og du skal således øjeblikkeligt stoppe. I dag gør vi det typisk via ‘unsubscribe links’, men faktisk kan brugeren opnå det samme ved blot at sende dig en e-mail.
Not to be subject to a decision solely based on a automated process
Brugeren har ret til en person bagved automationer. I dit oprettelses-flow er det vigtigt, at en bruger ikke får taget en beslutning med konsekvenser om denne udelukkende baseret på indtastede informationer. Du må således ikke bare sætte prisen op på en police på baggrund af f.eks. et indtastet postnummer. Det betyder at dit flow skal være indrettet sådan, at disse beslutninger følges op af en person. Ved tilbud om f.eks. forsikringer vil man kunne indrette processen således, at brugeren modtager et tilbud med prisen (baseret på postnummeret), men tilbudet først konventeres til en kontrakt efter en medarbejder har talt med brugeren.
Er jeg så “complient”?
Det korte svar: Nej. Men din løsning lever sikkert op til de fleste af reglerne allerede, så nu skal du bare have styr på det sidste.
“Med ovenstående på plads er du ret godt på vej, men GDPR er ikke blot et spørgsmål om din app.”
Det drejer sig om din virksomhed som helhed og de tiltag, politikker og procedurer du sætter i værk. Du skal kunne bevise over for datatilsynet, at du har kontrol over din data – både den du selv behandler, men i lige så høj grad den som dine leverandører arbejder med. Det stiller nogle ret store krav til hvilke leverandører og samarbejdspartnere, du kan arbejde sammen med.
Hvad gør jeg så?
Du skal iværksætte et ‘DPMS’ eller ‘Data Protection Management System’. Systemet består af fem faser som omfavner alt fra analyse over implementering til evaluering. Læs mere om DPMS i bogen “Data Protection and Privacy Management System“. Der findes allerede mange DPMS’er på markedet, så du ikke behøver at sætte det hele op selv.
GDPR og DPMS kan virke uoverskueligt, men når først man går i gang, er det faktisk ikke så kompliceret. Tag udgangspunkt i de otte rettigheder og sørg for at sikre, at du kan levere på alle rettighederne, hvis en bruger skulle vælge at udøve dem.
GDPR lægger op til, at tingene skal have proportionalitet, så omfanget af hvor meget eller hvor lidt lige netop din virksomhed har brug for, afhænger helt af hvilken situation du er i. Den lille håndværker behøver ikke, at køre et fuldskala DPMS, mens et hospital som behandler særlig sensitiv data, typisk er tvunget til at gå hele vejen.
Har du brug for hjælp til dit projekt så tag gerne fat i mig.
