COPPA and Children’s Privacy Guide: Consent, Data Minimisation and Security Duties

Children's data now carries explicit security duties, not just consent paperwork: the amended US COPPA Rule requires a written information security program, a written retention policy and separate parental consent before children's data goes to third parties. The 2025 amendments to the Federal Trade Commission's Children's Online Privacy Protection Rule (16 CFR Part 312) took effect on 23 June 2025, and most of them had to be met by 22 April 2026. In the UK, the ICO's Age Appropriate Design Code (the children's code) sets 15 standards for online services likely to be accessed by under-18s. This guide covers scope, the security and engineering duties, SDK and AI agent exposure, and a compliance plan, for security, privacy and product leads at app, game, edtech and consumer platforms. Status was checked against the official texts in October 2026.

Key takeaways

• COPPA is a security rule as well as a consent rule. Section 312.8 now requires a written information security program with a named coordinator, at least annual risk assessments, safeguards, testing and monitoring, and at least annual review.
• Third-party disclosure needs its own consent. Under 312.5(a)(2) parents must be able to consent to collection without consenting to disclosure, and separate verifiable consent is needed for disclosures that are not integral to the service, including targeted advertising.
• Indefinite retention is prohibited. Section 312.10 limits retention to what is reasonably necessary for the specific purpose and requires a written retention policy published in the online notice.
• SDKs and persistent identifiers are where most operators fail. A cookie ID, device ID or IP address is personal information under 312.2, and a third-party SDK collecting it counts as collection on the operator's behalf.
• UK services face a wider net. The ICO children's code covers services likely to be accessed by anyone under 18, defaults to high privacy and switches geolocation off by default.

Scope: who and what is covered

COPPA applies to the commercial operator of a website or online service (including apps, connected devices and voice services) that is directed to children under 13, or that has actual knowledge it collects personal information from a child under 13. Information is collected "on behalf of" an operator when an agent or service provider collects it, or when the operator benefits from another party collecting it, which is why an advertising or analytics SDK embedded in a child-directed app brings the app owner into scope.

Child-directed status is judged on subject matter, visual content, characters, activities and audience evidence. The 2025 amendments added a definition of mixed audience: a child-directed service that does not target children as its primary audience. Mixed-audience operators may age-screen users and, before screening, may collect personal information only for the limited purposes in 312.5(c).

What counts as personal information

The UK and wider children's privacy angle

The ICO's Age Appropriate Design Code is a statutory code of practice under the Data Protection Act 2018 that explains how UK GDPR applies to children. It covers information society services likely to be accessed by children, meaning under-18s, whether or not the service is aimed at them, and it applies to non-UK companies that process UK children's personal data. Its 15 standards are: best interests of the child, data protection impact assessments, age appropriate application, transparency, detrimental use of data, policies and community standards, default settings, data minimisation, data sharing, geolocation, parental controls, profiling, nudge techniques, connected toys and devices, and online tools. For EU processing, GDPR Article 8 sets the age of digital consent at 16, with member states allowed to lower it to 13. See the GDPR Compliance Guide for Security Teams. US state laws add teen protections; see the US State Privacy Laws Guide.

Key obligations

Notice and verifiable parental consent

• Direct notice (312.4(c)): tells the parent what will be collected, how it is used, the identities or categories of third parties that receive it and why, that the parent may consent to collection without consenting to third-party disclosure, and how to give consent.
• Online notice (312.4(d)): a clearly labelled link on the home page and wherever children's data is collected, listing every operator, the data practices, the retention policy, the internal-operations purposes for any persistent identifiers, and parents' rights to review, delete and refuse further collection.
• Consent methods (312.5(b)(2)): signed form returned by post, fax or scan; payment transaction that notifies the account holder; toll-free call or video call with trained staff; government ID checked and then promptly deleted; knowledge-based authentication with dynamic multiple-choice questions a child of 12 or under could not reasonably answer; facial match of a live image against photo ID, confirmed by trained staff, with images deleted promptly; and, only for operators that do not disclose children's data, "email plus" or the new "text plus" method.
• Exceptions (312.5(c)): nine cases needing no prior consent, including contact details collected solely to seek consent, child safety, security and legal process, persistent identifiers used solely for internal operations, and voice audio deleted immediately after answering a request.

The consent mechanism is an identity verification flow and should be built and tested like one. See the Identity Data Privacy and Consent Guide and, for age signals before consent, the Age Assurance Guide.

The written information security program (312.8)

Operators must establish and maintain reasonable procedures to protect the confidentiality, security and integrity of children's personal information. At minimum this means a written program, scaled to the sensitivity of the data and the size and complexity of the operator, that includes:

1. One or more designated employees who coordinate the program.
2. Identification of internal and external risks to children's data, with a risk assessment at least annually.
3. Safeguards designed and maintained in proportion to the volume and sensitivity of the data and the likelihood of compromise.
4. Regular testing and monitoring of the safeguards' effectiveness.
5. At least annual evaluation and update of the program in light of risks, test results and material changes.

Section 312.8(c) adds a supplier duty: before releasing children's data to, or letting it be collected by, another operator, service provider or third party, the operator must take reasonable steps to confirm that party can protect it and obtain written assurances that it will.

Retention and deletion (312.10)

Children's personal information may be kept only as long as reasonably necessary for the specific purpose for which it was collected, never indefinitely, and must be deleted using reasonable measures that protect against unauthorised access during deletion. The written retention policy must state the purposes for collection, the business need for retaining each category and a timeframe for deletion, and it must appear in the online notice. Enforce it in code (TTLs, lifecycle rules, purge jobs), including backups, logs, exports, training sets and agent memory.

Timeline and current status

As of October 2026, the eCFR shows Part 312 in its amended form and the 22 April 2026 compliance date has passed, so all amended duties apply now. The FTC has said it intends to review the rule again to address age verification; any change would need notice and comment, so check the Federal Register before relying on the age-verification policy statement. The FTC declined to adopt the proposed school authorisation exception for edtech, citing possible FERPA changes, and dropped proposed limits on engagement prompts such as push notifications.

Enforcement and penalties

• Civil penalties: COPPA Rule violations are treated as violations of an FTC trade regulation rule. The inflation-adjusted maximum under Section 5(m)(1)(A) of the FTC Act is $53,088 per violation (16 CFR 1.98(d), adjusted January 2025), and each affected child or each collection can count as a violation.
• Who enforces: the FTC (often via Department of Justice complaints) and state attorneys general.
• Recent actions: the Department of Justice announced a $10 million civil penalty against Disney entities for failing to designate child-directed YouTube content, which led to targeted advertising and collection without parental consent, with a court order requiring a COPPA compliance programme. A September 2025 action against toy maker Apitor centred on a third-party SDK collecting children's data without notice or consent.
• Safe harbor: operators that follow FTC-approved safe harbor guidelines are deemed compliant with 312.2 to 312.8 and 312.10, and programs must now publish member lists and assess each member at least annually.
• UK: the ICO enforces the children's code through UK GDPR powers, including fines of up to £17.5 million or 4% of worldwide annual turnover, whichever is higher.

What it means for AI agents and non-human identities

COPPA does not mention AI, but voice assistants, chatbots, tutors and companion apps process audio, text and images that are personal information, and the credentials behind them are the access path to that data.

• Model inputs and training: using a child's prompts, voice or images to train or fine-tune a model is a use that must be in the notice and the consent, and it collides with 312.10 retention limits. Disclosing that data to a third-party model provider for its own training is a third-party disclosure that needs separate consent unless it is integral to the service. See the AI and Privacy Guide.
• Service accounts and API keys: the identities that pipelines, data warehouses and AI agents use to read children's records are the most privileged access to that data. Scope them to the minimum tables, rotate them, and log their reads. A leaked warehouse key is a children's data breach.
• Agents acting on data: an AI agent with tool access to a CRM or support system can read and forward children's records. Give agents their own identities with per-tool authorisation and keep them out of datasets flagged as children's data unless the purpose requires it. See the AI Agent Authorisation Guide.
• SDKs as non-human data collectors: each SDK is effectively a third-party identity with collection rights inside your app. Inventory them, map the persistent identifiers each one sends, and obtain the written assurances 312.8(c) requires.

Compliance steps

1. Determine status. Decide, with counsel, whether each service is child-directed, mixed audience or general audience with actual knowledge, and record the reasoning. Revisit when content or audience changes.
2. Inventory children's data and collectors. Map every data element in the 312.2 categories, every system that stores it, every SDK and service provider that receives it, and every service account or agent that can read it. Tag children's data in the catalogue.
3. Close SDK and identifier leaks. Run traffic capture on app builds (a proxy on a test device) to see what each SDK sends. Remove or configure SDKs so persistent identifiers serve only internal operations, and disable behavioural advertising for child users.
4. Rebuild consent flows. Separate consent for collection and for third-party disclosure, choose a 312.5(b) method that fits your disclosure practices, and delete identity documents and facial images after verification. Test the flow for bypass, as you would an authentication flow.
5. Write the security program. Name the coordinator, run the first risk assessment, document safeguards (encryption at rest and in transit, access control, logging, vulnerability management, incident response), set a testing schedule and an annual review date.
6. Implement and evidence retention. Publish the retention policy, configure TTLs and lifecycle rules per category, and keep purge job logs as evidence.
7. Contract and assure suppliers. Obtain written assurances from every recipient, add deletion and sub-processor terms, and review them annually. See the Third-Party Risk Management Guide.
8. Test, then roll out in stages. Pilot new consent and age-screening flows behind a feature flag on one app version, compare completion and error rates, and keep the previous flow ready for rollback, never falling back to collecting data before consent.
9. Prepare for incidents. Add children's data to breach playbooks; US state notification laws still apply. See the Data Breach Notification Checklist.

Decision guidance

• Treat everyone as a child or age-screen: a service primarily directed to children must treat all users as children. A mixed-audience service can age-screen neutrally and apply COPPA only to under-13s, which preserves features for adults but adds a screening flow that must not encourage false ages.
• Email plus or stronger methods: email plus and text plus are cheaper but only allowed if you do not disclose children's data. If you share with any third party beyond what is integral, you need a stronger method.
• Small vs large: 312.8 scales safeguards to size and sensitivity, so a small studio can meet it with a short written program and a managed cloud baseline, while a platform holding biometrics or voice needs dedicated controls and formal testing.

Detection, measurement and framework mapping

What to monitor: access by service accounts and humans to tables tagged as children's data, outbound network calls from app builds to SDK endpoints, data exports to analytics or advertising destinations, failed and bypassed consent attempts, and purge job results.

• Metric: percentage of SDKs in child-facing builds with a mapped data flow and written assurance (target 100%).
• Metric: records of children's data older than the retention period for their category (target zero).
• Metric: identities (human and non-human) with read access to children's data, trended down after each access review.
• Metric: days since last 312.8 risk assessment and program review (must stay under 365).

Common failure patterns

• Trusting the SDK default: advertising and analytics SDKs send device identifiers by default. The FTC's 2025 action against Apitor turned on exactly this: a third-party SDK collecting children's data without notice or consent.
• Mislabelling child-directed content: the Disney YouTube case shows that failing to flag content as child-directed passes the obligation failure down to every advertising system downstream.
• Retention by inertia: children's data left in backups, logs and exports after account closure.
• Keeping verification artefacts: storing ID scans or facial images after the consent check, when 312.5(b)(2)(v) and (vii) require prompt deletion.
• Over-privileged pipeline credentials: warehouse and ETL service accounts that can read every child record, with long-lived keys and no read logging.

Practitioner checklist

• Record, per service, whether it is child-directed, mixed audience or general audience with actual knowledge, and why.
• Tag every 312.2 data element, including persistent identifiers and biometrics, in the data inventory.
• Capture and review network traffic from each child-facing build to confirm what every SDK sends.
• Implement separate consent for third-party disclosure and test the consent flow for bypass.
• Delete ID documents and facial images promptly after consent verification, and log the deletion.
• Publish the written retention policy and enforce it with automated deletion across backups, logs and AI data stores.
• Maintain the written 312.8 security program with a named coordinator and a dated annual risk assessment.
• Obtain written assurances from every service provider and third party that receives children's data.
• Scope, rotate and log every service account, API key and AI agent identity that can read children's data.
• For UK users under 18, complete a DPIA against the children's code and set high-privacy defaults with geolocation off.

Standards and references

• eCFR: 16 CFR Part 312 Children's Online Privacy Protection Rule
• Federal Register: Children's Online Privacy Protection Rule, Final Rule Amendments
• FTC: FTC Finalizes Changes to Children's Privacy Rule
• FTC: Children's Privacy Business Guidance
• eCFR: 16 CFR 1.98 Adjustment of Civil Monetary Penalty Amounts
• US Department of Justice: Disney Agrees to $10M Civil Penalty for Alleged Children's Privacy Violations
• ICO: Age Appropriate Design Code
• Davis Polk: FTC Prioritizes COPPA Enforcement as New Compliance Obligations Take Effect

Related NHI Mgmt Group resources: US State Privacy Laws Guide · GDPR Compliance Guide for Security Teams · Privacy Programme Guide for Security Teams · Age Assurance Guide. This guide summarises the US COPPA Rule and the UK Age Appropriate Design Code as of October 2026 and is not legal advice.