Why this needs its own section, not a paragraph bolted onto your existing policy

The age-assurance mechanic is genuinely different from how most apps describe their other data practices: you're not collecting a birthdate or an ID yourself, you're requesting a signal from the app marketplace (Apple or Google) and acting on the result. A privacy policy that folds this into a general "information we collect" section, worded like the rest of your data-collection language, tends to either overstate what you actually receive or bury the one distinction (platform-verified signal, not developer-collected data) that matters most here. Give it a dedicated section.

Starting language for the privacy-policy section itself

Illustrative starting language -- fill in your own brackets, then have counsel review it

"[App Name] uses age-assurance signals provided by the app marketplace you downloaded this app from (the Apple App Store or Google Play Store) to determine whether age-appropriate content restrictions or parental consent requirements apply to your account. We do not independently collect, store, or verify your birthdate, government ID, or other identifying documents to determine your age. Instead, we request an age-category signal from the platform you're using -- the platform, not [App Name], is responsible for determining and verifying that signal, using methods it discloses in its own privacy documentation."

Two fill-in choices matter more than the rest of the wording: describe what your app actually does when it receives a "consent required" or "consent withdrawn" signal -- don't describe restriction behavior you haven't built and tested -- and name the specific states you determined apply to you (see our companion decision guide), not "all states with such laws" as a hedge. A policy naming the wrong states, or none, is less defensible than one that's specific and gets updated when the underlying law changes.

The parental-consent screen: what you actually control

On both Apple's and Google's current implementations, the consent dialog a parent interacts with is largely rendered by the platform itself, not your app -- your role is triggering the request and handling the result, not designing a competing custom screen. Where your own copy matters is the surrounding context you do control: onboarding screens, your settings page, your support documentation. That copy should plainly state what permission is being requested, and just as plainly state what you are not collecting to make the request -- most apps under-explain this half, and it's the half that actually reassures a parent reading it.

Consent-withdrawal copy: the one honesty rule that matters most here

The rule

When a parent withdraws consent and your app has to tell the affected minor, keep that notice honest and non-manipulative. No "your friends miss you" dark-pattern re-engagement language, no urgency pressure aimed at getting a minor to go convince a parent to re-approve. This entire product category exists because of child-safety legislation -- shipping a guilt-trip screen at exactly the moment consent was withdrawn is the fastest way to turn a compliance feature into a legal and PR liability at once.

Structurally, the notice needs three things and nothing more: state plainly that access has been restricted or paused, tell the person how to raise it with their parent or guardian if they believe it's a mistake, and offer a real support contact. Anything beyond that risks becoming the dark pattern the rule above warns against.

Keep a visible change log

Add a "Last updated" line to this section and a short changelog entry every time you touch it, noting which state, law, or API change triggered the edit. Two of the four state deadlines covered by these laws were themselves delayed by amendment in the months before this guide was written -- a policy that silently changed with no visible history is worse evidence of active compliance than one with a dated trail, if either is ever reviewed by a court, a regulator, or your own future self trying to remember why a line changed.