Privacylabels: wat uw leverancier moet aanleveren

Beide app stores vroegen al langer om een privacylabel: een overzicht van welke gegevens uw app verzamelt en waarvoor. Sinds begin 2026 moet dat aanzienlijk gedetailleerder, en strekt de opgave zich uit tot elke bibliotheek van derden die in de app is meegeleverd.

Dat laatste is de kern. Een app bevat vrijwel altijd componenten die iemand anders heeft geschreven: een module die crashes doorgeeft, een die gebruiksstatistieken verzamelt, een die betalingen afhandelt. Elk daarvan verwerkt gegevens, en dat telt mee als uw verwerking.

Daarnaast moet u expliciet aangeven of u AI-modellen gebruikt en welke gegevens daarbij worden gedeeld. Wie dat niet of onjuist opgeeft, riskeert afkeuring bij de review of verwijdering van een app die al live staat.

Vraag om een overzicht van alle externe bibliotheken in de app, met per stuk: waarom die erin zit, welke gegevens die volgens de leverancier verwerkt, en waar dat gedocumenteerd staat. Een leverancier die dat niet kan geven, weet zelf niet wat er in uw app zit.

Vraag daarnaast om de opgave die voor de store wordt ingediend, voordat die wordt ingediend. U bent degene op wiens naam de app staat, dus u moet kunnen beoordelen of de opgave klopt met wat u had verwacht.

Spreek af hoe dit wordt bijgehouden bij doorontwikkeling. Een app krijgt na livegang nieuwe functies en soms nieuwe bibliotheken. Zonder afspraak loopt de opgave binnen een jaar achter op de werkelijkheid, en dat merkt u pas bij een controle.

Naast de labels geldt een tweede eis die vaak wordt gemist: gebruikers moeten in de app zelf hun account en de bijbehorende gegevens kunnen laten verwijderen. Een verwijzing naar uw klantenservice volstaat niet meer.

Dat raakt meer dan een knop. Er moet bepaald worden wat er precies verdwijnt, wat om administratieve of wettelijke redenen bewaard blijft, en wat er gebeurt met gegevens die al bij andere partijen staan. Neem die vragen mee in het ontwerp, want achteraf inbouwen is duurder en zelden even zorgvuldig.

Onze app verzamelt zelf niets. Moeten we dan iets opgeven?

Waarschijnlijk wel. Bevat de app een module die crashes doorgeeft of gebruik meet, dan gaan er gegevens naar buiten en telt dat als uw verzameling. De vraag is niet wat u zelf hebt gebouwd, maar wat er via uw app wordt verwerkt.

Wie draait op voor een verkeerde opgave?

Richting de store bent u dat, want de app staat op uw naam. Dat is een reden om de opgave vooraf te willen zien en om alleen te werken met leveranciers die kunnen onderbouwen welke componenten zij gebruiken en waarom.

Wat gebeurt er bij een afkeuring?

In het gunstigste geval wordt de app bij de review geweigerd en corrigeert u de opgave, wat tijd kost maar verder geen schade doet. Vervelender is een controle achteraf op een app die al live staat, want dan kan verwijdering volgen en zijn uw gebruikers de app kwijt tot het is hersteld.

Moet de verwijdermogelijkheid echt alles wissen?

Nee. Gegevens die u om administratieve of wettelijke redenen moet bewaren mogen blijven, denk aan facturen. Wat wel moet is dat het account en de daaraan gekoppelde persoonsgegevens verdwijnen, en dat voor de gebruiker duidelijk is wat er wel en niet weggaat.

Geldt dit ook voor een app die alleen intern wordt gebruikt?

Verspreidt u de app via de publieke stores, dan gelden de regels onverkort. Gaat het om distributie binnen uw eigen organisatie via een zakelijk kanaal, dan liggen de eisen anders. Laat dat vaststellen voordat u de route kiest, want het scheelt in wat u moet regelen.

• Beveiligingseisen aan uw leverancier
• App store optimalisatie
• Broncode-eigendom en overdracht