DPIA for Children’s Data Guide 2026

A DPIA for children’s data is the assessment organizations carry out before offering a product, service or feature likely to be used by children, so that risks to young people are found and reduced before launch. Children are treated as vulnerable in data protection law because they may be less aware of risks, consequences and their rights, and services aimed at or likely to be used by them attract close regulatory attention. This guide explains when a DPIA for children’s data is needed, what the law expects, how to apply the best interests of the child, how to handle age assurance and consent, which risks to assess and which safeguards are common, and how to keep the assessment current.

Why children’s data needs particular care

Recital 38 of the GDPR states that children merit specific protection with regard to their personal data, because they may be less aware of the risks, consequences and safeguards concerned and their rights. Article 8 sets conditions for a child’s consent in relation to information society services offered directly to a child, with an age of digital consent between 13 and 16 depending on the member state, and requires reasonable efforts to verify parental authorization for younger children. Where processing relies on legitimate interests, the balancing test must give proper weight to the child’s interests, as Article 6(1)(f) refers specifically to children. Our guide to verifiable parental consent explains how consent from a parent works.

In the United Kingdom, the Information Commissioner’s Age Appropriate Design Code, also called the Children’s code, sets out fifteen standards for online services likely to be accessed by children, and requires a DPIA for such services. See the ICO’s children’s information guidance. Other jurisdictions have adopted comparable rules, so check those that apply to you.

When a DPIA for children’s data is needed

Article 35 requires a DPIA when processing is likely to result in a high risk, and regulators’ lists often treat the data of vulnerable individuals, including children, as an aggravating factor that pushes ordinary processing into the high-risk category. Combined with other factors, such as profiling, large scale, innovative technology or tracking of behavior, most services aimed at children will need one. So will general services with a significant child audience, such as games, social platforms, video services and educational tools. Our guide to when a DPIA is required explains the screening factors, and the DPIA overview gives the general method.

Applying the best interests of the child

The children’s code makes the best interests of the child a primary consideration in design, drawing on the United Nations Convention on the Rights of the Child. In practice, the assessment should ask whether the service could harm children’s physical or mental health, well-being, development, privacy or safety, and whether the design puts commercial interests ahead of them. Consider the age range of users and their different developmental stages, since a design that suits teenagers may be inappropriate for seven-year-olds. Involve people with expertise in child development, and where feasible, children and parents, in identifying risks.

Risks to assess in a DPIA for children’s data

Risk	Example	Typical safeguard
Excessive data collection	Collecting location or contacts that the feature does not need	Minimize, off by default
Profiling and targeting	Behavioral ads or recommendation loops that encourage prolonged use	Switch off profiling by default, no targeted ads to children
Nudge techniques	Design that pushes children to weaken privacy settings or stay longer	Neutral choices, no dark patterns
Disclosure to others	Profiles visible to strangers, public sharing by default	Private by default, easy controls
Geolocation	Location shared with other users	Off by default, clear indicator when on
Contact by strangers	Direct messaging with unknown adults	Restrict contact, reporting tools
Understanding	Privacy notices children cannot follow	Age-appropriate, layered, just-in-time notices
Data sharing	Passing data to third parties for marketing	No sharing unless compelling reason and safeguards

Age assurance and consent

You need a proportionate way to know, or estimate, the age of users. Options range from self-declaration for low-risk services, through age estimation and account signals, to verification with documents or third-party tools for higher-risk services. Pick a method in proportion to the risk, and assess the privacy impact of the method itself, since collecting identity documents from children creates its own risk. Where you rely on consent and the child is below the relevant age, you must make reasonable efforts to verify parental authorization. Record the choice and the reasons.

Default settings and design

The children’s code expects high privacy settings by default, unless there is a compelling reason for a different default in the best interests of the child. That means profiles are private, location sharing is off, profiling for advertising is off and data collection is limited to what the service needs. Do not use design that steers children to give up privacy, and give clear ways to change settings. Our guide to privacy by design risk assessment explains how to test defaults as part of design.

Transparency in language children can follow

Tell children what you do with their data in a way suited to their age. Use short sentences, plain words, icons, videos or interactive explanations, and show information at the point where it matters. Provide fuller information for parents. Test notices with the intended audience. A long legal policy that no eight-year-old could read does not meet the transparency principle.

Safeguards, residual risk and consultation

Add the measures the assessment identifies, and rate the residual risk. Seek advice from the data protection officer, and consider the views of parents, children and child protection specialists. If a high risk remains and you cannot reduce it, prior consultation with the supervisory authority is required before processing starts. Our articles on DPIA residual risk and DPIA prior consultation explain the process.

A short worked example

A company plans a learning app for children aged eight to twelve. The DPIA finds that the design would collect precise location, show leaderboards with full names and offer personalized in-app purchases. The team removes location, uses avatars and first names in leaderboards, turns off personalized promotion, adds parental controls for purchases and messaging, and writes short illustrated privacy explanations. Age is assured through parent-created accounts. The data protection officer advises, the product owner accepts the residual risk as low to medium, and the DPIA is scheduled for review after six months of use and before any new social features.

Working with parents, schools and other adults

Many services for young people are used through a parent, guardian or school. Decide who is the controller in each case, since a school that chooses an app may act as controller while the supplier is a processor, and record the arrangements. Provide parents with clear information and controls, but avoid designs that give adults unrestricted access to a teenager’s private communications without regard to the child’s developing autonomy. The DPIA for children’s data should weigh these interests explicitly.

Keeping the DPIA under review

Children’s use changes quickly. Review the assessment when new features are added, when the audience changes, after incidents or complaints, and at planned intervals. Monitor indicators such as reports from young users and parents, the share of accounts with default settings changed and any contact from regulators. Keep records of the assessment, advice, decisions, testing and review dates. The DPIA example shows a complete record.

Common mistakes with a DPIA for children’s data

Organizations assume that a service is not aimed at children and never test, rely on self-declared age without considering risk, set high-sharing defaults, write notices for adults, profile children for advertising, collect more than necessary and fail to review after launch of new features. Another mistake is treating the assessment as only about consent. Consent does not make excessive or harmful processing acceptable.

Using a ready structure

If you want a structured starting point, the DPIA Report and Workbook provides a structured report with risk scoring and a working register that you can adapt for services used by young people. Whichever tool you use, complete the DPIA for children’s data before launch and keep it under review.

DPIA for children’s data FAQ

Is a DPIA always required for services used by children?

Not always, but data of vulnerable individuals such as children usually raises the risk, and most services aimed at or widely used by children will meet the criteria for a DPIA. In the UK the children’s code requires one for relevant services.

What is the age of digital consent?

Under Article 8 of the GDPR it is 16 by default, but member states may set it lower, down to 13. Check the age in each country where you operate.

Do I have to verify age?

You need a proportionate method to know or estimate age where it matters, chosen according to the risk of the service, and reasonable efforts to verify parental authorization where required.

What default settings should apply?

High-privacy defaults, such as private profiles, location off and no behavioral profiling for advertising, unless there is a compelling reason in the child’s best interests.

Can I use legitimate interests for children’s data?

Possibly, but the balancing test must give proper weight to the child’s interests, and processing that exploits or harms children is unlikely to pass.