Compliance voor kindgegevens: praktische gids voor SaaS-teams

Compliance voor kindgegevens betekent dat kind-specifieke privacyvereisten worden vertaald naar workflows voor product, security, leveranciers, support en evidence. Het gaat niet alleen om de vraag of een kind toestemming kan geven. Een SaaS-team moet ook weten of kinderen waarschijnlijk toegang hebben tot de dienst, welke persoonsgegevens worden verzameld, of het ontwerp leeftijdsgeschikt is, hoe ouderlijke autorisatie werkt en welk bewijs voor de launch bestaat.

Onder de GDPR verdienen kinderen specifieke bescherming omdat zij risico's, gevolgen, waarborgen en rechten minder goed kunnen begrijpen. Artikel 8 bevat bijzondere voorwaarden voor toestemming bij online diensten die rechtstreeks aan een kind worden aangeboden. Nationale wetgeving kan de relevante leeftijd tussen 13 en 16 jaar zetten.

Waarom dit belangrijk is in SaaS

Veel B2B SaaS-bedrijven denken dat kindgegevens irrelevant zijn omdat zij aan bedrijven verkopen. Dat kan onjuist zijn. Een samenwerkingstool kan op scholen worden gebruikt. Een supportproduct kan tickets over minderjarigen ontvangen. Producten voor education, health, gaming, community, identity of productivity kunnen toegankelijk zijn voor tieners. Analytics, opnames, AI-samenvattingen, profiling, geolocatie en integraties kunnen risico's maken, ook wanneer kinderen niet de koper zijn.

De ICO Children's Code is VK-specifiek, maar praktisch nuttig omdat hij kijkt naar online diensten die waarschijnlijk toegankelijk zijn voor kinderen. Hij dwingt teams om kindgegevens te mappen, leeftijd te beoordelen, privacy-invasieve defaults te vermijden, dataminimalisatie toe te passen en kindrisico's als designinput te gebruiken.

Wanneer het van toepassing is

Vraag eerst of kinderen doelgebruikers zijn, waarschijnlijke gebruikers zijn, in klantdata voorkomen of indirect in workflows aanwezig zijn. Het contract kan met een bedrijf, school of volwassene zijn; de operationele vraag blijft of persoonsgegevens van kinderen worden verzameld, afgeleid, opgeslagen, gedeeld of gebruikt.

Triggers zijn onder meer accounts voor minderjarigen, gebruik in onderwijs of youth-contexten, supporttickets of uploads met informatie over kinderen, behavioral analytics, aanbevelingen, advertenties, profiling, locatie, foto's, stem, biometrie, gevoelige data of klantvragen over gebruik op scholen.

Inventaris en leeftijd

Het eerste nuttige artefact is een inventaris van kindgegevens. Leg per workflow vast: gebruikersgroep, datacategorieen, verzamelpunt, doel, rechtsgrond, leeftijdssignaal, toestemming of ouderlijke autorisatie, leveranciers, bewaartermijn, toegang, notices en evidence-locatie.

Leeftijdszekerheid is een risicogebaseerde beslissing. Volgens de ICO kan een organisatie leeftijd vaststellen met een zekerheidsniveau dat past bij het risico, of de bescherming toepassen op alle gebruikers. Voor SaaS kan brede toepassing van veiligere defaults cleaner zijn wanneer scheiden van volwassenen en kinderen extra invasieve data zou vereisen.

Toestemming, DPIA en defaults

Toestemming is niet altijd de juiste rechtsgrond. Wanneer toestemming wordt gebruikt voor een online dienst die rechtstreeks aan een kind wordt aangeboden, kan artikel 8 ouderlijke autorisatie vereisen onder de toepasselijke leeftijd. De EDPB-richtlijnen vragen dat toestemming vrij, specifiek, geinformeerd en ondubbelzinnig is, met uitleg die bij de leeftijd past.

De DPIA hoort vroeg in productdesign plaats te vinden. Zij beschrijft de verwerking, beoordeelt noodzaak en proportionaliteit, identificeert kind-specifieke risico's, documenteert maatregelen en toont hoe het resultaat het product beinvloedde.

Defaults moeten alleen noodzakelijke data verzamelen, zichtbaarheid en delen beperken, onnodige profiling vermijden, geolocatie uitzetten tenzij er een sterke reden is en controles makkelijk vindbaar maken.

Operationele checklist

• Map kinddata-ingangen in product, support, security, analytics, AI en leveranciers.
• Bepaal of het bedrijf controller, processor of beide is.
• Documenteer leeftijdsaanpak, rechtsgrond, toestemming en ouderlijke autorisatie.
• Voer een DPIA of product privacy review uit met kindrisico's.
• Stel hoge privacydefaults in en minimaliseer data.
• Review profiling, advertenties, geolocatie, nudges en sharing.
• Pas notices aan de verwachte leeftijdsgroep aan.
• Definieer retentie, verwijdering, toegang en leveranciersbeperkingen.
• Bewaar evidence waar Legal, Compliance, Security en Product die kunnen vinden.

FAQ

Geldt dit voor B2B SaaS?

Dat kan. Kindgegevens kunnen binnenkomen via onderwijsclients, supportcontent, uploads, integraties, analytics, AI-functies of door klanten geimporteerde data.

Wat moet eerst worden gedocumenteerd?

Inventaris, leeftijdsaanpak, rechtsgrond, toestemming of ouderlijke autorisatie, DPIA, privacydefaults, leveranciers, retentie en evidence-owner.

Wat is de grootste fout?

Kindgegevens-compliance behandelen als een eenmalige juridische interpretatie in plaats van een herhaalbare workflow met owners, triggers, evidence en escalatie.