Guides
Part of Age restrictions are four separate rules that get mistaken for one law
Age restrictions policy template: what belongs in each section
An age restrictions policy template: a drafting skeleton for who may hold an account, what establishes a band, what is recorded, and how a wrong value is fixed.
Below is a drafting skeleton for a service operator's internal policy on age eligibility. The document says who may hold an account, how that is established, what a young account can do, and what happens when the answer turns out to be wrong. It is a starting point for a first draft and nothing more.
It carries no thresholds, no retention periods, no consent requirements and no jurisdictional language, because those depend on where you operate, what you do, and rules that keep moving. Have counsel review whatever you produce from it, for every market you serve, before it reaches a user.
Square brackets mark a decision only you can make. Do not ship a section you cannot fill in: a bracketed placeholder reads as a rule and enforces as nothing.
What to take away
- Write the policy around decisions the product actually makes, not around a legal summary. The summary will change; the decisions will still need answers.
- Every section that restricts someone needs a matching section describing how they get that reversed.
- Name an owner and a review date, or the document becomes a description of a system you no longer run.
The skeleton
1. Purpose and the decision this governs. One paragraph. [What this policy decides: who may hold an account, and what changes for accounts in each band.] Keep the reasoning here and the rules below; mixing them makes both harder to apply.
2. Scope. [Which products, which surfaces, which markets, and which account types.] State separately whether it covers accounts created before this policy existed, and what an absent age value means for them. Treating absent as adult and treating absent as unknown produce different systems, and the choice belongs here rather than in the code.
3. The bands we distinguish. [The bands, and why these and not others.] Give the reason, not just the numbers. When the reason is a rule, cite the rule; when it is a product judgment, say so. A band nobody can justify is one that gets changed by whoever complains loudest.
4. What establishes a band. [The signals accepted, in order of confidence, and which are sufficient alone.] For each: what it establishes, what it does not, and when it may be used. Say explicitly what happens when no signal is available, because unknown has to be a permitted state.
5. What is recorded. [The conclusion, the basis, the date established, and what the value is used for.] Then, separately: [what evidence is retained, in what form, for how long, and who may see it.] This is the most sensitive paragraph in the document and the one counsel will want first. Where a regulator has published expectations about children's data, that publication rather than any summary is what the paragraph should be written against: the United Kingdom information regulator's children's code guidance and resources is one example, covering one jurisdiction. The reasoning behind separating these fields is in age as a data field.
6. Defaults by band. [For each band: what is on, what is off, what is discoverable, what can be changed by the user, and what requires a guardian.] This section describes what a young user actually experiences, which makes it more consequential than the eligibility rule above it and is usually the thinnest part of a first draft.
7. Guardian and supervision route. [How a supervising adult is linked, what they can see, what they can change, and how the link ends.] Include what happens when the young user reaches a band boundary, and whether the link ends automatically or has to be ended by someone.
8. Mismatch and correction. [What happens when a stated age is contradicted, who reviews it, what evidence is accepted for a correction, and who may make the change.] Record corrections without erasing the previous state. Decide here, in advance and in writing, what happens to an account whose original value was false, because that decision is much worse made during an incident.
9. Restriction, appeal and restoration. [What is restricted while a question is open, how a user contests it, who decides, and how long each step takes.] Commit to a time. Hold the appeal to the rule that it may not ask for more information than the original check did, which is a standard worth writing down because it is otherwise quietly breached. Related failure modes are set out in the risks a check creates.
10. Third parties. [Which vendors are involved, what each receives, what each retains, where, and what happens at the end of the contract.] If you cannot fill this in from the contract, that is the finding, and it belongs in front of whoever signs it.
11. Records, ownership and review. [Who owns this document by name or role, the review cadence, and the triggers that force an earlier read.] Useful triggers: a new market, a new surface, a new vendor, a change in the bands, a change in what reads the age field, or any incident whose handling was contested.
12. Version block. Version, effective date, previous version, and who approved it. People are held to the version in force at the time, and you cannot show that without the history.
The three decisions people leave bracketed
Retention of evidence, the meaning of an absent value, and what happens to an account created with a false age. Each is uncomfortable, each is deferred, and each becomes an emergency later on somebody else's timetable. Answer them in the first draft even if the answer is provisional.
Three Bracketed Decisions
How long is evidence retained?
Set a retention period
Evidence kept indefinitely
Before it goes anywhere near a user
- Counsel review for every market you serve, on the full text rather than a summary, covering both the eligibility rules and the data handling.
- A read by someone who handles support, checking whether the appeal and correction routes can actually be operated at volume.
- A walk through the product against section 6, confirming that the defaults described are the defaults that exist.
- A plain language pass, and a separate pass on anything a young user or a guardian will read directly.
- Translation where you serve users in another language, with the review repeated on the translated text.
- A check against your terms of service, your privacy notice and your store listings for contradictions. Three documents saying three different things about age is common and indefensible.
What this is not
A structure, not legal advice, and not a compliance product. It cannot tell you what your obligations are, because those depend on where you operate and they change.
Anything with legal weight in your final text should come from a qualified adviser or from the responsible body's own current publications. The Federal Trade Commission's questions and answers on its children's privacy rule is one illustration, and it describes one country's regime.
How rules in this area are built, so you can read one, is covered in the four parts of an age rule. The layers that get confused with each other are in four rules mistaken for one; and the outward-facing policy on how your own staff use third-party services is a different document, sketched in the platform use skeleton.
Common questions
Can this be one page?
Sections 3, 4, 6 and 9 can be short but cannot be omitted. Everything else can be compressed or referenced out to documents you already have.
Do we need this if we serve adults only?
Yes, and sections 2, 4, 8 and 9 do most of the work. A service for adults still has to say what establishes that, and what happens when the answer is contested.
Should users see it?
Users need the rules that apply to them and the routes available to them, in language they can act on. That is usually a shorter, separate document that must not contradict this one.
