Children's Data Compliance Checklist for Founders and Compliance Leads

Children's data compliance is ready for review when a SaaS team can show where children's data may enter the business, why the processing is lawful, what safeguards apply, who owns each decision, and where the evidence lives. The checklist should turn child-specific privacy requirements into product, support, vendor, security, and audit work that can be repeated without a last-minute scramble.

The point is not to make every release heavy. The point is to make the child-data question visible early enough that founders, product leaders, compliance owners, legal, security, and operations can decide whether a workflow is out of scope, low risk, or needs deeper review. 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.

Use this checklist when the product may be used by children, is sold into education or family contexts, receives customer data about minors, uses profiling or AI on user content, or needs to answer customer and audit questions about child-data safeguards. It builds on the children's data compliance practical guide, data protection by design and default, data minimisation, and GDPR beyond cookie banners.

1. Confirm whether children are in scope

Start with the business reality, not the contract label. A B2B SaaS product can still process children's data if customers use it in schools, youth services, gaming, healthcare, communities, family workflows, identity, support, analytics, or uploaded content.

Check:

• whether children can create accounts, profiles, messages, uploads, recordings, tickets, or other content;
• whether adult users, schools, parents, guardians, or customers can enter data about children;
• whether support, sales, customer success, or professional services may receive screenshots, attachments, call notes, CSV imports, or free-text data about minors;
• whether analytics, AI summaries, recommendations, geolocation, advertising, or profiling can apply to users who may be children;
• whether a customer has asked whether the service is suitable for minors, school deployment, family use, or youth-related data.

If children are not in scope, record the reasoning. If they may be in scope, keep going and assign an owner before the review becomes a launch blocker.

2. Identify the company's role

Decide whether the company is acting as controller, processor, or both for each child-data workflow. This affects who decides the purpose, who gives instructions, who handles rights requests, who communicates notices, and who keeps the evidence.

Check:

• customer-controlled product data processed under customer instructions;
• direct-to-user account, marketing, billing, analytics, security, or support data;
• school, parent, guardian, or employer workflows where responsibilities may differ;
• vendor relationships where the company passes child data to subprocessors;
• AI or analytics workflows that create derived data from customer content.

Do not hide role uncertainty in a generic privacy note. If the role depends on the workflow, document the split and make sure contracts, notices, and internal playbooks match it.

3. Map the data and systems

Create a plain inventory before debating edge cases. The inventory should show what child data can enter, where it is stored, who can access it, and where it flows next.

Capture:

• account, profile, age, school, parent, guardian, household, image, audio, location, device, and contact data;
• messages, files, forms, support tickets, transcripts, screenshots, recordings, and imports;
• analytics events, logs, audit trails, telemetry, AI prompts, outputs, labels, and summaries;
• vendors, subprocessors, data warehouses, backups, exports, integrations, and admin tools;
• retention rules, deletion paths, access groups, and evidence locations.

The inventory should include operational systems, not only the product database. Child data often appears first in support or customer-import workflows.

4. Decide how age is assessed

Age assurance is a risk-based design decision. The ICO Children's Code says services can establish age with a level of certainty appropriate to the risks, or apply child protections to all users. For SaaS teams, broad protective defaults may be simpler than collecting more intrusive age data.

Check:

• whether self-declaration is enough for the risk level;
• whether age is unknown and protections should apply by default;
• whether school, parent, guardian, or customer context changes the assessment;
• whether higher-risk features need stronger assurance before use;
• whether the age method creates extra personal data or security risk;
• how the team records the decision and reviews it later.

The owner should be able to answer: how do we know whether children are present, what happens when age is unknown, and which safeguards apply when a child may be involved?

5. Confirm lawful basis and consent logic

Do not treat consent as the automatic answer. The team needs a lawful basis for each processing purpose. Where consent is used for an information society service offered directly to a child, GDPR Article 8 may require authorization from the holder of parental responsibility for children below the applicable national age.

Check:

• the processing purpose and lawful basis for each workflow;
• whether consent is freely given, specific, informed, and unambiguous;
• whether notices and choices are understandable for the expected age group;
• whether parental authorization is required, how it is verified, and where evidence is stored;
• whether withdrawal can be honored across product, vendors, logs, exports, and support data;
• whether another lawful basis is more appropriate for necessary service, security, or legal obligations.

If the team cannot explain how consent is collected, versioned, withdrawn, and respected, do not rely on consent until the workflow is operational.

6. Run a child-specific DPIA or product privacy review

The ICO Children's Code treats DPIAs as early design work for online services likely to be accessed by children. Even where the UK code is not directly applicable, the operational pattern is useful: identify child-specific risks, document mitigations, and show how the review changed the product.

Check:

• whether the workflow is likely to be accessed by children;
• whether the data is necessary and proportionate;
• whether profiling, recommendations, ads, geolocation, nudges, or sharing are involved;
• whether high-privacy defaults are technically enforced;
• whether notices, settings, and support flows are age appropriate;
• whether vendors receive child data and can support the safeguards;
• whether residual risk has a named owner and decision date.

Evidence should include tickets, design decisions, test results, vendor records, privacy copy, and approvals, not just a saved PDF.

7. Set protective defaults

Children's data compliance often fails in defaults. A policy can say the company protects children while the product still enables broad visibility, tracking, public profiles, geolocation, profiling, or data sharing.

Check:

• public visibility, searchability, sharing, and exports are limited by default;
• optional analytics, recommendations, advertising, geolocation, and AI features are off or tightly scoped where needed;
• internal access starts narrow and expands only by role, approval, or customer instruction;
• age-appropriate explanations appear before relevant choices;
• retention and deletion behavior is defined before collection begins;
• settings cannot quietly override customer, parental, school, or legal commitments.

Default settings should reflect necessity, not convenience. If the safer default makes the product harder to use, document the trade-off and escalation decision.

8. Review vendors and subprocessors

Child data does not stop at the application boundary. Infrastructure, support, analytics, AI, messaging, payments, security, and data warehouse tools may all receive or expose it.

Check:

• which vendors can receive, access, store, log, or infer child data;
• whether contracts, DPAs, subprocessors, transfer terms, and security evidence are current;
• whether vendor retention, deletion, backup, and access behavior matches the company's commitments;
• whether AI or analytics vendors use data for training, product improvement, or secondary purposes;
• whether customer instructions limit vendor use cases;
• what evidence the vendor can provide during an audit or customer review.

If a vendor cannot support the child-data workflow, the team should either change the vendor path, reduce the data, or block the feature until the risk is accepted.

9. Prepare rights, support, and deletion workflows

Founders and compliance leads should test the operational path before a real request arrives. Child-data questions often reach support first, not legal.

Check:

• who handles access, correction, deletion, objection, restriction, and portability requests;
• how parent, guardian, school, customer, and child requests are authenticated and routed;
• how customer-controller instructions are separated from direct-user requests;
• how deletion reaches backups, vendors, logs, exports, AI outputs, and support attachments where required;
• what support agents can say without making legal commitments;
• which issues need escalation to legal, privacy, security, or the customer owner.

The playbook should be specific enough that a support ticket does not become the first time the company decides how the control works.

10. Store audit evidence and owners

The checklist is complete only when the team can prove the work happened. Evidence should be findable by compliance, legal, security, product, and operations without reconstructing decisions from chat history.

Store:

• the child-data scope decision and owner;
• role assessment, lawful basis, consent, and parental authorization records;
• data inventory, system map, vendor review, and transfer evidence;
• DPIA or product privacy review outcome;
• default-setting decisions and test results;
• access, retention, deletion, and rights-request playbooks;
• unresolved risks, accepted trade-offs, follow-up dates, and escalation paths.

Review the record when the product adds new data, vendors, AI features, analytics, geolocation, customer segments, school deployments, support workflows, or markets. Children's data compliance is a living control, not a launch artifact.

FAQ

What should teams understand about children's data compliance?

Teams should understand whether 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 safeguards are working.

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

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

What should teams document first?

Document the scope decision, company role, data inventory, age-assurance approach, lawful basis, consent or parental authorization logic, DPIA outcome, defaults, vendors, retention, deletion, 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 checklist relies on the GDPR, EDPB consent and lawful-basis guidance, and ICO Children's Code guidance on scope, DPIAs, and age-appropriate application.