Children under DPDP: why the age threshold matters to product design

A product used by sixteen-year-olds cannot be designed around a foreign privacy threshold and then labelled ready for India. The DPDP Act defines a child as a person under eighteen. That definition affects the account journey, the data you collect, the features you enable and the decisions you need to revisit as a user grows older.

The design problem is broader than adding a date-of-birth field. A field can collect an answer without establishing that the surrounding process is appropriate for children.

Keep the threshold and commencement separate

The definition in section 2(f) is part of the commenced definitions. The substantive children duties in section 9 are scheduled for 13 May 2027 under the commencement notification, so on 22 October 2026 they are provisions to prepare for in the notified framework, rather than already operative duties.

Once applicable, section 9 will address prior verifiable parental or lawful-guardian consent, processing likely to harm a child’s wellbeing, and tracking, behavioural monitoring and targeted advertising directed at children, subject to relevant statutory exceptions. Read the text with the October 2026 correction, which does not lower the under-eighteen definition or accelerate commencement.

Do not import an age of thirteen or sixteen from another regime. Also do not treat section 9(5), which permits a notified safe-processing age exemption for a fiduciary, as a general reduction already available to every business. Any claimed notification needs current, specific verification.

Map the features children may actually use

List the paths through which a child could reach the service: direct signup, an account created by a parent, a school invitation or access through an existing family account. Then map the data collected at each stage and the features activated before the age assessment is resolved.

An age question at the end of onboarding may come after extensive tracking or profile creation. Move the relevant decision early enough to affect the processing it is supposed to control. Decide how the product behaves when the answer is uncertain or inconsistent, rather than treating uncertainty as permission to use the adult pathway.

This does not justify collecting every user’s identity document by default. Choose a proportionate method based on the service, the proposed processing and the reliability needed. Assess what the method itself collects, who receives it and how its evidence will be protected.

A hypothetical learning-app review

A learning app serves school students and adults preparing for examinations. Its original design activates the same behavioural profile for every new account, then asks for age later. During review, the team moves the age-related decision before the features that depend on it.

The app defines an adult pathway, a child pathway with the relevant parental process, and an unresolved pathway that limits the affected processing while the issue is addressed. It separately assesses whether particular educational activities fall within an exact exception. It does not label the entire app exempt because some users are students.

The team tests a parent-created account, a teenager registering directly and a record whose age information needs correction. These cases reveal whether the decision actually changes the data flow, instead of merely displaying different wording on the screen.

Do not let an exception erase the wellbeing question

Rule 12 and the Fourth Schedule contain conditional exceptions affecting section 9(1) and 9(3). They do not remove section 9(2)’s wellbeing restriction. Read the class, purpose and conditions together before relying on an exception for a feature.

A useful review records why the particular activity qualifies, which obligations the exception affects and which responsibilities remain. ‘Education’, ‘safety’ or ‘parent approved’ is not enough without that mapping. Parent participation is also not a reason to stop considering the child’s interests in the design.

Plan for changes over time

A user can reach adulthood, change their circumstances or correct an inaccurate age record. Decide who reviews the transition, what information the user receives and which permissions need reassessment. Do not automatically publish a previously private profile or activate unrelated marketing when a birthday passes.

Likewise, avoid claiming that every historical consent becomes invalid at the transition. Assess the relevant basis, purpose and new decision. Keep a limited record of what changed and why, rather than silently rewriting the account history.

The recurring failure is treating age as a static label. Build it as a decision that controls actual processing and has a safe route for uncertainty, correction and change. That makes the threshold useful in the product rather than decorative in a policy.