Back to all articles

COPPA 2026: What Your Kids-App Privacy Policy Must Now Say

By Support URL Generator Team · Published

Advertisement

If App Review flagged your kids app under Guideline 1.3, Google Play's Families team rejected an update, or your legal reviewer sent the privacy policy back, the reason in 2026 is usually the same: the FTC amended the COPPA Rule, and the deadline for full compliance was April 22, 2026. A policy that was fine in 2023 is now out of date. Build a hosted policy for a child-directed app → /privacy-policy-page-generator.

The dates that matter

  • January 2024 — the FTC published its Notice of Proposed Rulemaking (the "2024 NPRM").
  • January 16, 2025 — the Commission voted 5-0 to finalize the amended Rule.
  • April 22, 2025 — the final Rule was published in the Federal Register.
  • June 23, 2025 — the amended Rule took effect. Between this date and the compliance date, an operator could follow either the pre-2025 Rule or the amended Rule.
  • April 22, 2026 — full compliance required for everyone. Certain COPPA Safe Harbor program obligations under 16 CFR 312.11 carried an earlier date.

COPPA applies to operators of websites and online services directed to children under 13, and to any service with actual knowledge that it collects personal information from a child under 13. This article is a practical summary, not legal advice; confirm your obligations with a qualified attorney. Primary sources: the FTC announcement, the COPPA Rule page, and the Federal Register final rule.

What actually changed

Separate parental consent for third-party disclosure and targeted advertising

The amended Rule makes explicit that consent to collect a child's personal information is not consent to disclose it. Operators must now obtain separate verifiable parental consent before sharing a child's personal information with third parties for targeted advertising or other purposes that are not integral to the service. In practice, an ad SDK that builds profiles or serves personalized ads cannot run in a child-directed app on the strength of one combined consent screen, and for most kids apps it cannot run at all.

A written data retention policy, and no indefinite retention

Section 312.10 now states that an operator may retain a child's personal information only for as long as is reasonably necessary for the specific purpose it was collected for, and may not retain it indefinitely. You must establish and maintain a written data retention policy that identifies the business need for retaining each type of data and the timeframe for deleting it. Retained data may not be repurposed.

Expanded definition of "personal information"

Personal information now expressly includes biometric identifiers that can be used for automated or semi-automated recognition of an individual (for example a fingerprint, voiceprint, or face template) and government-issued identifiers (such as a birth certificate, passport, or state identification number). "Online contact information" now also includes a mobile phone number, so an SMS field is in scope.

A written information security program

Section 312.8 now requires operators to establish, implement, and maintain a written children's information security program proportionate to the sensitivity of the data and the size and complexity of the operator. It must designate one or more employees to coordinate it, include risk assessments, test and monitor safeguards, be evaluated and updated at least annually, and require written assurances from any service provider or third party that receives children's data.

Support for internal operations

The "support for the internal operations" exception, which lets you use a persistent identifier without parental consent for things like maintaining state, capping the frequency of contextual ads, or fraud prevention, was clarified. If you rely on it, your online notice must now list the specific internal operations involved and describe the means you use to ensure the identifier is not used or disclosed to contact a specific person, or to prompt the child to use the app more.

New "mixed audience" definition

A mixed-audience service is one that is child-directed but does not target children as its primary audience and does not collect personal information before running a neutral age screen. Mixed-audience apps may treat self-identified adults normally, but must apply full COPPA protections to any visitor who indicates they are under 13.

What your kids-app privacy policy must now contain

  1. The name, address, phone number, and email address of every operator collecting personal information through the app (or one operator designated to answer all parental inquiries, with every operator still named).
  2. Exactly what personal information the app collects from children, how it is collected (including passively, through persistent identifiers), and how it is used.
  3. The identities or specific categories of every third party that receives children's personal information, and the purpose of each disclosure.
  4. Your written data retention policy — what you keep, why, and when you delete it.
  5. If you use the support-for-internal-operations exception: the specific internal operations, and the safeguards that keep the identifier from being used to contact or profile the child.
  6. That a parent can review the child's information, refuse further collection, and have the information deleted, plus the exact procedure for doing each.
  7. That you obtain verifiable parental consent before collection, and the consent method you use.

Host it at a stable public URL and link it on the app's home screen and on every screen where personal information is collected.

Apple Kids Category and Google Play "Designed for Families"

Both stores layer their own rules on top of COPPA.

Apple, Guideline 1.3: apps in the Kids Category should not include third-party analytics or third-party advertising, with narrow exceptions — analytics that transmit no IDFA and no identifiable information about the child, their location, or their device; and contextual (not behavioral) advertising from a provider with publicly documented kids policies and human review of ad creative for age-appropriateness. The privacy policy link is required both in App Store Connect metadata and inside the app. See the App Review Guidelines and Apple's kids design guidance.

Google Play Families: apps in the program must comply with COPPA and other applicable laws, must use only ad SDKs enrolled in the Families Self-Certified Ads SDK Program, must disable personalized advertising, remarketing, and interest-based advertising for children, and must present a neutral age screen for a mixed audience. The Families policy also requires a privacy policy that accurately reflects your practices, and the Data safety form must match it.

Third-party SDKs in a kids app

Assume every SDK is a disclosure until you prove otherwise. Analytics SDKs that collect advertising identifiers, ad SDKs that personalize, attribution SDKs that fingerprint, and social SDKs that track are all incompatible with a child-directed build. Safer choices: first-party or COPPA-configured analytics with identifiers stripped, Google's certified families ad SDKs for contextual-only ads, and crash reporting configured to drop user identifiers. Whatever remains must be named in the policy with its data types and purpose. Our SDK privacy-policy clause library covers the common ones.

Replying to a rejection

If the rejection concerns the policy content, fix the policy first, then reply with specifics:

Hello,

Thank you for the review. This app is directed to children and we have
updated our privacy policy to meet the amended COPPA Rule (16 CFR Part
312, compliance date April 22, 2026).

The policy is hosted publicly, with no login required, at:
  https://example.com/kids-privacy

It now includes:
- every third party that receives children's data, by name, with the
  data types and the purpose of each disclosure ("Third parties")
- our written data retention policy and deletion timeframes
  ("Data retention")
- the verifiable parental consent method used before any collection
- the parental review and deletion procedure and a contact address

We removed [SDK name], previously used for [purpose], from the
child-directed build. The remaining third-party SDKs are [list], each
configured with advertising identifiers disabled.

The in-app privacy policy link is on the first screen and on the
sign-up screen. App Store Connect metadata links the same URL.

Please let us know if anything else is needed.

For Google Play, submit the same summary through the Play Console policy appeal form and confirm the Data safety section now matches the policy.

Related

Read why AI-written privacy policies get rejected, the app SDK privacy-policy clauses, and Firebase privacy policy guidance. Build a hosted policy with the privacy policy page generator, and if your app has account creation, add in-app deletion with the account deletion page generator.

Advertisement

Need a Support URL for Your App?

Generate a compliant, professional support page in under a minute. Our easy-to-use generator creates everything you need for App Store and Google Play submissions.