Je app staat in de store, de pushberichten gaan eruit, de locatiefunctie werkt. Dan vraagt iemand: “Heb je een privacybeleid voor de app?” Je kopieert snel het beleid van je website, zet er een nieuwe datum op, en publiceert. Probleem opgelost, toch?

Niet echt. Een standaard websitebeleid mist precies de databronnen die een mobiele app uniek maken: push-tokens, advertentie-ID’s, sensorgegevens en locatiedata in meerdere precisielagen. De Gegevensbeschermingsautoriteit (GBA) kijkt uitdrukkelijk naar deze app-specifieke elementen. Dit artikel bouwt een technisch privacybeleid voor je mobiele app vanuit de datalaag omhoog, zodat je beleid klopt met wat je app echt doet.

Waarom je websitebeleid tekortschiet voor een app

Een website verwerkt cookies, IP-adressen en formulierdata. Een mobiele app gaat veel verder. Er zijn vijf databronnen die je bij een website nooit tegenkomt en die je verplicht apart moet beschrijven in je privacybeleid voor een mobiele app.

  • Push-notificatietokens (gegenereerd door APNs of FCM)
  • Advertentie-ID’s zoals IDFA (Apple) en GAID (Google)
  • Precisielocatie, inclusief achtergrondlocatie
  • Sensordata: stappenteller, versnellingsmeter, microfoontoegang
  • OS-systeemrechten die je app aanvraagt

Elk van deze databronnen heeft een eigen rechtsgrond, een eigen bewaartermijn en een eigen verwerkersrelatie, belangrijke clausules die je moet opnemen in je beleid. Dat is de reden waarom je ze stuk voor stuk moet benoemen.

Push-notificatietokens: wat je verplicht vermeldt

Wanneer een gebruiker pushberichten toestaat, genereert het besturingssysteem een uniek token. Dat token stuurt Apple via APNs of Google via FCM naar jouw backend. Wat veel app-eigenaren vergeten: dat token is een persoonsgebonden identifier als je het koppelt aan een gebruikersprofiel, een e-mailadres of een abonnement.

In je beleid vermeld je minstens vier zaken. Wat het token is en hoe het ontstaat. Hoelang je het bewaart, ook na opt-out (gangbaar is 30 dagen na uitschrijving, maar documenteer je eigen keuze). Welke verwerker het token doorstuurt (APNs of FCM, beide zijn te beschouwen als verwerkers). En of je het koppelt aan andere profiel-informatie.

Een voorbeeldformulering: “Wanneer je pushberichten toestaat, ontvangen wij via Apple Push Notification service (APNs) of Firebase Cloud Messaging (FCM) een apparaattoken. Dit token bewaren wij zolang je pushberichten ingeschakeld hebt en verwijderen wij uiterlijk 30 dagen na uitschrijving of verwijdering van de app.”

Locatiedata in drie lagen

Locatie is de meest gevoelige databron in een gemiddelde app, en ook de meest gelaagde. Op iOS en Android bestaat er een fundamenteel verschil tussen drie vormen van locatietoegang, en elke laag vereist een aparte rechtsgrond én een aparte zin in je beleid.

Locatietype Wat het betekent Vereiste rechtsgrond
Approximate location Nauwkeurigheid van 3 km, via wifi of celmasten Gerechtvaardigd belang mogelijk bij niet-gevoelig gebruik
Precise location GPS-nauwkeurigheid tot enkele meters Toestemming (art. 6 lid 1 a AVG)
Background location Locatie ook wanneer de app niet actief is Uitdrukkelijke toestemming, DPIA verplicht

Voor achtergrondlocatie verwacht de GBA bovendien een Data Protection Impact Assessment (DPIA), onderdeel van privacy by design en by default. Dat geldt ook voor apps die continu of op korte intervallen locatie registreren, zoals een bezorgapp of een trackingfunctie voor werknemers. De DPIA documenteer je intern, maar in je beleid verwijs je ernaar.

Advertentie-ID’s en device-identifiers

De IDFA (Identifier for Advertisers, Apple) en de GAID (Google Advertising ID) zijn resettable identifiers: de gebruiker kan ze zelf opnieuw instellen of blokkeren. De Android ID is dat niet: die blijft gekoppeld aan het apparaat tot een fabrieksreset. Dat onderscheid is juridisch relevant, want non-resettable identifiers liggen onder meer scrutiny bij toezichthouders.

Als je app fingerprinting inzet, dus het combineren van meerdere apparaatkenmerken (schermresolutie, taalinstellingen, batterijstatus) om een uniek profiel op te bouwen zonder expliciete identifier, dan ben je verplicht dat expliciet te benoemen. Schrijf dan iets als: “Wij gebruiken technische apparaatkenmerken in combinatie om apparaten te herkennen. Dit is een vorm van fingerprinting. De rechtsgrond hiervoor is toestemming.”

Rechtsgronden per datakategorie

Niet elke verwerking in een app vereist toestemming. Crashlogs en anonieme sessie-analytics kun je vaak onderbouwen met gerechtvaardigd belang (art. 6 lid 1 f AVG), op voorwaarde dat je de afweging documenteert en de data niet herleidbaar is tot individuen. Voor locatiedata op precisieniveau, advertentie-ID’s en sensordata die je gebruikt voor profilering, is toestemming de enige verdedigbare rechtsgrond.

De praktische vuistregel: vraag je jezelf af of de gemiddelde gebruiker verrast zou zijn door deze verwerking? Dan is toestemming de veiligste keuze.

App-store listings als juridische laag

Apple verplicht een Privacy Nutrition Label in de App Store. Google vereist een Data Safety Section in de Play Store. Beide zijn publiek zichtbaar en worden door de GBA beschouwd als onderdeel van je transparantieverplichtingen. Het probleem: ze stellen vragen in categorieën die niet altijd één-op-één matchen met de AVG-terminologie.

Wat je verplicht dubbel documenteert: elke datacategorie die je aanvinkt in de app-store listing, moet terugkomen in je privacybeleid voor de mobiele app, met dezelfde scope. Als je in de Play Store aangeeft dat je “approximate location” verzamelt, maar je beleid beschrijft alleen “locatiegegevens”, is er een inconsistentie die bij een klacht als een rode vlag wordt gezien.

De toestemmingsstroom in de app zelf

Timing is alles. De OS-permissievraag (het systeemvenster van iOS of Android) mag je maar één keer tonen. Als de gebruiker weigert, is het venster definitief gesloten tot de gebruiker zelf naar de instellingen gaat. Daarom raden UX-specialisten en privacyadvocaten een pre-permission rationale screen aan: een eigen scherm vóór de OS-vraag, waarin je uitlegt waarvoor je de toegang nodig hebt en wat er gebeurt als de gebruiker weigert.

In je beleid beschrijf je ook wat er technisch en functioneel verandert bij weigering of intrekking. Stel, je hebt een lokale zoekapp. Dan schrijf je: “Als je locatietoegang intrekt, schakelen wij over op handmatige plaatsinvoer. Reeds verzamelde locatiedata verwijderen wij op jouw verzoek binnen 30 dagen.”

Wat de GBA verwacht bij locatieverwerking

De GBA heeft in recente beslissingen uitdrukkelijk gesteld dat continue of nauwkeurige locatieregistratie een hoog risico voor betrokkenen inhoudt. Dat betekent in de praktijk drie dingen. Je voert een DPIA uit vóór je de functie lanceert. Je documenteert de noodzaak en proportionaliteit van de locatieverwerking. En je zorgt dat de opt-in tijdens onboarding vrij, specifiek en geïnformeerd is, wat betekent dat de app volledig functioneel moet zijn als de gebruiker weigert, tenzij locatie de kern van de dienst is.

De valkuil bij opt-in tijdens onboarding: als je de locatiepermissie vraagt als eerste scherm, samen met vijf andere toestemmingen, is de toestemming juridisch aanvechtbaar. Granulariteit en timing zijn cruciaal.

Praktische beleidsstructuur: de paragrafen die je nodig hebt

Een privacybeleid voor een mobiele app bevat minstens de volgende secties, bovenop de standaard AVG-elementen zoals verwerkingsverantwoordelijke en betrokkenenrechten.

  • Apparaat- en gebruiksgegevens (inclusief device-identifiers, OS-versie, app-versie)
  • Pushberichten en notificatietokens
  • Locatiegegevens (per precisielaag beschreven)
  • Advertentie-ID’s en tracking
  • Rechten die de app aanvraagt en waarvoor
  • Verwerkers: APNs, FCM, analyticsdiensten, crashrapportagetools
  • Hoe je toestemming intrekt en wat er dan technisch verandert

Controlelijst voor publicatie

Doorloop deze twaalf checkpoints voordat je je beleid publiceert en je app-store listing invult.

Stap 1: Heb je alle vijf app-specifieke databronnen (tokens, advertentie-ID’s, locatie, sensordata, OS-rechten) beschreven?

Stap 2: Klopt de bewaartermijn van je push-token ook na opt-out?

Stap 3: Onderscheid je de drie locatielagen elk met een eigen rechtsgrond?

Stap 4: Heb je IDFA en GAID benoemd als resettable identifiers?

Stap 5: Gebruik je fingerprinting? Dan is dat expliciet vermeld?

Stap 6: Zijn crashlogs en analytics onderbouwd met een aantoonbare afweging gerechtvaardigd belang?

Stap 7: Zijn je app-store datacategorieën consistent met je beleid?

Stap 8: Beschrijf je de pre-permission rationale en de gevolgen van weigering?

Stap 9: Is er een DPIA uitgevoerd voor precisielocatie of achtergrondlocatie?

Stap 10: Is de opt-in tijdens onboarding granulair en niet gebundeld met andere toestemmingen?

Stap 11: Zijn alle verwerkers (APNs, FCM, analyticsproviders) opgenomen in je verwerkingsregister?

Stap 12: Is het beleid bereikbaar vanuit de app zelf, niet alleen via de app-store pagina?

Een privacybeleid voor een mobiele app afdoen met een kopie van je websitebeleid werkt niet. Push-tokens, achtergrondlocatie en advertentie-identifiers zijn databronnen die een eigen, concrete beschrijving vragen. De GBA verwacht dat je die laag voor laag documenteert, niet in vage termen, maar aansluitend op wat je app werkelijk verzamelt en verwerkt.

Gebruik een generator zoals privacypolicygenerator.be als startpunt voor de app-specifieke secties. Vul daarna de technische details in die uniek zijn voor jouw situatie, en doorloop de controlelijst voordat je publiceert. Zo staan je beleid, je app-store listing en je verwerkingsregister in lijn met elkaar.