Children's Data Compliance: Practical Guide for SaaS Teams

Children's data compliance means turning child-specific privacy requirements into product, security, vendor, support, and evidence workflows that a SaaS team can actually run. It is not only a question of whether a child can consent. A team also has to know whether children are likely to access the service, what personal data is collected, whether the product design is age appropriate, how parental authorization is handled when consent is used, and what records prove the decisions were made before launch.

The practical goal is simple: identify the child-data scenarios that can arise in your service, decide which ones are in scope, assign owners, reduce unnecessary data collection, document age and consent decisions, and keep evidence that the workflow is operating. If the product is likely to be accessed by children, the work belongs in product planning and data protection by design, not in a last-minute legal review.

Under the GDPR, children merit specific protection because they may be less aware of risks, consequences, safeguards, and rights. Article 8 creates specific conditions for consent in relation to information society services offered directly to a child, while national law can set the relevant child-consent age between 13 and 16. That means a SaaS team should avoid copying one generic age rule across every market without checking the jurisdictions it serves.

Children's data work also connects directly to GDPR beyond cookie banners, data protection by design and default, data minimisation, and privacy impact reviews during product planning. The same operating discipline applies, but the risk analysis is more sensitive because the data subjects are children.

Why children's data compliance matters in SaaS

Many B2B SaaS companies assume children's data is irrelevant because they sell to businesses. That assumption can be wrong. A collaboration platform may be used by schools. A customer-support product may receive tickets about minors. A health, education, gaming, community, creator, marketplace, HR, identity, or productivity product may be accessible to teenagers. Analytics, recording, AI summaries, profiling, geolocation, advertising, and integrations can all raise child-specific concerns even when children are not the target buyer.

The ICO's Children's Code is UK-specific, but it is a useful operational reference because it focuses on online services likely to be accessed by children, not only services aimed at them. It also makes the practical expectation clear: teams should map child data, assess age, avoid privacy-invasive defaults, minimize data, and treat child-specific risks as design inputs.

For SaaS teams, the business risk is broader than enforcement. Weak child-data controls can block school, health, public-sector, consumer, and enterprise deals. They can also create product delays when teams discover late that age assurance, parental flows, privacy notices, profiling choices, or data-sharing defaults need redesign. The earlier the team identifies child-data exposure, the cheaper the remediation usually is.

When children's data compliance applies

Start by asking whether children are target users, likely users, represented in customer data, or indirectly present in workflows. A product can be in scope even if the contract is with an adult, a school, a parent, or a business customer. The operational question is whether personal data about children is collected, inferred, stored, shared, or used.

Common triggers include:

• users under 18 can create accounts or profiles;
• customers use the service in education, youth, family, gaming, media, community, or health contexts;
• support tickets, uploads, recordings, forms, or integrations may include information about children;
• the product uses behavioral analytics, recommendations, advertising, profiling, or AI on users who may be children;
• the service asks for age, school, parent, guardian, household, location, photo, voice, biometric, or sensitive information;
• a customer asks whether the product is suitable for minors or for school deployment.

If none of these triggers apply, record the reasoning. If any trigger might apply, the team should run a scoped review before shipping the workflow or accepting the customer commitment.

Build a child-data inventory before debating edge cases

The first useful artifact is an inventory. It does not need to be a long legal memo. It should show where children's data can enter the company and who owns the decision.

For each workflow, capture the user group, data categories, collection point, purpose, lawful basis, age signal, consent or parental authorization logic, vendor recipients, retention rule, access controls, notices shown to users or parents, and evidence location. Mark whether the company is a controller, processor, or both in the relevant workflow.

This inventory should include product data and operational data. Product teams often think about signup fields and analytics, while support and customer success teams may see child data through attachments, screenshots, recordings, free-text notes, and customer imports. Security teams may hold logs or device data. AI features may create summaries, classifications, or recommendations from data that originally seemed low risk.

Decide how you know a user's age

Age assurance is not one control. It is a risk-based decision. The ICO's age-appropriate application standard says teams can either establish age with a level of certainty appropriate to the risks, or apply the relevant protections to all users. That choice is practical for SaaS: if your product cannot reliably separate adults from children without collecting more intrusive data, applying safer defaults broadly may be the cleaner design.

Document the age approach before launch. Self-declaration may be enough for some low-risk contexts, but it may be inadequate for higher-risk profiling, geolocation, messaging, advertising, or sensitive-data features. More intrusive age-assurance techniques can also create privacy risks of their own, so the decision should be justified in the DPIA or product privacy review.

The owner should be able to answer three questions: how do we know whether children are present, what protections apply when they are present, and what do we do when age is unknown?

Handle consent carefully

Consent is only one lawful basis, and it is not automatically the right one. Where consent is used for an information society service offered directly to a child, GDPR Article 8 sets specific rules. Children aged 16 and above can generally consent for themselves under the GDPR, but EU member states may lower the age to no less than 13. For children below the applicable age, consent must be given or authorized by the holder of parental responsibility, and the controller must make reasonable efforts to verify that authorization.

The EDPB's consent guidance also matters because consent must be freely given, specific, informed, and unambiguous. For children, the explanation needs to be understandable for the relevant age group. A dark pattern that nudges a child into extra tracking, sharing, geolocation, or profiling is not a strong consent model.

Operationally, store the consent version, language, timestamp, method, scope, withdrawal path, parental authorization evidence where required, and the systems affected by withdrawal. If a team cannot honor withdrawal cleanly, it should question whether consent is the right basis for that processing activity.

Use DPIAs as product design tools

The ICO Children’s Code treats DPIAs as an early design activity for online services likely to be accessed by children. The DPIA should describe the processing, assess necessity and proportionality, identify child-specific risks, document mitigations, and show how the outcome influenced the product.

For SaaS teams, this should not be a heavyweight blocker. It should be a repeatable product privacy review with child-specific questions:

• Can children access this workflow directly or indirectly?
• What data is necessary for the feature to work?
• Are privacy settings high by default?
• Are profiling, recommendations, ads, or nudges involved?
• Is geolocation off unless there is a compelling reason?
• Are explanations understandable for the expected age range?
• Are vendors receiving child data?
• What happens when a parent, school, or customer asks for deletion or access?

The strongest DPIA evidence is not a PDF alone. It is the combination of the review record, product tickets, design decisions, vendor settings, privacy copy, data retention configuration, and approvals.

Set privacy-protective defaults

Children's data compliance usually fails in product defaults. A team may have a policy saying children deserve protection while the product still enables tracking, public profiles, recommendations, data sharing, or location collection by default.

Default settings should collect only what is necessary, make child-facing explanations clear, limit visibility, restrict sharing, avoid unnecessary profiling, and make controls easy to find. Data minimisation is especially important: if a field, event, recording, or AI input is not needed for the child-safe version of the workflow, remove it or separate it from the default path.

This is where privacy engineering matters. Teams should configure analytics, event schemas, role-based access, deletion jobs, retention rules, and vendor integrations so child data is not casually copied into tools that were never reviewed for that purpose.

Common mistakes

The first mistake is assuming B2B status removes child-data exposure. A processor can still process children's data on behalf of a customer, and a vendor can still need controls, instructions, subprocessors, and evidence.

The second mistake is treating age as a banner question. Asking "Are you over 16?" may not solve the underlying design problem if the rest of the product is built around profiling, sharing, behavioral nudges, or broad data collection.

The third mistake is forgetting unstructured data. Child data often appears in attachments, chat transcripts, audio, video, free-text notes, screenshots, CSV imports, and AI prompts.

The fourth mistake is making parental consent a manual exception. If parental authorization is required, the workflow needs versioned notices, verification logic, renewal or withdrawal handling, and support playbooks.

The fifth mistake is leaving evidence scattered. Customer reviewers and regulators do not only ask what the policy says. They ask how the company knows the control works.

Practical checklist for SaaS teams

Use this operating checklist before launching or materially changing a service that may involve children:

• map child-data entry points across product, support, security, analytics, AI, and vendors;
• classify whether the company is controller, processor, or both;
• decide whether children are target users, likely users, or only present through customer data;
• choose and document the age-assurance approach;
• confirm the lawful basis for each processing purpose;
• document consent and parental authorization requirements by jurisdiction where consent is used;
• run a DPIA or product privacy review with child-specific risks;
• set high-privacy defaults and minimize collection;
• review profiling, recommendations, advertising, geolocation, nudges, and sharing;
• update notices so they are understandable for the relevant age range;
• configure retention, deletion, access controls, and vendor restrictions;
• keep evidence in a place compliance, legal, security, and product can all find.

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.

Does children's data compliance apply to B2B SaaS?

It can. B2B SaaS teams may process children's data through education customers, support content, uploaded data, integrations, analytics, AI features, or customer use cases. The contract model does not remove the need to assess the data.

What should teams document first?

Document the child-data inventory, age-assurance approach, lawful basis, consent or parental authorization logic, DPIA outcome, privacy defaults, vendor exposure, retention rules, and evidence owner.

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 guide relies on the GDPR, EDPB consent and lawful-basis guidance, and ICO Children's Code guidance on scope, DPIAs, and age-appropriate application.