Kinderdaten-Compliance: Praxisleitfaden fuer SaaS-Teams

Kinderdaten-Compliance bedeutet, kindbezogene Datenschutzanforderungen in Produkt-, Security-, Vendor-, Support- und Evidenz-Workflows zu uebersetzen. Es geht nicht nur darum, ob ein Kind einwilligen kann. Ein SaaS-Team muss auch wissen, ob Kinder den Dienst wahrscheinlich nutzen, welche Daten erhoben werden, ob das Design altersgerecht ist, wie elterliche Autorisierung funktioniert und welche Nachweise vor dem Launch vorliegen.

Unter der GDPR verdienen Kinder besonderen Schutz, weil sie Risiken, Folgen, Schutzmassnahmen und Rechte oft weniger gut einschaetzen koennen. Artikel 8 enthaelt besondere Bedingungen fuer Einwilligung bei Diensten der Informationsgesellschaft, die einem Kind direkt angeboten werden. Nationale Regeln koennen das relevante Alter zwischen 13 und 16 festlegen. Deshalb sollte ein Team keine pauschale Altersregel fuer alle Maerkte uebernehmen.

Warum das fuer SaaS wichtig ist

Viele B2B-SaaS-Unternehmen glauben, Kinderdaten seien irrelevant, weil sie an Unternehmen verkaufen. Das kann falsch sein. Ein Kollaborationstool kann in Schulen genutzt werden. Support-Tickets koennen Informationen ueber Minderjaehrige enthalten. Education-, Health-, Gaming-, Community-, Identity- oder Productivity-Produkte koennen von Jugendlichen genutzt werden. Analytics, Aufzeichnungen, KI-Zusammenfassungen, Profiling, Geolocation und Integrationen koennen kindbezogene Risiken schaffen, auch wenn Kinder nicht die Zielkaeufer sind.

Der ICO Children's Code ist UK-spezifisch, aber operativ nuetzlich: Er schaut auf Online-Dienste, auf die Kinder wahrscheinlich zugreifen, nicht nur auf Dienste, die fuer Kinder beworben werden. Praktisch heisst das: Kinderdaten mappen, Alter bewerten, privacy-invasive Defaults vermeiden, Datenerhebung minimieren und kindbezogene Risiken als Design-Input behandeln.

Wann der Workflow greift

Frage zuerst, ob Kinder Zielnutzer, wahrscheinliche Nutzer, in Kundendaten enthalten oder indirekt in Workflows sichtbar sind. Ein Produkt kann relevant sein, obwohl der Vertrag mit einem Erwachsenen, einer Schule, einem Elternteil oder einem Unternehmenskunden besteht. Entscheidend ist, ob personenbezogene Daten ueber Kinder erhoben, abgeleitet, gespeichert, geteilt oder genutzt werden.

Typische Trigger sind Accounts fuer Minderjaehrige, Einsatz in Education- oder Youth-Kontexten, Support-Inhalte ueber Kinder, Behavioural Analytics, Empfehlungen, Werbung, Profiling, Standortdaten, Fotos, Stimmen, sensible Informationen oder Kundenfragen zur Eignung fuer Minderjaehrige. Wenn ein Trigger moeglich ist, sollte das Team vor Launch oder Kundencommitment eine fokussierte Pruefung machen.

Inventar und Altersansatz

Das wichtigste Artefakt ist ein Kinderdaten-Inventar. Es sollte zeigen, wo Kinderdaten in das Unternehmen gelangen, wer die Entscheidung besitzt und welche Evidenz existiert. Erfasse Nutzergruppe, Datenkategorien, Zweck, Rechtsgrundlage, Alterssignal, Einwilligungs- oder Elternlogik, Anbieter, Aufbewahrung, Zugriffsrechte, Notices und Evidenzort.

Alterssicherung ist eine risikobasierte Entscheidung. Der ICO-Standard zur altersgerechten Anwendung erlaubt, das Alter mit einem dem Risiko angemessenen Sicherheitsniveau festzustellen oder die Schutzstandards auf alle Nutzer anzuwenden. Fuer SaaS kann die zweite Option sauberer sein, wenn eine zuverlaessige Trennung von Erwachsenen und Kindern mehr invasive Daten erfordern wuerde.

Einwilligung und DPIA

Einwilligung ist nicht automatisch die richtige Rechtsgrundlage. Wenn sie fuer einen einem Kind direkt angebotenen Online-Dienst genutzt wird, muss Artikel 8 beachtet werden. Unterhalb des einschlaegigen Alters ist Einwilligung oder Autorisierung durch die sorgeberechtigte Person erforderlich, und der Controller muss angemessene Anstrengungen zur Verifikation unternehmen.

Die EDPB-Leitlinien erinnern daran, dass Einwilligung freiwillig, spezifisch, informiert und eindeutig sein muss. Fuer Kinder muss die Erklaerung altersgerecht verstaendlich sein. Speichere Version, Sprache, Zeitpunkt, Methode, Scope, Widerrufsweg und erforderliche Elternnachweise.

Eine DPIA sollte frueh im Produktdesign stattfinden. Sie beschreibt die Verarbeitung, prueft Notwendigkeit und Verhaeltnismaessigkeit, identifiziert kindbezogene Risiken, dokumentiert Massnahmen und zeigt, wie das Ergebnis das Produkt beeinflusst hat.

Operative Checkliste

• Mape Kinderdaten-Eintrittspunkte in Produkt, Support, Security, Analytics, KI und Vendoren.
• Klaere, ob das Unternehmen Controller, Processor oder beides ist.
• Dokumentiere Altersansatz, Rechtsgrundlage und Einwilligungslogik.
• Fuehre eine DPIA oder Product-Privacy-Review mit kindbezogenen Risiken durch.
• Setze hohe Privacy-Defaults und minimiere Daten.
• Pruefe Profiling, Werbung, Geolocation, Nudges und Sharing.
• Aktualisiere Notices fuer die relevante Altersgruppe.
• Konfiguriere Retention, Loeschung, Zugriffsrechte und Vendor-Beschraenkungen.
• Halte Evidenz so, dass Legal, Compliance, Security und Product sie finden.

FAQ

Gilt Kinderdaten-Compliance fuer B2B-SaaS?

Ja, sie kann gelten. Kinderdaten koennen ueber Bildungskunden, Support-Inhalte, Uploads, Integrationen, Analytics, KI-Funktionen oder Kundendaten verarbeitet werden.

Was sollte zuerst dokumentiert werden?

Dokumentiere Inventar, Altersansatz, Rechtsgrundlage, Einwilligungs- oder Elternlogik, DPIA-Ergebnis, Privacy-Defaults, Vendor-Risiken, Retention und Evidenz-Owner.

Was ist der groesste Fehler?

Der groesste Fehler ist, Kinderdaten-Compliance als einmalige Rechtsfrage zu behandeln, statt sie in einen wiederholbaren Workflow mit Ownern, Triggern, Evidenz und Eskalation zu uebersetzen.