Er din app GDPR-sikker? Det er dit ansvar

Der er en misforståelse der kan blive dyr for dem der får udviklet en app: at GDPR er udviklerens problem. Sådan er det ikke. Den der ejer appen og bestemmer hvad den gør med brugernes oplysninger, er dataansvarlig, uanset hvem der har skrevet koden. Bureauet er din databehandler, ikke din ansvarsforsikring. Her er hvad ansvaret betyder i praksis, fra design til drift.

Dataminimering og retsgrundlag: pr. funktion, ikke pr. app

GDPR-arbejdet begynder ikke i en politik, men i funktionslisten. For hver funktion i appen skal to spørgsmål være besvaret:

• Hvilke personoplysninger har funktionen brug for, som minimum? Dataminimering betyder at man ikke indsamler “rart at have”-data. Kræver registreringen virkelig CPR-nummer, eller er e-mail nok? Har kortfunktionen brug for løbende placeringshistorik, eller kun positionen mens den bruges?
• Med hvilket retsgrundlag? Kernefunktioner bygger oftest på aftalen med brugeren. Markedsføring og tracking kræver normalt samtykke. Intern statistik kan bygge på legitim interesse forudsat at interesseafvejningen er foretaget og dokumenteret.

Lav det som en enkel tabel i kravspecifikationen: funktion, oplysninger, grundlag, opbevaringsperiode. Øvelsen tager en eftermiddag og tvinger beslutningerne frem mens de er billige. Den samme tabel bliver siden rygraden i din fortegnelse over behandlingsaktiviteter og i informationen til brugerne. En leverandør der får sådan en tabel, bygger desuden rigtigt fra start. Kravspecifikationen er det rigtige sted for databeskyttelse, ikke slutgodkendelsen.

Tredjeparts-SDK’er: den mest almindelige fælde

Den største GDPR-risiko i moderne apps er sjældent din egen kode, men de færdige byggeklodser. Analyseværktøjer, crashrapportering, pushnotifikationer, annoncenetværk og login-tjenester leveres som SDK’er der bages ind i appen, og flere af dem begynder at indsamle data i samme sekund som appen starter: enheds-id, IP-adresse, adfærdsdata.

Det gør dig ansvarlig for datastrømme du måske ikke engang kender til. Sådan tager du kontrollen:

1. Kortlæg. Kræv en liste over samtlige tredjeparts-SDK’er i appen med oplysning om hvilke data hvert SDK indsamler og hvor de sendes hen. Opdater listen ved hver større release.
2. Udfordr. Hvert SDK skal begrundes i et behov og ikke ligge der fordi “det plejer man at have”. Færre afhængigheder er desuden bedre teknik.
3. Kontrollér overførsler. Sendes data uden for EU/EØS, kræves der et gyldigt grundlag for overførslen. EU-hostede alternativer mindsker både risiko og papirarbejde.
4. Synkronisér med samtykket. Tracking-SDK’er må ikke aktiveres før brugeren har sagt ja. En almindelig fejl er at samtykkeboksen findes, men at SDK’erne allerede har nået at sende data. Det opdages let i en netværksanalyse og tager sig dårligt ud ved et tilsyn.

App-butikkerne stiller nu egne krav til deklaration af dataindsamling, så kortlægningen er nødvendig under alle omstændigheder. Gør den ordentligt én gang i stedet for sjusket to gange.

Brugerens rettigheder: byg dem, lov dem ikke

Retten til sletning, indsigt og tilbagetrækning af samtykke er ikke politiktekst. Det er funktionalitet der skal designes og testes som alt andet:

• Sletning. Hvad sker der konkret når en bruger sletter sin konto? Oplysningerne skal ud af produktionsdatabasen, kopierne og tredjepartstjenesterne, med definerede undtagelser (f.eks. regnskabsmateriale efter bogføringsloven) og dokumenterede slettefrister. “Vi deaktiverer kontoen” er ikke sletning.
• Indsigt. En bruger har ret til at få udleveret sine oplysninger. Manuel håndtering fungerer ved lav volumen, men den skal være beskrevet som en rutine: hvem gør hvad, og inden for hvilken frist (én måned er hovedreglen).
• Håndtering af samtykke. Samtykke skal være lige så let at trække tilbage som at give, og valget skal kunne ændres inde i appen uden at kræve en mail til supporten.

Et konkret scenarie: En bruger skriver “slet alt I har om mig”. Uden forberedelse bliver det en uges detektivarbejde på tværs af databaser, backups, analyseværktøjer og pushtjenester. Med et sletteflow bygget fra start er det et tryk på en knap og en bekræftelsesmail. Forskellen er designbeslutninger der kostede nogle timer i kravfasen.

GDPR som kvalitetskrav, ikke bremse

Håndteret rigtigt er databeskyttelse ikke noget der bremser appen. Det er de samme discipliner som god arkitektur: at vide hvilke data der findes, hvorfor, hvor de flyder hen og hvordan de slettes. Hos Weapp bygger vi apps med den holdning fra første skitse og hjælper gerne med at gennemgå kravene ud fra et databeskyttelsesperspektiv før udviklingen går i gang. Kontakt os, så tager vi en snak.