Common Children's Data Compliance Mistakes SaaS Teams Still Make

Children's data compliance usually breaks when a SaaS team treats it as a narrow legal question instead of an operating workflow. The recurring mistakes are practical: assuming B2B products are out of scope, ignoring support and uploaded content, relying on weak age checks, choosing consent without a working withdrawal path, leaving vendors out of the review, and failing to keep evidence that shows what the team decided before launch.

The fix is not to make every product release slow. It is to make child-data exposure visible early, assign owners, decide the lawful basis and age approach, set protective defaults, review vendors, and store evidence in a place the team can use during customer diligence, audit preparation, product review, or regulatory scrutiny.

Under the GDPR, children merit specific protection because they may be less aware of risks, consequences, safeguards, and rights. Article 8 adds specific conditions where consent is used for information society services offered directly to a child, and EU member states can set the relevant child-consent age between 13 and 16. The ICO Children's Code is UK-specific, but its operational framing is useful because it focuses on online services likely to be accessed by children, DPIAs, age-appropriate application, high-privacy defaults, and design choices.

This article builds on the children's data compliance practical guide, the children's data compliance checklist, data protection by design and default, data minimisation, and privacy impact reviews during product planning.

Mistake 1: Assuming B2B means children are irrelevant

Many SaaS teams start from the sales model instead of the data reality. They sell to companies, schools, healthcare providers, communities, or platforms, so they assume children's data is someone else's problem. That assumption can fail quickly.

Children may appear in customer uploads, classroom use, family accounts, support tickets, screenshots, recordings, community content, identity workflows, health notes, media files, analytics data, or AI-generated summaries. A company can also process children's data as a processor on customer instructions. The fact that the buyer is an adult or organization does not prove that minors are absent from the workflow.

Better practice is to ask whether children are target users, likely users, represented in customer data, or indirectly present in operations. If the answer is no, record the reasoning. If the answer is maybe, define the owner and review path before sales, product, or support makes commitments the rest of the company cannot support.

Mistake 2: Looking only at the signup screen

Signup is only one entry point. Child data often appears after onboarding, especially in B2B and workflow products.

Teams miss:

• support tickets with screenshots, attachments, transcripts, recordings, or free-text notes;
• customer imports, CSV files, documents, and profile fields;
• analytics events, logs, audit trails, and security telemetry;
• AI prompts, outputs, classifications, summaries, and evaluation data;
• integrations, exports, warehouses, backups, and admin tools;
• vendor systems used by support, product analytics, communications, and customer success.

The practical control is a child-data inventory that follows the data across systems. If the review stops at the public UI, the company may miss the places where sensitive operational risk actually lives.

Mistake 3: Treating age checks as a banner problem

Age assurance is not solved by a simple checkbox that asks whether someone is old enough. Some services can reasonably use self-declaration; others need stronger assurance or protective defaults for all users. The right approach depends on the risk, the feature, the user group, and the consequences of getting age wrong.

The ICO age-appropriate application standard gives teams a useful operational choice: establish age with a level of certainty appropriate to the risks, or apply the relevant protections to all users. That matters for SaaS teams because collecting more intrusive age evidence can create new privacy and security risks.

The mistake is treating age as a one-time gate while the rest of the product still allows profiling, broad sharing, geolocation, behavioral nudges, unnecessary data collection, or unclear notices. The age decision should connect to product defaults, consent logic, data minimisation, support workflows, and evidence.

Mistake 4: Choosing consent without an operating model

Consent is not automatically the right lawful basis. Where consent is used for an information society service offered directly to a child, GDPR Article 8 can require parental authorization below the applicable national age. The EDPB consent guidance also stresses that consent must be freely given, specific, informed, and unambiguous.

The common mistake is recording "consent" in a register while the product cannot prove consent version, language, timestamp, scope, parental authorization, withdrawal path, or downstream effects. If withdrawal cannot be honored across product data, vendors, logs, exports, support records, and AI outputs where required, the consent model is weak.

Teams should decide lawful basis by purpose. Necessary service processing, security, legal obligations, customer instructions, and optional personalization may need different analyses. A single blanket answer rarely survives review.

Mistake 5: Forgetting child-specific DPIA questions

A generic privacy review may not surface child-specific risks. The same feature can look ordinary for adults and materially different for children, especially where profiling, recommendations, geolocation, messaging, public visibility, ads, nudges, or sensitive inferences are involved.

A child-specific DPIA or product privacy review should ask:

• Can children access this service directly or indirectly?
• What personal data is necessary for the feature?
• Are defaults privacy-protective for the expected user group?
• Are explanations understandable for the relevant age range?
• Are profiling, recommendations, ads, geolocation, or nudges involved?
• Can parents, schools, customers, or children exercise rights through a workable process?
• Do vendors receive data that creates extra exposure?

The evidence should show how the review changed the product. A DPIA that does not affect defaults, notices, access, vendor choices, retention, or launch conditions is often just paperwork.

Mistake 6: Leaving vendors out of the child-data path

Child data can flow into infrastructure, analytics, AI, support, email, chat, customer success, logging, monitoring, billing, and data warehouse tools. Vendor risk is not separate from children's data compliance.

Teams often forget to check whether a vendor can support the required restrictions, deletion behavior, retention period, subprocessors, transfer terms, access controls, and evidence. AI and analytics vendors need extra scrutiny when they use data for training, product improvement, profiling, or derived outputs.

The stronger workflow maps which vendors receive or access child data, confirms the purpose, checks DPAs and subprocessors, verifies deletion and retention behavior, and records what the vendor can provide during a customer review or audit.

Mistake 7: Keeping risky defaults because they are convenient

Children's data compliance often fails in defaults, not policies. A team may publish a careful privacy statement while the product still enables public profiles, broad sharing, excessive analytics, geolocation, recommendations, advertising, or internal access by default.

Protective defaults should limit visibility, reduce unnecessary collection, restrict exports, narrow internal permissions, define retention before collection, and make explanations clear at the moment they matter. Optional features that increase exposure should require a deliberate decision.

This is where data minimisation and data protection by design and default become operational. If a field, event, integration, or AI input is not necessary for the child-safe workflow, remove it, delay it, aggregate it, mask it, or route it through a higher review.

Mistake 8: Treating support as an afterthought

Support and customer success teams often see child data before legal or product teams do. They receive attachments, screenshots, transcripts, complaints, access requests, deletion requests, school questions, parental questions, and customer commitments.

The mistake is giving support a privacy mailbox and no practical playbook. Agents need to know how to identify child-data issues, authenticate requesters, separate customer-controller instructions from direct-user requests, avoid overpromising, and escalate to legal, privacy, security, or the customer owner.

Support workflows should also cover deletion paths, vendor references, evidence capture, and response timing. A real ticket should not be the first time the company decides how parental, school, customer, or child requests will be handled.

Mistake 9: Scattering evidence across tickets and chat

Customer reviewers, auditors, and regulators do not only ask what the policy says. They ask how the company knows the control works.

Weak evidence usually looks like scattered product tickets, Slack decisions, outdated spreadsheets, one-off legal notes, and screenshots no one can find. Strong evidence shows the scope decision, role assessment, lawful basis, age approach, consent or parental authorization logic, DPIA outcome, default settings, vendor review, retention and deletion rules, support playbook, approvals, accepted risks, and follow-up dates.

The evidence does not need to be elaborate. It needs to be complete enough that the company can explain the decision without reconstructing it from memory.

Mistake 10: Letting old decisions become permanent

Children's data compliance changes when the product changes. A feature that was low risk at launch may become higher risk after the team adds AI summaries, analytics expansion, public sharing, school customers, new markets, geolocation, or a new vendor.

The mistake is treating the first review as permanent. Teams should reopen the record when product behavior, data categories, user groups, vendors, customer commitments, retention, access, or AI use changes. Follow-up dates should have owners and escalation paths, otherwise temporary mitigations become silent gaps.

FAQ

What should teams understand about children's data compliance?

Teams should understand when children's data can enter the product or operations, what legal and design decisions are triggered, who owns those decisions, and what evidence proves the workflow is running.

When does children's data compliance apply to SaaS teams?

It can apply when children are direct users, likely users, represented in customer data, or indirectly present in support, uploads, analytics, AI, integrations, school deployments, family workflows, or customer commitments.

What should teams document or change first?

Start with scope, role, data inventory, age-assurance approach, lawful basis, consent or parental authorization logic, DPIA outcome, defaults, vendor exposure, support routing, retention, deletion, and evidence ownership.

What is the biggest mistake teams make?

The biggest mistake is treating children's data compliance as a one-time legal interpretation instead of translating it into a repeatable workflow with owners, triggers, evidence, and escalation paths.

Sources

This article relies on the GDPR, EDPB consent and lawful-basis guidance, and ICO Children's Code guidance on scope, DPIAs, and age-appropriate application.