A set of rules that requires digital services to protect children’s privacy and safety by default. In practice, it governs how organisations collect, use, share, and retain personal data from younger users, demanding age-appropriate settings, data minimisation, clear notice, strong privacy controls, and careful risk assessment across product design.
What the Age Appropriate Design Code means in practice
The age appropriate design Code is not just a privacy principle, it is a design rule set that changes how digital services are built for younger users. It pushes teams to default to the least intrusive, safest data practices rather than treating children’s data handling as a post-launch compliance check.
Its importance lies in the fact that privacy for children is operational, not abstract. Product decisions about defaults, friction, consent prompts, recommendation logic, and data retention all become part of the code’s effective control surface, because a service can comply in form while still failing in practice if the design encourages unnecessary collection or disclosure.
Core obligations and design choices
The code centres on age-appropriate settings, data minimisation, clear notice, and strong privacy controls. Those requirements matter because children are more likely to be affected by opaque interfaces, overbroad sharing, dark patterns, and settings that are technically available but not meaningfully protective by default.
For practitioners, the design question is not only “can we obtain data?”, but “should this data be collected at all, and if so, under what default?” The code therefore affects onboarding, profile visibility, geolocation, nudging, profiling, searchability, and how long information remains accessible after collection.
How organisations assess compliance exposure
Compliance assessment starts with knowing where younger users are likely to appear in the product estate, which features process their data, and which third-party services receive it. That requires an inventory of data flows, a review of product defaults, and a check that the service’s notices and controls are understandable to the intended age group.
It is also useful to align design review with broader privacy governance, especially where a platform handles mixed-age audiences. NIST Privacy Framework provides a useful reference point for organising privacy risk management around data processing choices, while EU General Data Protection Regulation (GDPR) remains relevant where personal data processing of children sits within wider privacy obligations.
Why failure here creates disproportionate harm
When age-appropriate design fails, the harm is often less about a single control failure and more about cumulative exposure: excessive collection, persistent profiling, inappropriate sharing, and interfaces that make children more likely to disclose information they do not understand. The result is a privacy and safety problem that can scale quickly across user bases and product lines.
Security consequences can include unwanted contact, tracking, inference of sensitive interests, and long-lived retention of data that should never have been collected so broadly. The underlying issue is usually not one dramatic breach, but an architecture that normalises broad data use and makes the safest path hard to follow.
Risk and Threat Considerations
The main risk is that a service collects, retains, or exposes more children’s data than the design can justify, especially when defaults favour visibility, profiling, or convenience over protection. That creates privacy harm even without a conventional intrusion, and it also makes the service easier to exploit through oversharing, inference, or abuse of public-facing features.
Failure mechanism: Weak age-aware design and permissive defaults allow unnecessary data collection, excessive visibility, or retention that outlives the purpose for which the data was gathered.
Impact: Children can be exposed to profiling, contact, manipulation, or disclosure of personal information, and the organisation may face regulatory and trust damage when the service’s actual behaviour diverges from its stated safeguards.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-8 — System Use Notification | Supports clear notice and user-facing disclosure expectations for younger users. |
| DM-2 — Data Minimization and Retention | Directly aligns to collecting, using, and retaining only necessary personal data. | |
| PT-2 — Authority to Process Personal Data | Addresses privacy controls over how personal data is processed and shared. | |
| Recommendation — Provide understandable notices before data collection and access to features. Minimize children’s data collection and retain it only as long as needed. Constrain processing and sharing of children’s personal data to approved purposes. | ||
| ISO/IEC 27001:2022 | A.5.34 — Privacy and protection of PII | Covers organisational controls for protecting personal data across processing activities. |
| Recommendation — Embed privacy protection requirements into governance, design, and operational review. | ||
| GDPR | Article 25 — Data protection by design and by default | Directly matches privacy-by-default design obligations for personal data processing. |
| Article 35 — Data protection impact assessment | Supports structured assessment of risks from processing children’s personal data. | |
| Recommendation — Build privacy-protective defaults into product design and configuration from the start. Perform DPIAs for high-risk child-data processing and document mitigation decisions. | ||
Practitioner Guidance
Why practitioners should care: The code turns privacy design into a product requirement, so ownership must sit with product, engineering, privacy, and security together rather than being left to a late-stage legal review. Teams should treat age-appropriate settings and data minimisation as default architecture decisions, not optional enhancements.
Common misunderstanding: It is not enough to publish a child-friendly notice or add a single parental control. The real test is whether the service’s standard behaviour is conservative enough for younger users before any manual override or account-level exception is considered.
Practitioner takeaway: Review children-facing journeys from first use onward, because the highest-risk failures usually come from defaults, visibility settings, and retention choices that were never designed with younger users in mind.
Related resources from NHI Mgmt Group
- Guide: Age Verification and Age Assurance Guide
- How should organisations assess facial age estimation when they need to meet age assurance duties under the Age Appropriate Design Code?
- California Age-Appropriate Design Code Act
- Why do age appropriate design rules create more risk for gaming and social platforms that serve minors?
- Low-Code Integration