A child cannot consent, so the question is what you do instead

The age gate, and the only correct default behind it

The gate is a per-key setting, so it can be switched on for one property without touching the others. Where it is on, it renders before the banner and blocks it — no consent surface appears until the age question has been answered, because a banner shown first has already asked a child for a consent they cannot give.

Two answers. An adult declaration stores a session-scoped flag and the normal banner follows. A minor declaration asks for the child's date of birth and the parent or guardian's name and email, and all three are validated before anything is written — a date of birth that does not make the person under eighteen today is refused rather than stored, because it is also the date the age-out process below runs from.

What a self-declared minor is actually allowed to consent to

This is the part most descriptions get vague about, so here it is precisely. Where the visitor has declared themselves under eighteen, nothing they choose is granted. Each purpose they ticked is written as its own record and held in a pending-guardian state, never active — and every processing, analytics and export path that means "consent in force" reads only active records, so a held choice is never treated as consent. What the child chose is kept rather than discarded, so the guardian is asked about exactly that and nothing more.

Notice what that is not. It is not a rule that says "no targeted advertising for minors" or "no behavioural tracking for minors" implemented as a category filter. It is a blanket hold: no purpose a minor selects is in force until a guardian grants it, which necessarily includes advertising and analytics because it includes everything. A category-based rule would have to be maintained as new purposes are added; a blanket hold does not.

Every record produced in that state is stamped as a minor record, with the child's date of birth and the guardian email held against it for the age-out process described below. The one route that does not hold is the server-to-server capture API: there the calling system asserts that it has already obtained verifiable parental consent itself, the records are written active, and that assertion is the integrator's to stand behind.

How a guardian approves, and what is deliberately not collected

Verifiable is the load-bearing word in §9. A checkbox saying "I am the parent", ticked by the child, verifies nothing — the approval has to come from somebody else, through a channel the child is not sitting in front of.

The guardian email given at the age gate receives a single-use link, valid for fourteen days. Opening it is read-only: the page shows which organisation is asking and for which purposes, and records nothing. That is deliberate — a mail scanner that follows every link, or a parent who only wants to read before deciding, must never be able to give consent for a child by accident. Only an explicit answer changes anything.

• Grant — the guardian actively approves. The held records for the purposes asked about become active, the approval is stamped onto each of them as its parental proof reference, and the link is spent.
• Decline — the guardian refuses, optionally saying the child is not theirs or that they do not consent. The held records become declined, anything already active is withdrawn through the same engine every other withdrawal uses, and the link is spent.
• No answer — an expired link can be re-sent from the operator queue with a fresh fourteen days. An invite nobody answers is closed about a month after it was last sent: the held records become declined, never consent, and the guardian's email and the child's date of birth are cleared from them.
• Not collected — no identity document is requested from the guardian or stored by the platform. Asking a parent for their ID in order to process a child's choices collects more personal data than the purpose needs.

What happens on the child's eighteenth birthday

Consent given by a parent does not silently become consent given by the adult that child becomes. The age-out flow exists because the alternative — continuing to process an adult's data on a parent's ten-year-old decision — is not consent by any reading of §6.

The guardian receives a link. Opening it validates without consuming anything and shows the child's email already on file, so the guardian confirms rather than retypes an address. Submitting sends the now-adult child a signed consent link of their own and consumes the guardian's token.

The child then gives their own consent, and the system creates fresh adult records for every purpose covered by the link and retires the minor ones. The minor records are retired rather than deleted — the history of what was processed under parental consent is exactly the thing you would need to produce if anyone ever asked.

Where children's consent breaks in practice

The first failure is scope. Organisations enable the age gate on the consumer site and not on the support portal, the careers page or the mobile web view, and a child arrives through the one that was missed. The gate is a per-key setting precisely so it can be rolled out gradually — which also means it can be forgotten gradually.

The second is the unanswered invite. A guardian email that lands in spam, or goes to an address the child typed in a hurry, leaves the child's choices held until the invite lapses. The operator queue shows each invite as sent, expired, granted or declined, and somebody has to own it by name — a held record is safe, but a family that is never asked again is a user you have quietly lost.

The third is quieter and more expensive: data collected before the gate was switched on. The gate governs what happens from now. It does not retrospectively identify which of last year's records belonged to a fourteen-year-old, and there is no honest way to reconstruct that. It is one of the arguments for switching it on early rather than when the question is first asked.

What the platform does not decide for you

It does not decide whether your service is directed at children, which is a judgement about your product rather than a setting. It does not decide whether you qualify for any exemption the Central Government may notify for classes of fiduciary or purpose — Rule 12 of the DPDP Rules sets out those exemptions for children's data. And it does not determine age — self-declaration is a declaration, and the verification that follows is of the guardian's approval, not of the child's age.

A note on the Rules while you are here. The verifiable parental consent obligation sits in §9 of the Act; the due diligence — checking that the person identifying as the parent is an identifiable adult, against details you already reliably hold or against identity and age details or a virtual token issued by an entity entrusted by law or the Government — is Rule 10 of the DPDP Rules. An emailed link proves that somebody controls the guardian address and made an explicit decision; it does not prove that person is an adult or the child's parent. Whether that is enough for your service, or whether you also check the approval against details you already hold, is the Rule 10 judgement — and it is yours, not a setting.