COPPA 2.0 Compliance: Re-Engineering Consent, Retention Limits and Data Minimisation for Kids’ Data

The FTC’s amended COPPA rule is a dated engineering programme wearing a privacy-notice disguise. It reaches your collection, storage and sharing layers, not just the wording on a page, and the full compliance date is 22 April 2026.

Most of the COPPA coverage aimed at operators treats this as a policy-drafting exercise: update the privacy notice, add a consent checkbox, ship it. That reading will fail an examiner and, worse, will leave you telling parents one thing while your systems quietly do another. The amendments the FTC finalised in January 2025, published in the Federal Register on 22 April 2025 and effective from 23 June 2025, change what your kids-data pipeline is allowed to do. The rule became enforceable in stages, but the substantive obligations most operators still have not built for carry a full compliance date of 22 April 2026. Treat the intervening time as a delivery window, because the work is real.

Who is actually in scope, and why the edge cases matter

COPPA binds operators of online services directed to children under 13, and any operator with actual knowledge that it collects personal information from a child under 13. The engineering trap sits in the second limb. A general-audience product with a mixed-audience feature, an SDK embedded in a children’s app, or a support inbox that receives a birth date can pull you into scope for a slice of your traffic without anyone deciding to serve children. The amendments also widen the definition of personal information to include biometric identifiers and government-issued identifiers, so a face-scan age check or an ID upload is now regulated data in its own right. Before you sequence any of the work below, the first task is a defensible map of where under-13 data enters, flows and rests in your estate. Most firms discover their data-flow diagram is aspirational the moment they try to use it as evidence.

Separate consent is a schema change, not a checkbox

The headline requirement is that disclosing a child’s personal information to third parties now needs its own verifiable parental consent, separate from the consent to collect. If you monetise through targeted advertising or share data with third parties for their own purposes, a parent can agree to your service and decline the sharing, and your systems have to honour that split. That is not a UI problem. It means the consent state for a child is no longer a single boolean; it is at least two dimensions — collect, and disclose-to-third-parties — that have to be captured, versioned, and read at the point every downstream integration fires.

The failure mode is predictable. The consent record lives in one service, and the advertising SDK, the analytics tag and the data-sharing job each decide independently what to send. Unless the disclose flag is propagated to and enforced at each of those boundaries, you will have a compliant consent screen and a non-compliant data flow. Build the enforcement point where the data leaves your perimeter, not where the parent clicks. That is the same discipline as engineering access rights into the product rather than bolting them on afterwards, a pattern worth reading across from data-access-by-design work under the Data Act.

The written retention policy has to be true

The rule requires a written data-retention policy, and it requires that policy to sit in the online privacy notice itself — the FTC was explicit that linking to a separate document does not satisfy the obligation, though intra-notice hyperlinks and expandable sections are acceptable. The policy must state the purposes for which children’s information is collected, the business need that justifies keeping it, and a specific timeframe for deletion. Vague phrasing such as “as long as necessary” does not meet the standard; the periods have to be reasonable and specific. Indefinite retention is out, and information collected for one purpose cannot be quietly repurposed.

Here is where the engineering catches up with the drafting. A published retention schedule is a promise, and a supervisor can ask you to demonstrate it. If the policy says twenty-four months and your data lake, your backups, your analytics warehouse and your third-party processors have no deletion mechanism that honours that period, the policy is a liability you have written down and signed. Deletion has to be a real, scheduled, evidenced job across every store that holds the data, including the ones nobody thinks of as a store. This is the point at which historical data debt stops being an abstraction and becomes a dated deliverable.

Data minimisation and a security programme you can evidence

Minimisation under the amended rule is a design constraint, not a slogan: collect only what the service genuinely needs, and stop conditioning a child’s participation on handing over more than that. In practice this forces a review of every field on every form and every attribute captured by every SDK, and a decision to justify or drop each one. The rule also requires eligible operators to establish, implement and maintain a written information security programme proportionate to the sensitivity of the data — annual risk assessments, safeguards mapped to the risks identified, testing of those safeguards, and periodic evaluation and adjustment. Operators already running a programme aligned to the FTC’s Safeguards standard can extend it rather than start again, but the children’s-data scope has to be explicit and the evidence has to exist.

None of these three strands — consent, retention, minimisation — lives inside a single team’s remit, which is exactly why they slip. The consent change is product and integration engineering. Retention is data platform and backups. Minimisation is design and analytics. The security programme is security governance. A privacy owner drafting notice text cannot deliver any of them alone.

Sequencing the work so it lands before the date

With the compliance date fixed, the order matters more than the ambition. Map the under-13 data flows first, because every other task depends on knowing where the data is. Then split and instrument the consent model, because the disclose flag has to exist before you can enforce it at each egress. Build and test the deletion jobs against the retention periods you intend to publish, so the policy describes something your systems actually do. Run the minimisation review in parallel, since dropping a field removes downstream obligations rather than adding them. Publish the retention policy and the revised notice last, once the mechanisms behind them are demonstrably working — not first, as a statement of intent you then chase.

US privacy engineering is converging on a shared shape: dated obligations that reach into the pipeline and demand evidence of operation, not just of intent — the same discipline now landing through CCPA risk assessments. COPPA’s amendments are the sharpest version of it, because the subject is children and the FTC has said it intends to enforce from 22 April 2026. A privacy notice that promises deletion your systems cannot perform is not compliance. It is a signed admission, waiting for the examiner who asks you to prove it.