De nieuwe storeregels: wat er in 2026 bij is gekomen

Privacylabels zijn gedetailleerder geworden en strekken zich uit tot elke bibliotheek van derden die in uw app zit. U geeft nu per component op wat er wordt verzameld en waarom, niet alleen voor uw eigen code.

Gebruikers moeten hun account en de bijbehorende gegevens in de app zelf kunnen laten verwijderen. Een verwijzing naar uw klantenservice volstaat niet meer, en dat raakt hoe uw software is opgebouwd.

U moet expliciet aangeven of en hoe u AI-modellen gebruikt en welke gegevens daarbij worden gedeeld. Dat loopt gelijk op met de transparantieverplichting die sinds augustus 2026 uit de AI Act volgt.

In een groeiend aantal markten gelden eisen rond leeftijdsverificatie, waarbij zowel de marktplaats als u als aanbieder een rol krijgt. Wat er precies geldt verschilt per markt.

Alle vier de eisen komen neer op hetzelfde: u moet weten wat er in uw app zit en wat daarmee gebeurt. Dat klinkt vanzelfsprekend, maar bij software die in de loop van jaren is gegroeid, is dat overzicht er zelden nog.

Het praktische gevolg is dat u één inventarisatie nodig heeft die vier vragen tegelijk beantwoordt: welke componenten zitten erin, welke gegevens gaan waarheen, welke modellen worden gebruikt, en waar staat dat vastgelegd. Die lijst gebruikt u vervolgens voor uw storeopgave, uw verwerkingsregister en uw antwoord op vragenlijsten van klanten.

Wie dat overzicht heeft, is met alle vier de eisen in een dag klaar. Wie het niet heeft, is er per eis afzonderlijk een week mee bezig en komt telkens dezelfde vragen tegen.

Vraag uw leverancier om een overzicht van alle externe componenten in uw app, met per stuk waarom die erin zit en welke gegevens die verwerkt. Een leverancier die dat niet kan geven, weet zelf niet wat er in uw app zit, en dat is een groter probleem dan de storeregels.

Laat controleren of de verwijdermogelijkheid er is en werkt, want dit is de eis waar bestaande apps het vaakst op stuklopen. Het is ook de eis die het meeste ontwerpwerk vraagt.

Leg vast wie dit bijhoudt bij doorontwikkeling. Een opgave die bij oplevering klopt, loopt binnen een jaar achter als niemand de verantwoordelijkheid heeft.

Geldt dit ook voor onze bestaande app?

Ja. De eisen kennen geen overgangstermijn voor apps die al live staan; ze gelden bij de volgende indiening en bij controles achteraf. Laat uw leverancier nagaan op welke punten uw huidige app niet meer voldoet.

Wat gebeurt er als we niets doen?

Bij de eerstvolgende update loopt u tegen een afkeuring aan, wat tijd kost maar herstelbaar is. Vervelender is een controle achteraf op een app die al live staat, want dan kan de app tijdelijk uit de store en zijn uw gebruikers hem kwijt tot het is opgelost.

Moeten we hiervoor de app opnieuw laten bouwen?

Zelden. De meeste eisen zijn met gerichte aanpassingen te regelen. De uitzondering is de verwijdermogelijkheid: als uw software nooit is ontworpen om gegevens van één gebruiker te kunnen verwijderen, kan dat een ingrijpender aanpassing worden.

Wie is verantwoordelijk, wij of ons bureau?

Richting de stores bent u dat, want de app staat op uw naam. Dat is een reden om de opgave vooraf te willen zien en om afspraken te maken over wie dit bijhoudt. Uw leverancier levert het werk, u draagt het risico.

Hoeveel werk is dit bij elkaar?

Voor een app die goed is opgezet en waarvan het componentenoverzicht klopt, valt het mee. Voor een app die in jaren is gegroeid zonder dat iemand bijhield wat erbij kwam, is de inventarisatie het meeste werk. Die inventarisatie heeft u daarna wel voor meerdere doelen tegelijk.

• Privacylabels: wat uw leverancier aanlevert
• Account en gegevens verwijderen
• App launch checklist