Uk Aadc Implementation

UK Age Appropriate Design Code Implementation

Overview

The Age Appropriate Design Code (AADC), also known as the Children's Code, is a statutory code of practice issued by the UK Information Commissioner's Office (ICO) under Section 123 of the Data Protection Act 2018. It came into force on 2 September 2020 with a 12-month transition period ending 2 September 2021. The Code sets out 15 standards of age-appropriate design that information society services (ISS) likely to be accessed by children must conform to. "Children" under the Code means anyone under the age of 18 in the UK. Non-compliance does not directly create criminal liability, but the ICO takes the Code into account when assessing conformance with the UK GDPR and DPA 2018, and violations can result in enforcement action including fines of up to GBP 17.5 million or 4% of annual worldwide turnover.

Scope — Who Must Comply

The AADC applies to providers of information society services that:

1. Process personal data: The service processes the personal data of individual users
2. Are likely to be accessed by children: The service is likely to be accessed by users under 18, even if not specifically directed at children. The ICO interprets "likely to be accessed" broadly — if children form any part of the actual or foreseeable user base, the Code applies
3. Are information society services: Services normally provided for remuneration, at a distance, by electronic means, and at the individual request of a recipient. Includes apps, games, social media, streaming services, connected toys, news websites, educational platforms, and online marketplaces

Services NOT in Scope

• Services with no UK users
• Preventive or counselling services offered directly to a child
• Services that can demonstrate children do not and cannot access the service (e.g., authenticated corporate intranets)

The 15 Standards

Standard 1: Best Interests of the Child

Requirement: The best interests of the child should be a primary consideration when designing and developing online services likely to be accessed by a child.

Implementation:

• Conduct a Best Interests Assessment (BIA) documented in writing for each feature or processing activity affecting children
• BIA must consider: the child's physical safety, mental health, developmental needs, educational benefit, privacy interests, and right to play
• Reference the UN Convention on the Rights of the Child (UNCRC) Articles 3, 12, 13, 16, 17, and 31
• Record how children's interests were weighed against commercial interests
• Update BIA when features change or new risks emerge

BrightPath Learning Inc. Example: Before launching a "leaderboard" feature comparing children's scores, BrightPath conducted a BIA considering potential psychological pressure and bullying risks. The BIA concluded that public leaderboards were not in children's best interests. BrightPath instead implemented private progress reports visible only to the child and their parent.

Standard 2: Data Protection Impact Assessments

Requirement: Undertake a DPIA for any processing likely to result in a high risk to the rights and freedoms of children, considering the different ages, capacities, and developmental needs of children.

Implementation:

• Conduct child-specific DPIAs that assess risk from the perspective of children at different developmental stages (under 5, 5-9, 10-12, 13-15, 16-17)
• Consider risks that adults might tolerate but children cannot (commercial pressure, social exclusion, grooming, exposure to inappropriate content)
• Include children or children's advocates in the DPIA process where possible
• DPIA must address how the service's design affects children's agency and autonomy
• Review DPIA annually and after any significant service change

Standard 3: Age-Appropriate Application

Requirement: Take a risk-based approach to recognising the age of individual users and ensure you effectively apply the standards in this code to child users.

Implementation:

• Establish the age of users with a level of certainty proportionate to the risks arising from the data processing
• For high-risk processing: use age verification or estimation technologies with high confidence
• For lower-risk processing: self-declaration may be acceptable if combined with risk-mitigation measures
• Apply different design standards to different age groups where appropriate (pre-literate children, primary school, secondary school, young adults)
• Do not use age information collected for this purpose for any other purpose

Standard 4: Transparency

Requirement: Provide privacy information in a clear, prominent, and age-appropriate manner that is suitable for the audience, including for children who are not the primary users but may still access the service.

Implementation:

• Provide a child-friendly version of the privacy notice using language, illustrations, and formats appropriate to each age group
• Use bite-sized, just-in-time notices at the point of data collection rather than relying solely on a single privacy policy page
• For children under 12: use simple vocabulary (maximum Year 5 reading level), illustrations, icons, and interactive elements
• For children 13-17: use plain English at GCSE reading level with practical examples
• Explain what data is collected, why, who sees it, and what the child can do about it
• Make the "so what?" clear — help children understand how data processing affects them in practice

Standard 5: Detrimental Use of Data

Requirement: Do not use children's personal data in ways that have been shown to be detrimental to their wellbeing, or that go against industry codes of practice, other regulatory provisions or Government advice.

Implementation:

• Do not use children's data for: behavioural advertising targeting, extensive profiling for commercial purposes, social scoring, emotional manipulation, or dark patterns that exploit developmental vulnerabilities
• Monitor academic research and Government guidance on technology's impact on children's wellbeing
• Maintain a "detrimental use register" documenting processing activities assessed against this standard
• Remove or modify features identified as detrimental following review

Standard 6: Policies and Community Standards

Requirement: Uphold published terms, policies, and community standards, including but not limited to privacy policies, age restriction policies, behaviour rules, and content policies.

Implementation:

• Enforce age restrictions consistently — if the service states it is for 13+, actively enforce this
• Apply community standards equally and transparently
• Provide child-accessible reporting mechanisms for policy violations
• Publish and maintain a transparency report on policy enforcement actions

Standard 7: Default Settings

Requirement: 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.

Implementation:

• Profile visibility: default to private or friends-only
• Location sharing: default to off
• Search indexing: default to not indexed by external search engines
• Direct messaging: default to contacts-only or off for younger children
• Personalised advertising: default to off
• Data sharing with third parties: default to off
• Push notifications: default to minimal or off
• Document the compelling reason if any default is not set to highest privacy

Standard 8: Data Minimisation

Requirement: Collect and retain only the minimum amount of personal data needed to provide the elements of the service in which a child is actively and knowingly engaged.

Implementation:

• Limit data collection to what is strictly necessary for the specific feature the child is using
• Do not collect data for future use or speculative purposes
• Disable background data collection (microphone, camera, contacts, location) unless actively required for a feature the child has requested
• Implement automated data deletion schedules with short retention periods
• Regularly audit data collection against stated purposes

Standard 9: Data Sharing

Requirement: Do not disclose children's data unless you can demonstrate a compelling reason to do so, taking account of the best interests of the child.

Implementation:

• Default to not sharing children's data with third parties
• Where sharing is necessary, document the compelling reason and conduct a BIA
• Contractually require third parties to apply equivalent protections to children's data
• Provide transparent notice to the child and parent about any data sharing
• Maintain a publicly available list of categories of third-party recipients

Standard 10: Geolocation

Requirement: Switch geolocation options off by default (unless you can demonstrate a compelling reason for geolocation to be switched on by default, taking account of the best interests of the child). Provide an obvious sign to the child when location tracking is active. Options which make the child's location visible to others must default to off.

Implementation:

• GPS and precise location services: default OFF
• Display a persistent, visible indicator when any location tracking is active (e.g., a pulsing location icon)
• Location visible to others: always default to OFF with no exception
• If location is required for a feature, collect at the lowest precision necessary (city-level rather than street-level)
• Automatically reset location permissions to OFF after each session ends
• Provide parents with the ability to disable location features entirely

BrightPath Learning Inc. Example: BrightPath's educational platform does not collect precise geolocation. Country-level location is derived from the IP address (truncated to /16) solely for content localisation (language and curriculum alignment). No location data is shared with third parties or visible to other users. A notice states: "We know which country you're in so we can show you the right lessons. We don't track where you go."