Er appen din GDPR-sikker? Dette er ditt ansvar

Det finnes en misforståelse som koster dem som bestiller apper dyrt: at GDPR er utviklerens problem. Slik er det ikke. Den som eier appen og bestemmer hva den gjør med brukernes opplysninger, er behandlingsansvarlig, uansett hvem som har skrevet koden. Byrået er databehandleren din, ikke ansvarsforsikringen din. Her er hva ansvaret betyr i praksis, fra design til drift.

Dataminimering og behandlingsgrunnlag: per funksjon, ikke per app

GDPR-arbeidet begynner ikke i en policy, men i funksjonslisten. For hver funksjon i appen skal to spørsmål ha svar:

• Hva er det minste funksjonen trenger av personopplysninger? Dataminimering betyr at du ikke samler inn «greit å ha»-data. Trenger registreringen virkelig fødselsnummer, eller holder det med e-post? Trenger kartfunksjonen kontinuerlig posisjonshistorikk, eller bare posisjonen mens den brukes?
• Med hvilket behandlingsgrunnlag? Kjernefunksjoner bygger oftest på avtalen med brukeren. Markedsføring og sporing krever normalt samtykke. Intern statistikk kan bygge på berettiget interesse, forutsatt at interesseavveiingen er gjort og dokumentert.

Sett dette opp som en enkel tabell i kravspesifikasjonen: funksjon, opplysninger, grunnlag, lagringstid. Øvelsen tar en ettermiddag og tvinger frem beslutningene mens de er billige. Den samme tabellen blir deretter ryggraden i protokollen over behandlingsaktiviteter og i informasjonen til brukerne. En leverandør som får en slik tabell, bygger dessuten riktig fra start. Kravspesifikasjonen er rett sted for personvern, ikke sluttkontrollen.

SDK-er fra tredjeparter: den vanligste fellen

Den største GDPR-risikoen i moderne apper er sjelden din egen kode, men de ferdige byggeklossene. Analyseverktøy, krasjrapportering, pushvarsler, annonsenettverk og innloggingstjenester leveres som SDK-er som bakes inn i appen, og flere av dem begynner å samle inn data i samme sekund som appen starter: enhets-ID, IP-adresse, atferdsdata.

Det gjør deg ansvarlig for datastrømmer du kanskje ikke engang kjenner til. Slik tar du kontrollen:

1. Kartlegg. Krev en liste over samtlige SDK-er fra tredjeparter i appen, med opplysninger om hvilke data hver SDK samler inn og hvor de sendes. Oppdater listen ved hver større utgivelse.
2. Vær kritisk. Hver SDK skal begrunnes i et behov, ikke ligge der fordi «det pleier man å ha». Færre avhengigheter er dessuten teknisk bedre.
3. Kontroller overføringer. Sendes data ut av EØS, kreves et gyldig overføringsgrunnlag. Alternativer med hosting i EU reduserer både risiko og papirarbeid.
4. Synkroniser med samtykket. SDK-er for sporing skal ikke aktiveres før brukeren har sagt ja. En vanlig feil er at samtykkedialogen finnes, men at SDK-ene allerede har rukket å sende data. Det oppdages lett i en nettverksanalyse og ser dårlig ut ved tilsyn.

Appbutikkene stiller nå egne krav til deklarasjon av datainnsamling, så kartleggingen trengs uansett. Gjør den grundig én gang i stedet for slurvete to ganger.

Brukernes rettigheter skal bygges, ikke bare loves

Retten til sletting, innsyn og tilbaketrekking av samtykke er ikke policytekst. Det er funksjonalitet som skal designes og testes som alt annet:

• Sletting. Hva skjer konkret når en bruker sletter kontoen sin? Opplysningene skal bort fra produksjonsdatabasen, kopier og tredjepartstjenester, med definerte unntak (for eksempel regnskapsopplysninger etter bokføringsloven) og dokumenterte slettefrister. «Vi deaktiverer kontoen» er ikke sletting.
• Innsyn. En bruker har rett til å få utlevert opplysningene sine. Manuell håndtering fungerer ved lavt volum, men må være beskrevet i en rutine: hvem som gjør hva, og innen hvilken frist (én måned er hovedregelen).
• Samtykkehåndtering. Samtykke skal være like lett å trekke tilbake som å gi, og brukeren skal kunne endre valget inne i appen, ikke måtte sende en e-post til kundestøtten.

Et konkret scenario: En bruker skriver «slett alt dere har om meg» i en e-post. Uten forberedelse blir det en ukes detektivarbeid i databaser, sikkerhetskopier, analyseverktøy og pushtjenester. Med en sletteflyt som er bygget fra start, er det ett knappetrykk og en bekreftelse på e-post. Forskjellen ligger i designbeslutninger som kostet noen timer i kravfasen.

GDPR som kvalitetskrav, ikke brems

Riktig håndtert er personvern ikke noe som bremser appen. Det handler om de samme disiplinene som i god arkitektur: å vite hvilke data som finnes, hvorfor, hvor de flyter og hvordan de slettes. Vi i Weapp bygger apper med den holdningen fra første skisse og hjelper gjerne til med å gå gjennom kravene fra et personvernperspektiv før utviklingen starter. Ta kontakt, så tar vi en prat.