Children's privacy and app-store programmes

Keel ships COPPA and the three app-store children’s programmes as separate frameworks, not one blended checklist. This page is about running them together in a workspace. For what each one requires, use the framework pages on keelgrc.com/frameworks; for the store-by-store differences, see kids apps and mobile games.

Control mapping, not a review prediction

These frameworks help you run the programme behind a store submission. They are not legal advice and they do not predict a review outcome. Apple decides App Review, and its guidelines bind an app in their entirety rather than only its children’s rules. Amazon expressly reserves the final decision on whether an app is rejected or suppressed. A readiness score of 100% here is a statement about your controls, not about your next release.

Why four frameworks and not one

COPPA is US law. The store programmes are contracts inside a developer agreement, and they do not agree with each other or with COPPA - on who counts as a child, on what puts an app in scope, or on what advertising is permitted.

Blending them would break scoring in the direction that matters. A studio shipping only to Google Play would be scored against Apple’s rules and could never reach 100%; a studio shipping everywhere would see one number that hides which store it is failing. Applying them separately means each framework’s readiness answers one question: am I ready for this store?

Apply only the ones you actually ship to.

Applying them, and what it costs against your plan

The children’s-privacy frameworks are sold as one add-on bought through COPPA, which is the SKU. On the Frameworks page in the app:

• The COPPA card carries the purchase button, labelled with the bundle name and its monthly price. Underneath it, an Includes now line names every framework the purchase grants.
• The other members’ cards do not sell. They link back to the COPPA card, because one purchase covers all of them and offering the same add-on four times is how a studio ends up paying four times.
• Buying any member entitles you to the rest. If you already own one, the others show Apply (owned) rather than a price.

Against your plan’s included framework allowance, the whole bundle counts as one framework, however many members you apply. That is the point of it: applying the children’s set does not consume the slots you need for SOC 2 or ISO 27001.

If your plan already includes premium frameworks, there is nothing to buy - apply them directly.

What a version string means here

Open any of the store frameworks and its version does not read like a version:

Child-Directed App (COPPA) Policy, retrieved 2026-08-13

That is deliberate, and it is the most important thing to understand about these three. None of the stores publishes a version number, a clause numbering scheme or a change log. They edit the page, and the new text is the policy. A retrieval date is the only honest freshness signal available, so Keel carries that instead of inventing a version. Amazon prints its own last-updated date, which the other two do not, so that is carried alongside.

COPPA is different: it is a published federal rule, amended by rulemaking, and its version says so.

Two consequences for how you work:

• Requirement references are Keel’s, not the store’s. You see these on a control, where the requirements it satisfies are listed by reference. Apple numbers its guidelines, so those numbers are real citations and are used as-is (1.3, 5.1.4(b)). Google and Amazon number nothing, so their requirements carry Keel-invented paths such as families/ads/certified-sdk-only and child-directed/ads/no-amazon-programs-to-children. Nothing in a Google or Amazon policy looks like that - which is the point. Do not quote one to a store as though it were their own clause reference.
• Check the live policy before a submission. Keel re-checks the published source pages monthly and reports a change for a human to read; it never rewrites framework content on its own, because deciding what a policy change does to a requirement set is not a job for an automated diff. A monthly check is not the same as a guarantee that the page did not change yesterday.

Scope decisions you record, not ones Keel guesses

Three of these frameworks turn on a scope decision that only you can make, and each is evidence in its own right:

• Is the app child-directed? COPPA asks whether the service is directed to children under 13, or whether you have actual knowledge you collect personal information from a child. Amazon goes further: a multi-audience app counts as child-directed unless you confirm children are not using it, so the confirmation is the artefact to keep.
• Who is a child? COPPA stops at 13. Amazon treats a child as under 13, or under 16 in the European Union, Australia and Japan. A programme scoped only to COPPA is under-scoped for that store in three markets.
• What did you declare? Google’s requirements attach to the target audience you declare in Play Console, and Google can reach its own conclusion from what the app actually looks like. Attach the declaration itself as evidence, not a description of it.

Keel does not infer any of these from your other settings. Record the decision and the reasoning on the control that carries it, the same way you would a scoping decision for any framework.

What applying them seeds

Applying a framework seeds its curated starter controls, pre-mapped to the requirements they satisfy. For the children’s set those include the programme controls - a children’s online privacy programme, the direct and online privacy notices, verifiable parental consent, consent-exception handling, parent review, refusal and deletion requests, and minimised collection in children’s activities - alongside the app-store ones: audience declarations and metadata, child-appropriate experience and parental gates, children’s advertising and monetisation controls, third-party SDK and API governance, neutral age screening for mixed audiences, and online-safety controls for children’s social features.

Because those controls are shared across the frameworks that map to them, the audience determination, SDK inventory and ad-review records you keep for one store count toward the others that ask for the same thing.

Evidence that is per-store, not shared

Much of the underlying work is shared - the crosswalk maps one control to every requirement it satisfies, so implementing it once improves readiness across all four. Some evidence genuinely is not shared, and duplicating a single artefact across stores is the most common way a programme looks complete and is not:

• Ad inventory and SDK choice. Each store qualifies the supplier differently, so the evidence differs: for Google, that the SDK version you ship appears on its published self-certified list; for Apple, that the ad service publicly documents Kids Category practices including human review of creatives; for Amazon, that no Amazon Advertising or Associates inventory is served in a child-directed context at all.
• Age gating. A parental gate and a neutral age screen are different mechanisms answering different questions, and neither is verifiable parental consent. Keep them as separate controls with separate proof.

Removing a framework

Removing a framework from the workspace stops it being scored. It does not remove an obligation, and on Apple it does not even remove the store’s: once customers expect an app to meet the Kids Category requirements, later updates must keep meeting them even if the category is deselected. Treat removal as a change to what Keel tracks, not as a change to what binds you.

Next steps

• Frameworks & crosswalks: how one control counts toward many frameworks.
• Evidence: attaching the artefacts named above to the controls that carry them.
• Policies: framework-mapped policy templates.