If your digital service is "likely to be accessed" by anyone under 18, the Age Appropriate Design Code applies to you, and it carries the full weight of the Data Protection Act 2018. This is statutory guidance, not a voluntary charter, and it binds UK and non-UK controllers alike. Right now, you need high privacy settings by default, geolocation switched off unless proven necessary, zero nudge techniques pushing children toward oversharing, and a documented, risk-based reason for every design decision that touches a child's data.
TL;DR:
- The Code applies to any digital service likely accessed by children under 18, including general retail apps and social features, not just youth-targeted apps.
- Default privacy settings must be high by design, geolocation turned off unless necessary, and all nudging techniques pressuring children into oversharing are prohibited.
- Evidence-based documentation covering user segmentation, decision logs, and risk assessments is essential to demonstrate compliance and withstand ICO scrutiny.
- Retrofitting privacy defaults post-launch costs more and is less effective than integrating standards into the initial discovery, design, and development phases.
- Services should use their existing product development processes to incorporate the 15 standards early, avoiding costly fixes and ensuring children's welfare remains a priority.
Table of Contents
- What is the Age Appropriate Design Code and who must follow it?
- The 15 standards: a practical checklist for product teams
- How do you know if children are "likely to access" your service?
- What design and engineering changes does compliance actually require?
- What records prove compliance, and what does ICO enforcement look like?
- Building the Code into product discovery and delivery
- A practitioner's view on designing for children's best interests
- Getting Code-ready without slowing your roadmap down
- Where to check the detail yourself
- Sources
- FAQ
What is the Age Appropriate Design Code and who must follow it?
The Code, widely known as the Children's Code, exists because section 123 of the Data Protection Act 2018 instructs the Information Commissioner to prepare statutory guidance on age-appropriate design. The ICO published the resulting Code and enforces it under UK GDPR. It is technology-neutral by design. The explanatory memorandum is explicit that the Code sets flexible standards rather than fixed technical prescriptions, which means you map principles onto your own architecture instead of hunting for a checkbox solution.
Scope hinges on one phrase: "information society services likely to be accessed by children." That catches far more than apps marketed to under 18s. A general retail app, a fitness platform, or a recruitment tool can fall in scope the moment its user base plausibly includes children, regardless of intended audience.
Key scope points worth pinning to your compliance file:
- The Code applies to UK controllers and to non-UK controllers processing data belonging to children in the UK.
- Schools and colleges processing personal data for educational purposes generally sit outside scope.
- The "best interests of the child" principle sits above ordinary commercial trade-offs, meaning engagement metrics don't override a child's welfare when the two conflict.
That last point reshapes product decisions that would otherwise be routine, from notification frequency to how a signup flow collects age data.
The 15 standards: a practical checklist for product teams
The final Code document sets out 15 standards. Treat each as an audit item with a concrete check, not an abstract principle to admire from a distance.
- Best interests of the child. Check: does any feature knowingly trade a child's welfare for engagement or revenue? Example: a rewards mechanic that encourages compulsive return visits.
- Age-appropriate application. Check: have you assessed the age range likely to access the service and adjusted accordingly?
- Transparency. Check: is your privacy notice written so a child can understand it, not just a lawyer?
- Default settings. Check: is privacy set to "high" out of the box, with no action required from the user?
- Data minimisation. Check: does every field you collect have a clear, necessary purpose?
- Geolocation. Check: is location tracking off by default, with an obvious, temporary way to switch it on?
- Nudge techniques. Check: does any UI pattern pressure a child into weaker privacy choices?
- Parental controls. Check: are controls visible to the child using them, not just the parent?
- Profiling. Check: is profiling off by default unless a compelling reason and safeguard exist?
- Online tools. Check: do reporting and blocking tools actually work and get used?
- Data sharing. Check: is third-party sharing minimised and justified?
- Retention. Check: is there a defined deletion point, not indefinite storage?
- Data protection impact assessments. Check: has a DPIA been completed and kept current?
- Recordkeeping. Check: can you evidence every decision above?
- Testing and review. Check: is the service tested with actual assumptions about child users, not adult proxies?
Profiling, nudge techniques, and retention cause the most breaches in practice, largely because they hide inside growth and engagement work rather than sitting in an obvious privacy setting.
Pro Tip: Run your entire signup and upsell funnel through the lens of standard seven alone. Confirmshaming copy, forced continuity on trials, and persistent "just one more thing" banners are all audit failings against the nudge techniques standard. They're usually built by a growth team with no idea the Code exists.
How do you know if children are "likely to access" your service?
The ICO doesn't require certainty, only a reasonable, evidenced judgement. Several operational signals should trigger scrutiny before you conclude a service sits outside scope:
- Age-related metrics from analytics platforms showing a meaningful proportion of under 18 users.
- App store category or content rating that skews toward general or family audiences.
- Search terms and referral sources suggesting younger users are finding the service.
- Social features, such as chat or user-generated content, that appeal disproportionately to children.
If you conclude children are "not likely" to access your service, document why. Regulators expect evidence such as age-verification data, market research, or content restrictions, not a one-line assumption in a meeting note. A common practical failure is exactly this: firms skip the paper trail and have nothing to show when asked.
Fold this into your DPIA rather than treating it as a separate exercise. Map every data flow, segment users by age or developmental stage where feasible, rate the risk each flow poses to a child, and list the mitigation for each rated risk. 5Rights Foundation's analysis of the Code reinforces that this segmentation, thinking in developmental stages rather than a single "child" category, produces far more defensible design decisions than a blanket approach.
What design and engineering changes does compliance actually require?
Translating the standards into a build backlog looks like this:
- Privacy by default. Set every new account to the highest privacy configuration available, and make that setting persist through app updates and re-installs, not just first launch.
- Geolocation off. Disable location services on account creation, and require an explicit, time-limited opt-in with a visible indicator whenever it's active.
- Remove nudge techniques. Audit onboarding, checkout, and account-deletion flows for confirmshaming, forced continuity, and persistent banners nagging users to reduce their privacy protections.
- Default profiling off. Personalised feeds and targeted content should require an active choice from the user; where profiling supports a core function, degrade gracefully rather than blocking the feature entirely.
- Minimise and shorten retention. Cut default retention windows and anonymise data as soon as its operational purpose ends.
Pro Tip: Treat the Livingstone et al. child rights by design research as a design brief, not academic reading. Building flexibility for older versus younger children into a single feature usually costs less than retrofitting two age tiers after launch.
What records prove compliance, and what does ICO enforcement look like?
Keep a compliance file that would survive an ICO request without a scramble. At minimum: your DPIA, a current data map, design specifications showing default settings, decision logs explaining trade-offs, test results, snapshots of default configurations at release, and copies of user-facing privacy communications.
Write the "best interests" reasoning directly into functional specifications, not just a compliance memo nobody on the product team reads. A single sentence in a Jira ticket, explaining why a feature defaults to privacy-protective behaviour, does more for governance than a standalone policy document filed away and forgotten.
The ICO holds substantial enforcement powers under UK GDPR, including reprimands, enforcement notices, and fines. Recent regulatory attention has focused on social platforms and gaming services with weak default settings and aggressive engagement mechanics, exactly the pattern standards four and seven are built to prevent.
Building the Code into product discovery and delivery
The cheapest place to fix a Code breach is before a single screen gets built. In discovery workshops, map each of the 15 standards against the user journeys you're designing, then bake the relevant checks into acceptance criteria before prototyping starts.
- Discovery outputs should flag every journey touching a child's data, not just the obviously child-facing ones.
- Sprint acceptance criteria should include Code checks alongside functional requirements, with automated regression tests catching any reintroduction of a fixed nudge pattern or a default setting drifting back to "low privacy."
- Documenting trade-offs and mitigations at the design stage, rather than retrofitting them post-launch, consistently costs less in engineering time and legal risk.
Teams using a structured discovery, design, development and deployment process tend to catch these issues before they reach a sprint board, which is a far cheaper place to solve them than production.
A practitioner's view on designing for children's best interests
Most product teams don't set out to harm children; they simply optimise for engagement without asking who's on the other end of the screen. The Code forces that question back into every design review, and that's uncomfortable precisely because it should be. Treating the 15 standards as a governance exercise misses the point. They work best woven into the same discovery and delivery process you already run for accessible design, not bolted on afterwards.
— Paul
Getting Code-ready without slowing your roadmap down
Retrofitting privacy defaults after launch costs more in engineering hours than building them in from the first sprint, and that gap can be closed by specialized app development teams working against the Age Appropriate Design Code. Our Discover, Design, Develop and Deploy process maps the 15 standards onto your actual user journeys during discovery, before a single screen gets built, so privacy-by-default settings, geolocation controls, and nudge-free flows are specified as acceptance criteria rather than a post-launch fix.
If you already have a live product and need a faster read on where it stands, a Mobile App Clinic gives you a focused session to identify Code gaps, from default settings to profiling risks, without committing to a full build. It's also worth pairing privacy work with data privacy best practice for developers, since strong data handling and Code compliance tend to reinforce each other. As one industry analysis of SMB digital presence notes, most users judge trustworthiness by design quality alone, which is exactly what privacy-conscious defaults signal. Book a discovery call through the process page, or start with an App Clinic session if you need answers this month rather than next quarter.
Where to check the detail yourself
- The ICO's guidance page is the best starting point for practical steps.
- Section 123 of the Data Protection Act 2018 gives you the statutory text itself.
- The final Code document sets out all 15 standards in full.
- 5Rights Foundation offers a children's rights perspective on interpretation.
Sources
- Age appropriate design: a code of practice for online services | ICO
- Data Protection Act 2018, section 123
- Final age-appropriate design code of practice (PDF)
- Explanatory memorandum to the Age Appropriate Design Code
FAQ
Does the Age Appropriate Design Code apply outside the UK?
Yes. Any controller, UK-based or not, processing personal data belonging to children in the UK must follow the Code, regardless of where the company is registered.
Are schools exempt from the Children's Code?
Schools and colleges are generally exempt when processing personal data strictly for educational purposes, as set out in the final Code document.
What happens if my service breaches the Code?
The ICO can issue reprimands, enforcement notices, or fines under UK GDPR, and enforcement activity has increasingly targeted weak default privacy settings and aggressive engagement mechanics.
How does the Code compare to the US COPPA rules?
COPPA focuses narrowly on verified parental consent for children under 13, while the UK Code applies a broader "likely to be accessed" test covering all under 18s and mandates specific design defaults like geolocation-off and no nudge techniques.
Can Pocketapp help audit an existing app against the Code?
Yes. A Mobile App Clinic session can review your current defaults, profiling settings, and UX patterns against the 15 standards and flag where design changes are needed.