The U.K. Information Commissioner's Office's Age Appropriate Design Code outlines 15 standards for online services that process children's personal data. If your service is likely to be accessed by children, or if you can't definitively prove it isn't, you need to assess your compliance posture now, before parliamentary approval converts these standards into enforceable obligations.
This checklist guides you through the operational requirements you'll face. It's not just for children's apps or educational platforms. If your analytics show users under 18, if your terms of service don't explicitly prohibit minors, or if your content could reasonably attract younger audiences, you're in scope.
Prerequisites
Before working through the checklist items, confirm you have:
- Current user demographic data showing age distribution across your service
- Documented lawful bases for processing personal data from all user segments
- Access to your product and engineering roadmap for the next 12 months
- Authority to convene cross-functional teams (product, legal, engineering, marketing)
If you can't access user age data because you don't collect it, that's your first problem. You can't claim exemption from child-focused standards if you don't know who's using your service.
Scope Assessment
☐ Determine whether children are likely to access your service
Don't rely on "our target audience is adults" as your scoping logic. Examine actual usage patterns, content type, and whether your terms of service are enforced. A thorough assessment should include user research or analytics and a clear yes/no determination with documented reasoning.
☐ Define "child" consistently with the code's age thresholds
The code doesn't use a single age cutoff. Different standards apply at different developmental stages. Ensure your privacy documentation specifies which age groups you're designing for, and that your technical controls can differentiate between these groups if needed.
☐ Identify all features or content areas that might attract younger users
This includes user-generated content sections, gaming elements, social features, or educational resources. Create a feature inventory that flags child-appeal risk for each component, even if your primary service targets adults.
Technical and Design Standards
☐ Default settings must provide the highest privacy protection for child users
You can't present children with a settings menu and expect them to choose wisely. Ensure geolocation is off by default, profiling is disabled, data sharing with third parties is blocked, and privacy-protective settings require active opt-in to relax.
☐ Disable or restrict data practices that the code considers high-risk for children
Avoid behavioral advertising to under-18s, location tracking unless essential, and data sharing for purposes beyond service delivery. Implement technical controls to prevent these practices from applying to child accounts, not just policy statements.
☐ Transparency materials should be written for your youngest likely users
If 13-year-olds use your service, your privacy information needs to be comprehensible to them. Test privacy notices with actual children in your target age range, using age-appropriate language, visual aids, and concise explanations.
☐ Implement parental controls where appropriate
Provide tools that help parents oversee their children's use of your service. Ensure parental monitoring features are accessible and don't require children to initiate or approve, while balancing against children's evolving capacity for privacy.
Data Minimization and Retention
☐ Collect only the minimum data necessary to deliver your service to children
"We might use it later" isn't a valid justification. Map each data element to a specific, current service function, with child accounts collecting fewer data points than adult accounts where possible.
☐ Retention periods for children's data should be shorter than for adult data
Delete children's data when it's no longer needed for the purpose you collected it. Implement automated deletion schedules that treat child data as higher-risk, with retention periods documented and technically enforced.
☐ Avoid using children's data for purposes incompatible with your original collection purpose
If your analytics project involves profiling child behavior for purposes beyond service improvement, you're likely non-compliant. Implement a compatibility assessment process that blocks new uses of child data unless they directly benefit the child or are strictly necessary for service delivery.
Operational Controls
☐ Establish age verification or age assurance mechanisms
You need a reliable way to identify child users. Implement age verification at account creation that's proportionate to the risks your service presents, with technical controls that prevent children from falsifying their age without creating excessive friction.
☐ Differentiate your DSARs process between requests from children and adults
Children have the same GDPR rights as adults, but exercising them may look different. Ensure DSAR response procedures verify whether the requestor is a child, involve parents where appropriate, and use age-appropriate communication.
☐ Train relevant teams on the code's requirements
Your product managers, designers, and engineers need to understand these standards before they build new features. Document training completion for everyone who makes decisions affecting child users, with the code's 15 standards embedded in your design review process.
Common Mistakes
Assuming you're exempt because you prohibit child users in your terms of service. If children can access your service in practice, you're in scope. Terms of service don't override regulatory obligations.
Treating the code as a one-time compliance project. These standards require ongoing design discipline. Every new feature, third-party integration, and data use expansion needs to be assessed against child-protection requirements.
Applying adult-focused consent mechanisms to children. A wall of toggles isn't meaningful choice for a 12-year-old. If you're relying on consent as your lawful basis for processing children's data, your consent interface needs to be genuinely age-appropriate, which often means fewer options presented more simply.
Waiting for parliamentary approval to start preparation. The code signals where the ICO's enforcement priorities lie. Even if formal approval is pending, building these protections now reduces your regulatory risk and positions you ahead of competitors who'll scramble later.
Next Steps
Map your current practices against each checklist item and document gaps. Prioritize technical changes that affect high-risk processing, especially behavioral advertising, location tracking, and third-party data sharing.
Engage your product and engineering teams now. These aren't policy changes you can implement with updated documentation. They require design decisions, technical controls, and potentially significant feature modifications.
If you're uncertain whether the code applies to your service, document your reasoning but proceed as if it does. The ICO has signaled that child data protection is a supervisory priority. Building these protections benefits your users and your risk profile regardless of formal scope determinations.
