Als kinderen onder de 13 jaar uw app gebruiken, uw spel spelen of uw website bezoeken — zelfs als u het nooit voor hen hebt ontworpen — kan de federale wet u al behandelen als een kindbedrijf. En aangezien de eerste grote update van die wet in meer dan tien jaar dit jaar volledig van kracht is geworden, zijn de verplichtingen strenger dan de meeste kleine operators beseffen.
De wet is de Children's Online Privacy Protection Act, of COPPA. Deze bestaat sinds 2000, maar de herziening van de COPPA-regel door de Federal Trade Commission — afgerond in januari 2025 met naleving door operators vereist vanaf april 2026 — heeft het praktische speelboek herschreven: afzonderlijke ouderlijke toestemming voordat u gegevens van een kind met iemand deelt, harde limieten op hoe lang u die bewaart, en een schriftelijk beveiligingsprogramma om ze te beschermen. Civiele boetes lopen op tot meer dan $50.000 per overtreding, jaarlijks naar boven bijgesteld voor inflatie.
Deze gids legt uit wie COPPA daadwerkelijk dekt, wat de bijgewerkte regel vereist, en de concrete checklist die een klein team kan doorlopen zonder een privacyafdeling in te huren.
Wie COPPA dekt: Het gaat niet alleen om kindersites
Het duurste misverstand over COPPA is de overtuiging dat het alleen van toepassing is op producten 'gemaakt voor kinderen'. De FTC zegt expliciet het tegenovergestelde: de regel is niet alleen voor kindersites.
Websites en diensten 'gericht op kinderen'
Een site of app wordt als gericht op kinderen beschouwd wanneer deze, alles bij elkaar genomen, aantrekkelijk is voor kinderen onder de 13 jaar. De FTC weegt factoren zoals onderwerp, visuele stijl en personages, muziek, taal, bewijs van daadwerkelijk gebruik door kinderen, en reclame gericht op kinderen. Een fel geanimeerd spel, een cartoon-avatarmaker, of een product-uitpakken-kanaal met een jong publiek kunnen allemaal kwalificeren — ongeacht wat uw marketingplan zegt over uw doelgroep.
'Daadwerkelijke kennis' vangt alle anderen
Zelfs een dienst voor algemeen publiek wordt gedekt op het moment dat de operator daadwerkelijke kennis heeft dat deze persoonlijke gegevens verzamelt van een kind onder de 13 jaar. Die kennis kan komen via een support-e-mail waarin de leeftijd van een gebruiker wordt genoemd, een verjaardagsveld in uw aanmeldformulier, een klacht van een ouder, of analyses die een jonge gebruikersgroep tonen die u ervoor koos niet te onderzoeken. Zodra u het weet, kunt u het niet meer niet-weten: vanaf dat moment zijn COPPA's toestemmings- en gegevensverwerkingsverplichtingen van toepassing op de informatie van dat kind.
Diensten met gemengd publiek krijgen een tussenweg
Als uw publiek echt zowel kinderen als volwassenen omvat, laat de regel u leeftijdscontrole toepassen en COPPA-bescherming alleen toepassen op de onder-13-gebruikers die u identificeert — maar de controle moet neutraal en effectief zijn. Een zelfverklaarde geboortedatumpoort die gebruikers stilletjes hun antwoord laat wijzigen tot ze 'oud genoeg' zijn, of die standaard een volwassen jaar gebruikt, zal u niet beschermen. Ontwerp de poort zodanig dat deze niet in één klik kan worden omzeild, en behandel iedereen die als onder 13 is geïdentificeerd als volledig gedekt.
Wat de update van 2025 veranderde
De wijzigingen waaraan operators vanaf april 2026 moesten voldoen, zijn de eerste significante herziening sinds 2013, en ze concentreren zich op drie thema's: ouders moeten specifiek goedkeuren voor delen en monetariseren, gegevens van kinderen mogen niet worden opgeslagen zonder oog voor verwijdering, en beveiliging moet worden gedocumenteerd in plaats van aangenomen.
Afzonderlijke toestemming vóór delen of gerichte advertenties
Eerder kon één enkele ouderlijke toestemming verzameling, gebruik en openbaarmaking samen dekken. Nu moet u een afzonderlijke, opt-in toestemming verkrijgen vóór het openbaar maken van persoonlijke gegevens van een kind aan derden — inclusief voor gerichte advertenties. In de praktijk betekent dit dat uw onboarding-stroom twee afzonderlijke, duidelijk beschreven verzoeken moet bevatten: één om de informatie van het kind te verzamelen en te gebruiken voor de dienst zelf, en een andere vóórdat iets naar advertentienetwerken, analyseleveranciers of andere derden stroomt. Vooraf aangevinkte vakjes en gebundelde 'accepteer alles'-knoppen voldoen niet aan de norm.
Bewaar gegevens van kinderen alleen zo lang als nodig — en verwijder ze daarna
De bijgewerkte regel handhaaft de 'redelijkerwijs noodzakelijke'-bewaarnorm, maar voegt een expliciet verbod toe op het oneindig bewaren van persoonlijke gegevens van kinderen. U moet een gegevensbewaarbeleid voor kindinformatie publiceren en een intern schema voor verwijdering onderhouden. Concreet: definieer voor elke categorie gegevens die u bewaart (accounts, chatlogs, supporttickets, back-ups) hoe lang u ze bewaart en waarom, en verwijder ze vervolgens volgens dat schema. 'We zouden het misschien ooit nodig hebben' is geen geldige bewaarreden meer.
Een schriftelijk beveiligingsprogramma is verplicht
Operators moeten nu een schriftelijk beveiligingsprogramma voor persoonlijke gegevens van kinderen opzetten, implementeren en onderhouden, met waarborgen die passend zijn voor de gevoeligheid van de gegevens. Voor een klein team vereist dit geen enterprise-tooling — maar het vereist wel dat u opschrijft wie toegang heeft tot kindgegevens, hoe deze worden versleuteld tijdens transport en in rust, hoe u leveranciers met toegang screent, en hoe u reageert op een incident — en dat u dat document vervolgens daadwerkelijk volgt.
Brede definities en scherpere kennisgevingen
De update voegt biometrische identificatoren toe aan de definitie van persoonlijke informatie, dus stemafdrukken, gezichtsgeometrie of vingerafdrukken verzameld van kinderen zijn volledig gedekt. Uw directe kennisgeving aan ouders moet ook gedetailleerder zijn: specificeer wat u verzamelt, hoe u het gebruikt, en specifiek welke derden het ontvangen en voor welke doeleinden. Een generieke alinea 'we kunnen gegevens delen met partners' volstaat niet langer.
Verifieerbare ouderlijke toestemming, praktisch gesproken
COPPA-toestemming moet 'verifieerbaar' zijn — u hebt een methode nodig die redelijkerwijs is berekend om te bevestigen dat de persoon die toestemming geeft daadwerkelijk de ouder van het kind is, niet het kind. De FTC erkent verschillende benaderingen, en de juiste hangt af van wat u met de gegevens doet:
- Betalingsverificatie. Een kleine betaling of kaartverificatiestap bevestigt dat een volwassene het betaalinstrument bezit. Gebruikelijk voor abonnementen en betaalde apps.
- Ondertekende toestemmingsformulieren. Een ouder ondertekent en retourneert een formulier per post, fax of gescande upload. Laagtechnologisch en betrouwbaar voor scholen, kampen en programma's met offline inschrijving.
- Videoconferentie. Een live videocontrole met getraind personeel. Sterke zekerheid, maar arbeidsintensief op schaal.
- Overheidsidentificatieverificatie. Controle van een rijbewijs of ander identiteitsbewijs tegen een database. Effectief, maar u bewaart dan gevoelige ouderdocumenten die hun eigen bescherming en verwijderingsschema nodig hebben.
- Kennisgebaseerde authenticatie. Uitdagingsvragen afkomstig uit gegevens die alleen de ouder waarschijnlijk zou weten. De FTC heeft specifieke implementaties van deze methode goedgekeurd.
- E-mail-plus — alleen intern gebruik. Voor gegevens die u uitsluitend binnen uw eigen operatie verzamelt en gebruikt (nooit aan derden openbaar gemaakt), mag u de lichtere 'e-mail-plus'-methode gebruiken: een e-mail van de ouder gevolgd door een vertraagde bevestiging via een tweede kanaal. Op het moment dat een derde de gegevens ontvangt, is e-mail-plus niet langer voldoende.
Welke methode u ook kiest, bewaar documentatie van de toestemming: wanneer deze is gegeven, wat deze dekte, en hoe deze is geverifieerd. Toestemmingsdocumentatie is zowel een juridisch schild als gewone bedrijfsadministratie.
Uw nalevingschecklist
Doorloop deze stappen in volgorde. Elke stap bouwt voort op de vorige, en samen dekken ze de verplichtingen die de eigen zesstappen-nalevingsplan van de FTC benadrukt.
1. Breng in kaart wat u verzamelt en van wie
Inventariseer elk gegevensveld dat uw product raakt: aanmeldformulieren, analyse-SDK's, crashreporters, advertentiemodules, chatfuncties, supporttools, nieuwsbrieven. Noteer voor elk of het van een gebruiker onder de 13 jaar zou kunnen komen en welke leveranciers het ontvangen. De meeste kleine teams ontdekken minstens één SDK die stil apparaatidentificatoren of locatiegegevens verzendt die ze nooit bewust hebben gekozen te verzamelen.
2. Bepaal uw publiekshouding
Bent u kindgericht, gemengd publiek, of algemeen publiek? Documenteer de redenering. Als gemengd publiek, bouw dan de neutrale leeftijdscontrole zoals hierboven beschreven. Als algemeen publiek, beslis dan van tevoren hoe u zult reageren wanneer u daadwerkelijke kennis krijgt van een jonge gebruiker — wie beoordeelt de vlag, hoe snel stopt de gegevensverzameling, en wanneer vindt verwijdering plaats.
3. Herschrijf uw privacybeleid en ouderkennisgeving
Plaats een duidelijk, volledig beleid: welke kindinformatie u verzamelt, hoe u het gebruikt, met wie u het deelt en waarom, uw bewaartermijnen, de rechten van ouders om gegevens van hun kind in te zien, te corrigeren en te verwijderen, en hoe u contact kunt opnemen. Schrijf vervolgens de directe kennisgeving aan ouders in duidelijke taal — het moet de specifieke derden en doeleinden noemen, niet achter algemeenheden verbergen.
4. Bouw de tweesporige toestemmingsstroom
Scheid de toestemming voor het exploiteren van uw dienst van de toestemming voor het delen van gegevens met derden of het serveren van gerichte advertenties. Log beide. Maak het intrekken van toestemming net zo gemakkelijk als het geven ervan, en zorg dat intrekking daadwerkelijk de downstream-stromen stopt — inclusief het vertellen aan leveranciers om te verwijderen wat u hen hebt gestuurd.
5. Beveilig leveranciers met contracten
Lijst elke serviceprovider, advertentienetwerk, analysetool en platform die kindgegevens raakt. Uw contracten moeten hun gebruik van de gegevens beperken tot uw aangegeven doeleinden, hen verbieden om onafhankelijk hergebruik of monetarisatie te doen, en verwijdering op verzoek vereisen. Een leverancier wiens voorwaarden het toestaan gegevens voor eigen doeleinden te bewaren of door te verkopen, is een COPPA-aansprakelijkheid die in uw stack zit.
6. Publiceer het bewaarschema en voer het uit
Schrijf het bewaarbeleid dat de regel nu vereist: gegevenscategorieën, doeleinden, tijdslimieten, verwijderingsmethode, en wie verantwoordelijk is. Zet terugkerende verwijdering op een kalender — kwartaalverwijderingen van verlopen supporttickets, verouderde logs en verouderde back-ups. Vergeet niet dat verwijdering binnen een redelijke tijd ook back-ups en kopieën bij leveranciers moet bereiken.
7. Schrijf het beveiligingsprogramma
Documenteer toegangscontroles, encryptie, medewerkerstraining, leveranciersscreening en incidentrespons specifiek voor kindgegevens. Evalueer het minstens jaarlijks en na elk incident of grote productwijziging.
Fouten die steeds terugkomen
- Een app-store-leeftijdsclassificatie als naleving behandelen. Winkelclassificaties en COPPA zijn afzonderlijke systemen. Een '4+' of 'Iedereen'-label voldoet niet aan de verplichtingen van de regel en ontslaat u er ook niet van.
- De SDK's vergeten. Analyse-, attributie- en advertentiemediatiekits zijn de meest voorkomende bron van niet-openbaar gemaakte verzameling. Audit ze bij elke app-update, niet alleen eenmalig bij de lancering.
- Aannemen dat 'we richten ons niet op kinderen' het onderzoek beëindigt. Daadwerkelijke kennis en gebruik door gemengd publiek brengen producten voor algemeen publiek binnen bereik, ongeacht de bedoeling.
- Eén vakje voor alles. Gebundelde toestemming voldoet niet aan de afzonderlijke opt-in-vereiste voor openbaarmaking en gerichte advertenties.
- Gegevens bewaren 'voor het geval dat'. Oneindige bewaring is nu expliciet verboden. Als u het doel niet kunt noemen, verwijder de gegevens dan.
- Staatswetten negeren. Verschillende staten hebben hun eigen privacywetten voor kinderen en tieners ingevoerd met ontwerpcode-verplichtingen die verder gaan dan COPPA. Federale naleving is de ondergrens, niet het plafond — controleer de staten waar uw gebruikers wonen.
Wat niet-naleving kost
COPPA-overtredingen worden behandeld als oneerlijke of misleidende praktijken, en rechtbanken kunnen civiele boetes opleggen van meer dan $50.000 per overtreding — waarbij elk getroffen kind en elke afzonderlijke overtreding mogelijk afzonderlijk telt. Die rekenkunde is hoe handhavingsacties bij grote platforms tientallen en honderden miljoenen dollars hebben bereikt. Kleine operators krijgen zelden boetes op de voorpagina, maar de FTC heeft herhaaldelijk kleine app-ontwikkelaars en startups vervolgd, en staatsprocureurs-generaal kunnen hun eigen acties ondernemen. Naast boetes vereisen bevelen doorgaans verwijdering van onrechtmatig verzamelde gegevens — inclusief modellen of profielen die daarop zijn gebouwd — plus jaren van nalevingsmonitoring. De sanering kost meestal veel meer dan de naleving zou hebben gekost.
Volg naleving als de bedrijfskosten die het is
Elk item op de bovenstaande checklist kost iets: toestemmingsverificatiediensten, contractbeoordelingen, SDK-audits, verwijderingstooling, personeelstijd. Behandel deze als gewone kostenposten in uw boeken in plaats van eenmalige verrassingen. Tag leverancierscontracten die kindgegevens raken, zodat verlengingen een nieuwe gegevensgebruiksbeoordeling triggeren. Log bewaarschema-runs zoals u back-ups logt — een gedateerd bewijs dat verwijderingen hebben plaatsgevonden is zelf bewijs van naleving. En wanneer u de volgende functie begroot die gebruikersgegevens verzamelt, reken dan de toestemmingsstroom, de kennisgevingsupdate en de opslaglevenscyclus van tevoren in, op dezelfde manier als u hosting zou prijzen. Privacywerk dat in uw grootboek leeft, wordt gefinancierd; privacywerk dat in goede bedoelingen leeft, wordt vergeten.
Vereenvoudig uw financiële beheer
Terwijl u toestemmingsstromen, bewaarschema's en leveranciersbeoordelingen in uw operatie bouwt, is het essentieel om duidelijke financiële administratie van die nalevingsuitgaven te onderhouden. Beancount.io biedt boekhouding in platte tekst die u volledige transparantie en controle geeft over uw financiële gegevens — geen zwarte dozen, geen leverancierslock-in. Start gratis en zie waarom ontwikkelaars en financiële professionals overstappen op boekhouding in platte tekst.
