A California law that raises privacy and design requirements for online services likely to be accessed by children under 18. It requires stronger default protections, regular impact assessments, and child understandable privacy notices. The law reflects a broader shift toward privacy by design for minors, not just after the fact compliance.
Overview and legal purpose
The California Age-Appropriate Design Code Act is a privacy-by-design law for services that children are likely to use. It shifts the burden from after-the-fact notices toward safer defaults, age-aware product decisions, and documented privacy impact analysis.
Its practical effect is to make product design part of privacy compliance, not a separate UX concern. That matters because children do not evaluate disclosure, consent, profiling, or data sharing the same way adults do, and the law assumes stronger protections are needed before data collection and engagement tactics begin.
For teams building consumer apps, the statute is less about one isolated control and more about a design posture: limit data collection, reduce profiling pressure, and make privacy protections understandable to the intended audience. For broader design guidance, California’s approach aligns closely with privacy-by-design principles reflected in the EU Cyber Resilience Act, even though the legal regimes address different subject matter.
What the law changes in practice
The statute is most important where product behavior is shaped by defaults, personalization, recommendation systems, or data collection choices. It requires companies to think about the likely child audience up front, then adjust interfaces, settings, disclosures, and data uses accordingly.
That makes the law operational, not just declarative. A service may have a privacy policy and still fail the design standard if the default configuration encourages broader data sharing than is necessary, if notices are written in adult legal language, or if impact assessment is treated as a one-time paperwork exercise instead of a recurring product review.
The same design logic appears in a number of security and privacy regimes. NIST’s privacy guidance on data minimization and risk analysis is a useful reference point, and the NIST Privacy Framework helps teams translate that posture into governance, categorization, and risk treatment.
Why child-focused design is different
Children are not just a narrower user segment. They are a materially different risk population because they may be less able to understand data use, recognize manipulation, or anticipate long-term consequences of sharing information. That is why the law focuses on understandable notices, stronger defaults, and careful treatment of profiling and engagement features.
In practice, this means privacy decisions cannot be left to generic terms of service or buried toggles. The organization has to ask whether the feature is age-appropriate, whether the data use is necessary for the service, and whether the design creates avoidable exposure for a minor user base.
Where the service model depends on broad collection, personalization, or adtech-style measurement, the design challenge becomes more significant. The law pushes teams to justify retention, disclosure, sharing, and profile-building in terms that are defensible for minors, not merely convenient for growth analytics.
Governance, documentation, and product accountability
The strongest reading of the Act is that it turns privacy into an engineering and governance discipline. Product, legal, privacy, and security teams need a shared view of which services are likely to be accessed by children, what data is collected, and how design choices are reviewed over time.
That is where impact assessments matter most. They are not only compliance artifacts; they are the record that a team considered audience, purpose limitation, default settings, dark-pattern risk, disclosure quality, and the downstream effects of data use before launch or major change.
A useful comparator is how security programs treat control baselines: if the organization cannot explain why a design decision is appropriate for minors, it probably has not made the decision deliberately enough. The privacy posture becomes stronger when review is tied to product change management rather than a late-stage legal checkpoint.
Risk and Threat Considerations
Children-facing services carry higher privacy exposure when defaults, profiling, or disclosures are designed for adult users and then simply reused for minors. The practical risk is overcollection, opaque data sharing, and misuse of engagement patterns that can create lasting privacy harm.
Failure mechanism: A service fails when age-appropriate assumptions are not built into product design, allowing data collection, recommendation logic, or sharing settings to operate in ways a child user would not reasonably understand.
Impact: The result can be unlawful processing, privacy complaints, reduced trust, and persistent exposure of minors to profiling, tracking, or other data uses that the law is intended to constrain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63, CIS Controls v8 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Child-privacy design requires governance and risk treatment across product decisions. |
| PR.DS — Data Security | The law emphasizes data minimization and stronger default protections for minors. | |
| GV.PO — Policy | Age-appropriate design needs documented policy standards for product and privacy review. | |
| Recommendation — Use GV.RM to embed child-privacy risk decisions into product governance and release review. Apply PR.DS to limit collection, retention, and sharing for child-facing services. Define and enforce policy requirements for child-focused privacy-by-design controls. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Age-sensitive services often require careful audience assurance and account handling. |
| AAL — Authenticator Assurance Level | Stronger defaults and safer account access can be relevant where minors hold accounts. | |
| FAL — Federation Assurance Level | Federated sign-in can affect data sharing and disclosure for child-facing services. | |
| Recommendation — Align assurance requirements with the service’s age-sensitive user population. Set authenticator strength to match the service’s risk and user population. Review federation choices for data exposure and consent implications before deployment. | ||
| CIS Controls v8 | 3 — Data Protection | The statute’s design requirements center on limiting and protecting personal data. |
| 4 — Secure Configuration of Enterprise Assets and Software | Default protections and safer settings are central to age-appropriate design. | |
| 14 — Security Awareness and Skills Training | Product teams need privacy-aware design judgment for child-facing services. | |
| Recommendation — Minimize and protect child-user data throughout collection, storage, and sharing. Set privacy-preserving defaults and review configuration baselines for child-facing products. Train product and engineering teams to recognize age-appropriate privacy obligations. | ||
| NIST AI RMF | GOV — Govern | The law depends on governance structures that assign privacy accountability in design. |
| Recommendation — Establish governance for child-facing privacy decisions and documented accountability. | ||
Practitioner Guidance
Governance implication: Treat likely child access as a product classification issue, not just a legal review trigger. Once a service falls into scope, privacy design decisions need ownership across product, privacy, and engineering, with documented review at launch and after material feature changes.
What to watch for: Defaults that favor collection over restraint, notices that are written for lawyers rather than minors, and feature roadmaps that add personalization before the privacy analysis is complete. Those are usually the early signals that the design standard is being met in form, but not in substance.
