When Children's Data Compliance Applies and What to Do Next

Children's data compliance applies when a SaaS product, workflow, vendor, support process, AI feature, analytics setup, or customer deployment collects or uses personal data about children. The practical answer is to identify where child data can enter the business, decide whether children are target users, likely users, or present through customer data, and turn that decision into owners, controls, and evidence.

This is broader than a signup question about age. GDPR gives children specific protection because they may be less aware of risks and rights, and Article 8 adds special conditions when consent is used for information society services offered directly to a child. In that consent scenario, children can generally consent for themselves at 16, but EU member states may set a lower age down to 13. Below the applicable age, consent must be given or authorised by the holder of parental responsibility, and the controller must make reasonable efforts to verify it.

For operators, the first move is not to debate every legal edge case in isolation. The first move is to map the product reality: who can use the service, what data is collected, how age is known or unknown, what lawful basis is used, which vendors receive data, and what product defaults apply. Then the team can decide what must change before launch, customer onboarding, procurement review, or audit.

This work connects closely to GDPR beyond cookie banners, data protection by design and default, data minimisation for SaaS, and privacy impact reviews in product planning. Children's data is not a separate universe. It is a higher-sensitivity version of the same operational discipline.

Quick Decision Rule

Use this rule: children's data compliance is in scope when children are intended users, likely users, represented in customer data, or reasonably able to appear in the workflow.

That includes direct accounts for minors, school or youth deployments, family or health use cases, community features, gaming, learning, messaging, creator tools, marketplaces, support tickets, customer uploads, recordings, forms, free-text notes, analytics events, AI prompts, and integrations that may contain information about children.

It can also apply to B2B SaaS. Selling to a company does not prove that no child data is processed. A processor may handle child data on a customer's instructions. A support tool may receive screenshots about minors. An education customer may use a generic collaboration platform with students. A customer data import may include dependants, pupils, patients, or family members.

If the answer is clearly no, record why. If the answer is yes or uncertain, run a scoped child-data review before the team ships the workflow or signs a commitment that assumes the product is suitable for minors.

When It Usually Applies

Children's data compliance usually applies in five situations.

First, the product is aimed at children or teenagers. That is the clearest case. The team should review age-appropriate notices, consent or parental authorisation where consent is used, profiling, default settings, direct marketing, geolocation, sharing, retention, and child-friendly rights handling before release.

Second, the service is likely to be accessed by children even if children are not the target buyer. The ICO Children's Code is UK-specific, but it is a useful operational reference because it covers online services likely to be accessed by children, including many for-profit online services. It makes clear that teams should consider the code when children are likely to access the service, even if they are not the intended audience.

Third, customers use the product in contexts where children's data is expected. Education, childcare, family services, youth sport, health, gaming, media, social, identity, safety, and public-sector workflows all deserve early review. In these cases the SaaS company may be a processor, a controller for some operational data, or both.

Fourth, unstructured data can include children. Support attachments, chat transcripts, call recordings, screenshots, CSV imports, documents, incident reports, community posts, and AI prompts are common blind spots. The product may not ask for child data, but the workflow can still receive it.

Fifth, the feature uses higher-risk processing such as profiling, recommendations, behavioral advertising, location tracking, public visibility, automated decisions, sensitive data, or AI analysis. Children-specific risk should be considered before these features are enabled for users who may be minors.

When It May Not Apply

Children's data compliance may be out of scope when the service is genuinely adult-only, children are not likely users, customer contracts prohibit child data, the product design makes child access unrealistic, and operational workflows do not receive information about children.

Even then, avoid relying on a policy statement alone. Keep a short decision record. It should explain the user base, customer segments, data sources, restrictions, and why child data is not expected. That record helps when procurement, security, or legal teams later ask whether the issue was considered.

If the product later expands into education, consumer communities, health, identity, family use cases, AI features, or new markets, reopen the decision. Applicability is not permanent. It follows the product, customer base, data flows, and vendors.

What To Do Next

Start with an inventory. List every place child data can enter the company: registration, customer imports, admin fields, integrations, analytics, support, security logs, recordings, AI prompts, surveys, billing notes, and vendor tools. For each entry point, capture the owner, data categories, purpose, lawful basis, age signal, vendor recipients, retention rule, access controls, and evidence location.

Then decide how age is handled. The ICO age-appropriate application standard says organisations can establish age with a level of certainty appropriate to the risks or apply the relevant protections to all users. For SaaS teams, that matters because collecting more data to verify age can create privacy risk of its own. Sometimes safer defaults for everyone are cleaner than intrusive age checks.

Next, check the lawful basis and consent model. Consent is not automatically the right lawful basis. If consent is used for an information society service offered directly to a child, Article 8 must be considered. The EDPB consent guidance also reinforces that consent must be freely given, specific, informed, and unambiguous. For children, explanations should be understandable for the expected age group.

After that, decide whether a DPIA or product privacy review is needed. A DPIA is often appropriate where children are likely users, the processing is high risk, or features involve profiling, geolocation, public visibility, AI, sensitive data, or unexpected sharing. The output should influence product design, not sit as a document after the feature is already built.

Finally, turn the review into implementation tasks. Update privacy copy, default settings, event schemas, retention jobs, deletion workflows, vendor restrictions, role-based access, support playbooks, parental authorisation evidence, customer documentation, and release gates. Assign owners and store evidence where product, legal, security, and compliance can all find it.

Evidence Buyers and Regulators Expect

Good evidence is practical. Keep the child-data inventory, age-assurance decision, lawful-basis analysis, consent or parental authorisation records, DPIA or privacy review, product tickets, notice versions, vendor review, retention configuration, deletion test evidence, access-control evidence, and approval record.

For processor scenarios, also keep customer instructions, data processing terms, subprocessors, support handling rules, and escalation paths for access or deletion requests. If the company is both controller and processor in different parts of the service, separate the evidence so the role is clear.

Evidence should answer three questions: how did the team know children were or were not in scope, what controls changed because of that decision, and how can the company prove those controls still operate?

Common Mistakes

The first mistake is assuming B2B status ends the analysis. It does not. The customer's users and uploaded data still matter.

The second mistake is treating age as a one-line gate. A simple age question does not fix profiling, sharing, tracking, retention, or privacy-invasive defaults.

The third mistake is forgetting indirect and unstructured data. Child data often appears where nobody designed a child-facing feature.

The fourth mistake is using consent without an operational withdrawal path. If the team cannot honor withdrawal cleanly across systems, consent may be fragile.

The fifth mistake is leaving evidence scattered across tickets, policies, spreadsheets, and vendor portals. Scattered evidence turns a manageable workflow into an audit scramble.

FAQ

What should teams understand about children's data compliance?

Teams should understand whether children can appear in the product or operations, what legal and product decisions that triggers, who owns the workflow, and what evidence proves the decision was implemented.

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

It applies when children are target users, likely users, present through customer data, or reasonably able to appear in product, support, analytics, vendor, AI, or operational workflows.

What should teams document first?

Start with the child-data inventory, age approach, lawful basis, consent or parental authorisation logic, DPIA decision, privacy defaults, vendor exposure, retention rules, and evidence owner.

Does every child-data review require parental consent?

No. Parental authorisation is specifically important where consent is the lawful basis for an information society service offered directly to a child below the applicable age. Other lawful bases and roles may require different controls, but the team still needs a documented decision.

Sources

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