Skip to content
COPPAUK AADCage thresholdschildren's privacy

AADC vs COPPA: why 'under 18' and 'under 13' are different compliance universes

COPPA is a data-privacy statute that gates collection from under-13s behind parental consent; the UK AADC is a design code protecting every under-18 through age-appropriate defaults. The gap is where teams get caught.

Landfall · Published 23 July 2026

Two of the most-cited children's regulations in the world draw their protective line in completely different places. COPPA draws it at 13 and asks a single question: did you collect a child's data without a parent's say-so? The UK Age Appropriate Design Code draws it at 18 and asks a different one: is your service designed, by default, in children's best interests? Teams that treat these as two flavours of the same rule ship an under-13 consent gate, call children's compliance "done," and walk straight into the gap between them.

This guide is about that gap — where the two regimes actually diverge, and what a team serving both markets does about it.

The core split

COPPA — the US Children's Online Privacy Protection Act, enforced by the FTC — is a data-privacy statute. Its central obligation, COPPA-312-3-PARENTAL-CONSENT, is that operators must obtain verifiable parental consent before collecting, using, or disclosing personal information from children under 13. Its scope, per COPPA-312-2-ACTUAL-KNOWLEDGE, catches services directed to children and any operator with actual knowledge it is collecting from an under-13. The mechanism is consent; the trigger is data collection; the boundary is a child's thirteenth birthday.

The UK AADC — the ICO's Children's Code — is a design code. Its foundation, UK-AADC-STD-01, is that the best interests of the child must be a primary consideration in how you design and build the service. It protects everyone under 18, and it applies to any service "likely to be accessed by children," not only services aimed at them. There is no consent gate at its heart; there is a standard of care that reshapes your defaults for the whole child population of your product.

That is the split in one line: COPPA is a permission you obtain; the AADC is a way you build. One is satisfied by a workflow, the other by a posture.

Where they diverge, concretely

DimensionCOPPA (under-13)UK AADC (under-18)
Protected ageUnder 13 (COPPA-312-2-ACTUAL-KNOWLEDGE)All under-18s, banded across five developmental stages (UK-AADC-AGE-BANDS)
Core modelVerifiable parental consent before collection (COPPA-312-3-PARENTAL-CONSENT, COPPA-312-5-VPC-METHODS)Most-protective settings on by default (UK-AADC-STD-07)
Age assuranceNeutral age screening on mixed-audience sites (COPPA-312-MIXED-AUDIENCE)Establish age with certainty proportionate to risk, or apply the code to all users (UK-AADC-STD-03, UK-AADC-STD-03-METHODS)
Profiling & adsPersistent identifiers are personal information, especially for behavioural advertising (COPPA-312-2-PERSISTENT-IDS)Profiling off by default; permitted only with harm-protection measures (UK-AADC-STD-11)
GeolocationPrecise geolocation is personal information requiring parental consent (COPPA-312-GEOLOCATION)Geolocation off by default; obvious when active; easy to switch back off (UK-AADC-STD-10-GEOLOCATION)
Data minimisationCannot require more data than reasonably necessary to participate (COPPA-312-7-NO-CONDITIONING)Collect the minimum needed (UK-AADC-STD-08); no nudging children into giving more (UK-AADC-STD-13)
EnforcerFTC, civil penalties up to $50,120 per violation; state AGs may also act (COPPA-312-FTC-ENFORCEMENT)ICO, under the UK GDPR/Data Protection Act enforcement regime

Read down the table and the pattern is clear. COPPA's answers are mostly about collection: get consent, don't over-collect, treat identifiers and precise location as data that needs a parent's yes. The AADC's answers are mostly about defaults: turn profiling and geolocation off before a child ever arrives, and don't design the interface to talk them back out of that protection.

Age assurance is the sharpest contrast. COPPA is largely content with a neutral age screen that doesn't nudge a child toward lying about their age (COPPA-312-MIXED-AUDIENCE). The AADC's UK-AADC-STD-03 gives you a genuine fork: either establish age with a confidence proportionate to the risks your service poses to children, or apply the whole code's protections to your entire user base. For many products, "apply it to everyone" is the honest — and cheaper — answer, and that is a very different engineering decision from bolting a 13+ gate onto a signup form.

The trap: COPPA-compliant, AADC-exposed

Here is the failure mode. A team builds a solid COPPA programme — verifiable parental consent for under-13s, honest notices, no conditioning, sensible retention (COPPA-312-9-DATA-RETENTION) — and reasons that children's compliance is handled. Then the same product is accessible from the UK, and every duty in the AADC applies to a population COPPA never touched: the 13-to-17s.

Those teenagers are outside COPPA's scope entirely. But under the AADC they are children, and your service owes them privacy-protective defaults (UK-AADC-STD-07), profiling off unless you can show harm protection (UK-AADC-STD-11), geolocation off by default (UK-AADC-STD-10-GEOLOCATION), and an interface that doesn't nudge them into weakening any of it (UK-AADC-STD-13). An under-13 consent gate does nothing for a 15-year-old whose account was public and profiled by default. The under-13 gate is not a smaller version of the under-18 duty — it is a different duty, aimed at a different age band, satisfied by a different mechanism.

This is precisely the age-scope distinction that Landfall's own generation logic enforces: an obligation triggered by "likely to be accessed by children" and one triggered by "collecting from a child under 13" are not interchangeable, and a backlog that maps one to the other will quietly drop the teenagers.

What a team serving both markets actually does

You do not run two parallel compliance programmes. You take the strictest-default union — for any given design decision, apply whichever regime is more protective, to the widest population either regime protects.

In practice that looks like:

  • Set protective defaults for all minors, not just under-13s. Profiling and precise geolocation off by default across your entire child population satisfies the AADC's UK-AADC-STD-07, UK-AADC-STD-11, and UK-AADC-STD-10-GEOLOCATION at once — and it comfortably clears COPPA's consent requirements for the under-13s inside that group, because you're not collecting the sensitive data by default in the first place.
  • Decide your age-assurance posture deliberately. Use UK-AADC-STD-03's fork honestly: if you can't establish age with risk-proportionate confidence, apply children's protections to everyone. That single decision also handles COPPA's mixed-audience screening expectation.
  • Keep COPPA's consent machinery where it bites. For genuine collection from under-13s, you still need verifiable parental consent through an approved method (COPPA-312-5-VPC-METHODS) — the AADC's defaults don't remove that statutory requirement.
  • Minimise once, for both. COPPA-312-7-NO-CONDITIONING and UK-AADC-STD-08 point the same way: collect the minimum. Build it once and both regimes are happier.
  • Document the design decisions. The AADC expects a data protection impact assessment (UK-AADC-STD-02); COPPA enforcement (COPPA-312-FTC-ENFORCEMENT) rewards operators who can show a deliberate, minimising design. The same evidence serves both.

The mental model that keeps teams out of trouble: COPPA tells you when you need a parent's permission; the AADC tells you how the product should behave before anyone gives permission at all. Get the defaults right for every minor, keep the consent gate for the under-13s, and the two regimes stop feeling like a contradiction.

To work from the primary obligations rather than this summary, browse them in the explorer: the UK Age Appropriate Design Code and COPPA. Both are the same corpus this article is grounded in.

Explore the underlying obligations

This article is grounded in the obligations Landfall maps from source legal text. Browse them yourself:

For informational purposes only. This guide is summary-level, informational writing — not legal advice, not a risk score, and not regulatory approval. It does not create an attorney-client relationship. Always consult qualified legal counsel for compliance decisions about your specific product.

What Landfall Is NOT

Critical Boundaries

Understanding these boundaries is essential before using this product. Misuse of this tool for purposes outside its scope may create legal, regulatory, or commercial risk for your organization.

NOT Legal Advice

This product does not provide legal advice and does not create an attorney-client relationship.

Interpretations are informational analysis, not legal counsel. Always consult qualified legal professionals for compliance decisions.

NOT a Risk Score

We do not quantify, calculate, or certify your compliance risk level.

No numerical risk rating, compliance percentage, or safety score. Risk assessment requires human judgment about your specific context.

NOT Runtime Enforcement

This is a planning and mapping tool, not a runtime enforcement system.

Does not integrate with your production systems. Does not block, filter, or enforce compliance in real-time. Implementation is your responsibility.

NOT Regulatory Approval

Using this tool does not mean you are compliant with any regulation.

No certification, seal of approval, or compliance guarantee. Regulators will evaluate your actual implementation, not your use of this tool.

NOT Authoritative Interpretation

Our interpretations are not binding and may differ from regulatory guidance.

Only regulators and courts provide authoritative interpretation. Our analysis reflects our reading of requirements, which may be incomplete or incorrect.

NOT a Safe Harbor

This tool does not shield you from enforcement actions or liability.

Documentation of your process is valuable, but does not constitute a legal defense. Compliance is ultimately your organization's responsibility.

NOT an AI Compliance Agent

AI features assist analysis but do not make compliance decisions for you.

AI-generated interpretations require human review and approval. Automated suggestions are starting points, not final answers.

NOT Complete Coverage

We do not cover all regulations, all obligations, or all jurisdictions.

Regulatory landscape is vast and evolving. Gaps in our coverage do not mean those requirements don't apply to you.

What This Tool IS:

  • A structured workflow for mapping regulatory requirements to implementation tasks
  • A documentation system for compliance decisions (audit trail)
  • A collaboration platform for compliance, legal, and engineering teams
  • An informational resource for understanding regulatory obligations