The UK Age Appropriate Design Code, usually called the Children's Code, is a statutory code of practice issued by the Information Commissioner's Office under section 123 of the Data Protection Act 2018. It came into force on 2 September 2020 with a twelve-month transition period, so conformance has been expected since 2 September 2021. The code is written as fifteen standards. This article turns each of them into the product decision it actually asks for, so that a product, privacy or trust-and-safety lead can walk the list against a real backlog rather than a policy document.
Who the code applies to
The code applies to information society services likely to be accessed by children in the UK, where a child is anyone under 18. "Likely to be accessed" is broader than "aimed at": a service with a meaningful child audience is in scope even if its terms say 13 plus. The ICO must take the code into account when enforcing the UK GDPR, and courts and tribunals may do the same, so the practical position is that a service in scope is measured against the code when anything goes wrong.
The code also splits childhood into five age ranges (0 to 5, 6 to 9, 10 to 12, 13 to 15 and 16 to 17) and expects design choices to reflect the range, not treat a six-year-old and a sixteen-year-old as the same user.
Standards 1 to 3: the posture
1. Best interests of the child. The best interests of the child must be a primary consideration when designing and developing any service a child is likely to use. The decision: every feature that touches a child's data gets a written best-interests rationale in the design review, not only the ones that look risky.
2. Data protection impact assessments. Carry out a DPIA to assess and mitigate risks to children, and do it before launch. The decision: a DPIA is a launch gate for in-scope features, owned by a named person, and it names the age ranges affected.
3. Age appropriate application. Establish age with a level of certainty appropriate to the risks the service creates, or apply the code's standards to all users. The decision: choose one of those two routes deliberately and record why. For many products the honest answer is to apply the protections to everyone rather than build assurance they cannot justify. The age assurance comparison covers the methods.
Standards 4 to 6: what you tell children
4. Transparency. Privacy information and published terms must be concise, prominent and in language suited to the child's age, with bite-sized explanations at the point of use. The decision: layered notices per age range, and a just-in-time explanation wherever a child is asked to switch something on.
5. Detrimental use of data. Do not use a child's personal data in ways shown to be detrimental to their wellbeing or that go against industry codes, regulatory provisions or government advice. The decision: an explicit list of prohibited data uses, reviewed against the advertising and gaming codes the product touches.
6. Policies and community standards. Uphold your own published terms, policies and community standards, including privacy policies, age restrictions, behaviour rules and content policies. The decision: every rule you publish has an enforcement mechanism behind it; a published rule you do not enforce is itself a finding.
Standards 7 to 10: the defaults
7. Default settings. Settings must be high privacy by default unless you can demonstrate a compelling reason for a different default, taking account of the best interests of the child. The decision: the shipped default for a child account is the most protective one, and a change away from it is a deliberate act by the child with an explanation attached.
8. Data minimisation. Collect and retain only the minimum personal data needed to provide the elements of the service the child is actively engaged in. The decision: per-feature data collection, so a child using one feature does not pay for the whole product in data.
9. Data sharing. Do not disclose a child's data unless you can demonstrate a compelling reason to do so, taking account of the best interests of the child. The decision: an inventory of every third party that receives child data, each with a written justification, and a default of no sharing.
10. Geolocation. Geolocation options off by default, an obvious sign when location tracking is active, and options that make a child's location visible to others default back to off after each session. The decision: location is opt-in, visibly on, and never sticky. The high-privacy defaults guide goes deeper on standards 7 to 13.
Standards 11 to 13: control and influence
11. Parental controls. If you provide parental controls, give the child age-appropriate information about them, and if a parent can monitor activity or track location, give the child an obvious sign when monitoring is on. The decision: parental tools are transparent to the child and graduate with age.
12. Profiling. Profiling options off by default unless there is a compelling reason, and profiling only with measures in place to protect the child from harmful effects, in particular being fed content detrimental to health or wellbeing. The decision: recommender and personalisation systems have a child mode that runs without behavioural profiling unless the justification is written down.
13. Nudge techniques. Do not use nudge techniques to lead or encourage children to provide unnecessary personal data or to weaken or turn off their privacy protections. The decision: a design review of every consent, settings and sign-up screen for asymmetric choices, pre-ticked boxes, guilt copy and repeated prompts.
Standards 14 and 15: the edges
14. Connected toys and devices. If you provide a connected toy or device, ensure you include effective tools to enable conformance with the code. The decision: hardware products carry the same standards, including for data collected by a companion app.
15. Online tools. Provide prominent, accessible tools to help children exercise their data protection rights and report concerns. The decision: rights requests and reporting reachable from within the product, in language children can use, with response times that are tracked.
A worked example
Meadowlark Studio, a fictional company, runs a creative drawing app rated 9 plus. The team runs the fifteen standards as a checklist. Standard 3 turns into a decision to apply the code to all users, since the app has no reliable age signal. Standard 7 turns a public gallery default into private by default. Standard 10 turns off the "artists near me" map for every account, with an indicator when it is on. Standard 12 turns the "you might like" feed into a curated feed with no behavioural profiling. Standard 13 removes a modal that asked "Are you sure? Your friends will miss you" when a child declined to share. Standard 2 produces the DPIA that records all of it. None of these are legal opinions; they are product decisions the code makes easy to defend.
How Landfall helps
Landfall holds the fifteen standards as structured obligations, each with its source text, summary and category, and maps them onto a project once the questionnaire establishes that children are likely to access the service. The generated backlog groups the resulting items by standard so a product lead can see which decisions are open, which have evidence and which need a written justification. Age-range answers narrow which standards fire for which features. Every mapping keeps its citation, so a reviewer can read the standard the item came from. Browse the standards themselves in the UK AADC explorer.