# Children’s Transparency in Practice: Lessons from LEGO-Style Notices

Canonical URL: https://xpertdpo.com/children-s-transparency-in-practice-lessons-from-lego-style-notices/

Content type: Article

Published: 2026-06-25T17:44:35+01:00

Updated: 2026-06-25T17:57:12+01:00

Author: Philipa Jane Farley, Head of Legal and Operations

Summary: Child-facing privacy transparency is not just a shorter notice. DPOs and privacy teams need to test the child journey, parental routes, just-in-time notices, settings, evidence and review triggers.

## Article

*This article accompanies Hour 6: Children's Data and Online Services in our full-day CPD programme on [XpertAcademy](https://xpertacademy.com/cpd-event-a-regulatory/). Completion of the full one-hour session, including the related learning materials, contributes to the one-hour CPD certificate issued for that session. You can access the course here: [CPD Event A: Full-Day Regulatory Privacy Training](https://xpertacademy.com/cpd-event-a-regulatory/).*

 A privacy team is preparing for a product review. The online service is used by families and is likely to be accessed by children. There is a full adult privacy policy, a shorter child-facing privacy notice, a parent help page and several settings screens inside the product.

 The first read looks reassuring. The child-facing notice is friendly. The adult privacy policy is detailed. The parent help page explains account set-up. But when the privacy team compares the child-facing notice with the adult privacy policy against the actual child journey, the gaps become obvious. The child journey is unclear.

 The child-facing notice says the service uses information to keep the account working and help the child use the app. The adult policy refers to profile data, technical data, uploaded content, moderation, analytics, personalisation, support access and third-party providers. The settings screen lets a child change profile visibility, upload creations and manage notifications, but the notice does not explain what changes when those controls move. The parent route exists, but it is separate from the points where a parent might actually need to help. The product owner says the privacy notice was "simplified for children". The DPO is not sure it was made understandable.

 That is the operational problem. Child-facing transparency is not only a writing exercise. It is a journey, setting, timing and evidence exercise. A notice may be legally detailed, and still fail to help a child or parent understand what is happening at the moment a real privacy choice is made.

### Why this is a governance issue, not a copywriting issue

 Children are not expected to decode an adult privacy policy. Regulators in the UK and Ireland both frame children's data protection as something that must be designed around children's rights, development, context and practical understanding.

 The DPC's Fundamentals for a Child-Oriented Approach to Data Processing describe child-specific data protection principles and recommended measures intended to improve protection for children in both online and offline environments. The ICO Children's Code takes the same topic into online-service design. It covers services likely to be accessed by children and includes standards on transparency, high privacy defaults, data minimisation, data sharing, geolocation, parental controls, profiling, nudge techniques, connected toys and governance.

 For a DPO or privacy lead, the useful question is not "does a notice exist?" It is whether the organisation can show that children and parents receive the right information, in the right form, at the right point in the service, and that the information matches what the product actually does.

 That is especially important where the adult policy and the child journey are out of step. Adult policies often describe all processing across the organisation. Child-facing notices often describe the service in plain terms. Neither document is wrong simply because it has a different level of detail. The risk appears when the simplified notice hides, misses or blurs a material consequence of the service.

 Examples include profile visibility, uploads, friend or follower features, geolocation, push notifications, marketing preferences, personalised recommendations, behavioural analytics, AI-assisted moderation, support access, data sharing with vendors, or the use of children's data to improve the product. A child may not need the full legal architecture behind each activity. They do need enough to understand what will happen if they press the button, change the setting, upload the content, invite the friend, join the challenge or ask for help.

### What the team should do with the scenario

 In the review scenario, the privacy team should resist two unhelpful answers.

 The first is to expand the child-facing notice until it becomes a second adult policy. That may create more words without creating more understanding. The second is to leave the notice simple and rely on the adult policy for the details. That may make the evidence look tidy while leaving the child journey unclear.

 The practical route is to map the child journey against the processing. The team should take a real account set-up and use-case flow and mark the points where the child sees, creates, changes or exposes personal data. For each point, the team should ask four questions:

- What does the child think is happening here?
- What personal data is actually collected, generated, shared, inferred or made visible?
- Does the child or parent receive a clear explanation before the relevant use is activated?
- Does the setting or route give a meaningful choice, or only the appearance of one?

 This quickly turns a vague transparency concern into specific work. If profile visibility changes who can see a username, avatar, uploaded creation or activity badge, the service needs clear just-in-time wording at that setting. If uploading content triggers moderation, storage or sharing with a community, the child needs a simple explanation before upload. If push notifications involve device identifiers or parent approval, the parent route should be visible in the relevant flow, not hidden in a help centre. If a parent can monitor activity, the child needs age-appropriate information that monitoring is in place.

 The DPO's role is not to write every word. It is to make sure the design, legal basis, transparency, settings and evidence all point in the same direction.

### A LEGO-style public transparency case study

 LEGO is a useful public case study because its public privacy materials show several transparency techniques that DPOs can analyse. This is not an endorsement of every LEGO service, a compliance finding, or a suggestion that another organisation can copy LEGO wording or visual design. The point is narrower and more practical: LEGO's public materials provide visible examples of layered content, child-facing tone, parent routes and concrete action language.

 The public LEGO privacy policy includes a section labelled as child-friendly privacy information. It explains the organisation, personal data, why data may be needed, whether data can be used for anything, whether anyone else can see it, retention, rights, the DPO and routes for help in language aimed at children. It also sits alongside a more detailed adult privacy policy that describes categories of data, purposes, legal bases, cookies, accounts, digital services and rights.

 That layering is the first design lesson. The child route does not have to carry every legal detail, but it must connect honestly to the fuller account. In a review, the DPO should check whether the child-facing layer correctly reflects the adult policy. Where the adult policy says technical data, profile data, uploaded content, cookies, personalisation or support access may be involved, the child-facing layer should not reduce everything to "we use information to make things work" if that phrase would hide something a child or parent needs to know.

 The second lesson is tone. Good child-facing transparency usually sounds direct, concrete and respectful. It should avoid legal varnish, but it should also avoid speaking down to children or turning privacy into cute decoration. A child-friendly notice can use questions, short explanations and everyday examples. It should still be accurate about choice, limits and consequences.

 The third lesson is layered content beyond a single notice. A LEGO-style model is not "one colourful privacy page". It is a set of routes: an adult policy, a child-facing explanation, parent or guardian routes, contact options, cookie information and product-specific or service-specific explanations where needed. For another organisation, that might mean a child notice, a parent guide, a settings dashboard, upload prompts, a moderation explanation and a rights route that the support team can actually operate.

 The fourth lesson is the use of visual cues and icons. The ICO Children's Code expressly recognises dashboards, layered information, icons and symbols as tools that may help children understand privacy information. Icons can be useful where they consistently mark a setting, warning, parent route, upload, visibility change or data-sharing point. They are not useful if they are decorative, unexplained or inconsistent. A product team should test whether a child understands the icon's practical meaning, not simply whether the icon looks friendly.

 The fifth lesson is action language. A notice should help the child or parent act. "Ask an adult", "change this setting", "contact us", "delete this", "do not continue if you are unsure" and "this will make your profile visible" are action-shaped statements. They tell the user what can be done next. That is different from abstract assurance such as "we care about your privacy" or "we process your data safely". Assurance may be true, but it does not help a child make a privacy decision.

 For the review team in our scenario, the LEGO-style case study produces a focused risk question:

 Can a child and parent understand the main privacy consequences of the service without having to reconcile a child notice, adult policy and settings journey by themselves?

 If the answer is no, the work is not finished.

### Applying the pattern without copying it

 The safest way to use a public example is to extract the design principles and rebuild them for the actual service.

 Start with the facts the privacy team has. The service is likely to be accessed by children aged 10 to 15. Children create a profile, choose an avatar, upload content, receive recommendations, earn badges and can take part in community challenges. Parents approve account creation for younger users. The adult privacy policy says the service collects account data, profile choices, uploaded content, device data, usage analytics, moderation records and support messages. The child-facing notice explains personal data in plain language but does not mention recommendations, moderation records or what happens when an upload is public rather than private.

 Then state what is unknown. The team may not yet know whether recommendation logic uses individual behaviour or broad age bands. It may not know whether moderation vendors can access raw content, whether uploaded content is retained after deletion from the public profile, whether support staff can view child account histories, or whether analytics are used for product development. These unknowns matter because they decide what the notice, settings and DPIA need to say.

 Next, turn the unknowns into checks. Legal and privacy should confirm the purposes and lawful bases for each processing activity. Product should provide screenshots or prototypes of the settings and upload flows. Engineering should confirm what data is created and retained. Vendor owners should provide processor, subprocessor, support-access and retention evidence. Customer support should confirm how parent and child rights requests are handled. If AI-assisted moderation, recommender systems or behavioural profiling are involved, the review should include the model purpose, input data, output effect, human review, appeal route and child-specific risk controls.

 The child-facing transparency then becomes a product artefact, not only a document. For example, an upload screen might say, in child-appropriate language, that if the child posts a creation publicly, other users may be able to see the chosen display name and creation, and the service may check the upload before it appears. A settings screen might explain that changing a profile from private to visible changes who can see the child's activity. A recommendation feature might explain why certain content is suggested and whether the child can reset or turn off personalisation. A parent route might explain what a parent can approve, change, access or request, and what the child will be told when parental monitoring or controls apply.

 The adult privacy policy still matters. It should contain the fuller legal account, including categories of personal data, purposes, lawful bases, recipients, retention, rights, international transfers and contact details. But the child journey should not depend on a child or parent reading the adult policy end to end before they can understand a setting.

### Practical examples for child-facing notices and just-in-time transparency

 A useful child-facing notice usually has a small number of stable explanations and then relies on just-in-time support at high-friction points.

 For account creation, the notice should explain what information is needed to create the account, what is optional, whether a parent or guardian must approve anything, and what happens if approval is not given. If the service asks for date of birth or age band, the wording should explain why it is needed and whether the exact date is stored.

 For profile settings, the notice should explain what other users can see. It should avoid vague terms such as "public" or "community" unless the service also explains who that means. A child should be able to understand the difference between private, friends-only, classroom-only, group-only and public visibility.

 For uploads, comments and community features, the service should explain what is checked before publication, who can see the content, whether other users can respond, how to report a concern, and whether deleting the post removes it everywhere. If moderation creates a record, the adult policy and internal evidence should reflect that.

 For recommendations, personalisation or badges, the service should explain whether activity affects what the child sees next. The explanation does not need to describe the algorithm like an engineering document, but it should give a meaningful account of what behaviour changes the child's experience.

 For parental routes, the service should separate three things that are often blurred: parental consent or authorisation, parental support, and parental monitoring or controls. Consent is not the same as ongoing monitoring. Support is not the same as access to a child's private activity. If a parent can see or control something, the child may need to be told in an age-appropriate way.

 For rights routes, the service should avoid sending children into a legal maze. It should say how a child or parent can ask for data, correct something, delete something, object, withdraw consent where relevant, or raise a worry. The back-office process must match the public promise.

### The checklist the DPO should use

 This should not become a listicle, but a checklist helps keep the review honest. The DPO or privacy team should be able to answer these questions and point to evidence for each one.

- Purpose and users: Which children are likely to use or be affected by the service, what age ranges are in scope, and which parts of the service are child-facing?
- Data and sensitivity: What account data, profile data, uploaded content, technical data, usage data, location data, communications, moderation records, analytics or inferred data are created?
- Roles and suppliers: Who is controller, processor or joint controller for each purpose, and what vendors, subprocessors, support teams or hosting providers can access child data?
- Lawful basis and fairness: What lawful basis applies to each purpose, where is parental consent or authorisation required, and where would reliance on consent be weak because the child or parent has no real choice?
- Transparency and timing: Where does the child or parent receive privacy information, and is the explanation available at the point the data use is activated?
- Settings and defaults: Are privacy settings high by default where appropriate, and does the child understand the consequence of weakening a setting?
- Profiling and personalisation: Does the service use activity, interests, age, uploads or behaviour to shape what the child sees, and is that explained and controlled?
- Minimisation and retention: Is the service collecting only what it needs, and can the team explain how long child data, uploads, logs, moderation records and support records are kept?
- Parental routes and child rights: Can parents support or approve the service without erasing the child's own privacy rights, especially as the child gets older?
- Evidence and review: Is there a DPIA, decision record, user-journey map, source evidence, action log and review trigger that would survive audit or regulatory scrutiny?

 The important discipline is to write down where the answer is uncertain. A clean "not yet known" is better than a confident assumption that later proves false.

### Concrete evidence record

 After the review, the organisation should be able to produce a concise evidence pack. It does not need to be theatrical. It needs to be complete enough for a DPO, governance forum, audit team or regulator to see what was checked and why the final position was accepted.

 The record should include:

- a child transparency decision record setting out the reviewed journey, age range, main risks, decisions made and open actions;
- a marked-up child journey showing where notices, prompts, settings, parent routes and rights routes appear;
- a comparison table between the adult privacy policy and the child-facing notice, highlighting any child-relevant processing that needs clearer wording;
- screenshots or prototype captures of just-in-time notices, settings, upload prompts, parent approvals and monitoring indicators;
- DPIA notes covering children's rights, age-appropriate design, transparency, profiling, parental controls, vendor access, retention and residual risk;
- supplier evidence covering roles, subprocessors, support access, data locations, retention, deletion, security and incident handling;
- evidence of user testing or, where user testing is not proportionate, the reason that decision was made;
- an action log showing owners, deadlines and sign-off for wording, product, legal and support changes;
- a risk acceptance note for any residual risk that cannot be removed before launch or review completion;
- a review schedule and triggers, including new features, new data uses, new vendors, complaints, incidents, age-range changes, AI or recommendation changes, and material updates to regulator guidance.

 The evidence should connect. If the DPIA says profile visibility is private by default, the screenshots should show that. If the notice says parents can request deletion, the support process should make that possible. If the adult policy says data is used for personalisation, the child journey should not imply that nothing changes based on activity. If the public explanation says a child can ask for help, the contact route should be staffed and understood.

 This is where many organisations find the real issue. The privacy words may be acceptable in isolation, but the journey, settings and evidence do not yet agree with each other.

### What would trigger escalation

 The DPO should escalate where the review finds a material gap between what the service does and what children or parents are told. Escalation is also appropriate where child-facing transparency depends on an untested assumption about age, understanding, parental involvement, vendor access, profiling, retention or public visibility.

 Examples include a recommendation feature that is more personalised than the notice suggests, a public sharing setting that is not clearly explained before activation, parental monitoring that is invisible to the child, a vendor using child data for its own purposes, retention of deleted uploads without a clear reason, or a support process that cannot meet the rights route described in the notice.

 Escalation does not always mean stopping the product. It may mean narrowing the launch, turning off a feature for children, changing defaults, adding a just-in-time prompt, separating child and parent routes, completing vendor evidence, delaying personalisation, or requiring senior risk acceptance. The point is that the decision should be explicit and reviewable.

### What this means for CPD

 The CPD value in this topic is practical judgement. DPOs and privacy teams should be able to move beyond asking whether the privacy notice is friendly, and start asking whether the service is understandable, fair and evidenced for the children who will actually use it.

 The LEGO-style case study is useful because it shows transparency as a system of communication: tone, layers, icons, parent routes, action language and product-specific explanations. But the lesson is not to copy a public brand. It is to test your own service. The adult policy, child notice, settings journey, parent route, DPIA and evidence record should all describe the same reality.

 If they do, the organisation has a stronger basis for explaining its decisions. If they do not, the privacy team has found the next piece of work.

 *This article is intended to support the learning covered in Hour 6 of our [XpertAcademy](https://xpertacademy.com/cpd-event-a-regulatory/) CPD programme. The relevant CPD certificate is issued for completion of the full one-hour session on XpertAcademy, rather than for reading this article on its own. You can return to the course here: [CPD Event A: Full-Day Regulatory Privacy Training](https://xpertacademy.com/cpd-event-a-regulatory/).*

### Sources

- Data Protection Commission, Fundamentals for a Child-Oriented Approach to Data Processing: [https://www.dataprotection.ie/en/dpc-guidance/fundamentals-child-oriented-approach-data-processing](https://www.dataprotection.ie/en/dpc-guidance/fundamentals-child-oriented-approach-data-processing)
- Information Commissioner's Office, Age appropriate design: a code of practice for online services: [https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/age-appropriate-design-a-code-of-practice-for-online-services/](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/age-appropriate-design-a-code-of-practice-for-online-services/)
- Information Commissioner's Office, Transparency standard, Children's Code: [https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/age-appropriate-design-a-code-of-practice-for-online-services/4-transparency/](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/age-appropriate-design-a-code-of-practice-for-online-services/4-transparency/)
- Information Commissioner's Office, Parental controls standard, Children's Code: [https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/age-appropriate-design-a-code-of-practice-for-online-services/11-parental-controls/](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/age-appropriate-design-a-code-of-practice-for-online-services/11-parental-controls/)
- European Data Protection Board, GDPR guidelines, recommendations and best practices hub supplied in the brief: [https://www.edpb.europa.eu/our-work-tools/general-guidance/gdpr-guidelines-recommendations-best-practices_en](https://www.edpb.europa.eu/our-work-tools/general-guidance/gdpr-guidelines-recommendations-best-practices_en)
- LEGO Group, Privacy Policy and child-friendly privacy information: [https://www.lego.com/en-gb/legal/notices-and-policies/privacy-policy](https://www.lego.com/en-gb/legal/notices-and-policies/privacy-policy)

## General Information Only

This article is provided for general information and does not constitute legal, regulatory, or professional advice. Data protection obligations depend on the specific facts, context, and jurisdiction involved. You should not rely on this content as a substitute for advice tailored to your organisation.

If you would like support with a specific issue, please contact us: https://xpertdpo.com/contact/