Är din app GDPR-säker? Det här är ditt ansvar

Det finns en missuppfattning som kostar appbeställare dyrt: att GDPR är utvecklarens problem. Så är det inte. Den som äger appen och bestämmer vad den gör med användarnas uppgifter är personuppgiftsansvarig — oavsett vem som skrivit koden. Byrån är ditt biträde, inte din ansvarsförsäkring. Här är vad ansvaret betyder i praktiken, från design till drift.

Dataminimering och rättslig grund — per funktion, inte per app

GDPR-arbetet börjar inte i en policy utan i funktionslistan. För varje funktion i appen ska två frågor ha svar:

• Vilka personuppgifter behöver funktionen — som minst? Dataminimering betyder att inte samla “bra att ha”-data. Behöver registreringen verkligen personnummer, eller räcker e-post? Behöver kartfunktionen kontinuerlig platshistorik, eller bara position medan den används?
• Med vilken rättslig grund? Kärnfunktioner vilar oftast på avtalet med användaren. Marknadsföring och spårning kräver normalt samtycke. Intern statistik kan vila på berättigat intresse — om intresseavvägningen är gjord och dokumenterad.

Gör detta som en enkel tabell i kravspecifikationen: funktion, uppgifter, grund, lagringstid. Övningen tar en eftermiddag och tvingar fram besluten medan de är billiga. Samma tabell blir sedan stommen i din registerförteckning och i informationen till användarna. En leverantör som får en sådan tabell bygger dessutom rätt från start — kravspecen är rätt plats för dataskydd, inte slutbesiktningen.

Tredjeparts-SDK:er: den vanligaste fällan

Den största GDPR-risken i moderna appar är sällan din egen kod — det är de färdiga byggblocken. Analysverktyg, kraschrapportering, pushnotiser, annonsnätverk och inloggningstjänster levereras som SDK:er som bakas in i appen, och flera av dem börjar samla in data i samma sekund som appen startar: enhets-ID, IP-adress, beteendedata.

Det gör dig ansvarig för dataflöden du kanske inte ens känner till. Så tar du kontrollen:

1. Inventera. Kräv en lista över samtliga tredjeparts-SDK:er i appen, med uppgift om vilken data varje SDK samlar in och vart den skickas. Uppdatera listan vid varje större release.
2. Ifrågasätt. Varje SDK ska motiveras av ett behov — inte ligga kvar för att “det brukar man ha”. Färre beroenden är dessutom bättre teknik.
3. Kontrollera överföringar. Skickas data utanför EU/EES krävs giltig överföringsgrund. EU-hostade alternativ minskar både risk och pappersarbete.
4. Synka med samtycket. Spårnings-SDK:er får inte aktiveras förrän användaren sagt ja. Ett vanligt fel är att samtyckesrutan finns men SDK:erna redan hunnit skicka data — det upptäcks lätt i en nätverksanalys och ser illa ut vid tillsyn.

Appbutikerna ställer numera egna deklarationskrav på datainsamling, så inventeringen behövs ändå — gör den ordentligt en gång i stället för slarvigt två.

Användarens rättigheter: bygg dem, lova dem inte

Rätten till radering, registerutdrag och återkallat samtycke är inte policytext — det är funktionalitet som ska designas och testas som allt annat:

• Radering. Vad händer konkret när en användare raderar sitt konto? Uppgifterna ska bort ur produktionsdatabas, kopior och tredjepartstjänster, med definierade undantag (t.ex. bokföringsdata enligt bokföringslagen) och dokumenterade gallringstider. “Vi avaktiverar kontot” är inte radering.
• Registerutdrag. En användare har rätt att få ut sina uppgifter. Manuell hantering fungerar vid låg volym men ska finnas beskriven som rutin: vem gör vad, inom vilken tid (en månad är huvudregeln).
• Samtyckeshantering. Samtycke ska vara lika lätt att ta tillbaka som att ge, och valet ska gå att ändra inne i appen — inte kräva ett mejl till supporten.

Ett konkret scenario: en användare mejlar “radera allt ni har om mig”. Utan förberedelse blir det en veckas detektivarbete över databaser, backuper, analysverktyg och pushtjänster. Med raderingsflöde byggt från start är det en knapptryckning och ett bekräftelsemejl. Skillnaden är designbeslut som kostade några timmar i kravfasen.

GDPR som kvalitetskrav, inte broms

Rätt hanterat är dataskydd inget som bromsar appen — det är samma discipliner som god arkitektur: veta vilken data som finns, varför, var den flödar och hur den tas bort. Vi på Weapp bygger appar med den hållningen från första skissen och hjälper gärna till att granska kravbilden ur dataskyddsperspektiv innan bygget startar — hör av dig så tar vi ett samtal.