Independent DPDP educationBrowser-only workspace · no accounts, analytics or submissions

01 Children + guardians

Children's data: age, parent verification and high-risk product choices

Age and parent verification are only part of the design. Teams must decide whether the product should collect, profile, track or retain the data at all.

The child-data design gate

Product need is challenged before age or parent evidence is requested, then access and lifecycle remain bounded.

The child-data design gateProduct need is challenged before age or parent evidence is requested, then access and lifecycle remain bounded.01Audiencelikely age · context · risk02Needremove · separate · minimise03Verifyage · adult · authority04Protectaccess · feature · monitoring05Lifecycletransition · withdraw · erase
  1. 01
    Audiencelikely age · context · risk
  2. 02
    Needremove · separate · minimise
  3. 03
    Verifyage · adult · authority
  4. 04
    Protectaccess · feature · monitoring
  5. 05
    Lifecycletransition · withdraw · erase
Editorial operating model. Replace it with your evidenced systems, owners and decisions.

02 Provision-aware reading

Three states that must not be flattened.

01Operative

What is operative now

· in force

Selected definitions, institutional machinery and rule-making provisions are in force. That does not make every substantive operating duty discussed in this article currently operative.

Check the phased ledger
02Scheduled · 18 months

What is notified for later

· notified future commencement

Most day-to-day Data Fiduciary duties discussed here sit in the notified eighteen-month cohort. The displayed date is derived from the status ledger and must be rechecked against later instruments.

Check the phased ledger

The DPDP Act defines a child as an individual under eighteen and contains obligations and restrictions for processing children’s personal data. The final Rules describe approaches to verifiable parent consent and contain conditional exemptions for specified classes and purposes. These substantive provisions sit in a notified future cohort in the current source ledger.

A safe product review should not begin by collecting identity documents from every user. It should begin with product scope, likely audience, data minimisation and whether high-risk features can be removed or separated. Any age or parent-verification method needs a threat model, privacy analysis, accessibility plan and failure path.

Challenge the feature before selecting verification

Ask whether the service needs to know exact age, whether a broader age band is sufficient, whether the feature can be unavailable to children and whether the experience is likely to attract them. Map profiling, targeted content, tracking, location, contacts, messaging, public visibility and behavioural monitoring separately. Removing a high-risk feature may be safer and simpler than building a complex verification flow.

Record the decision and evidence. Do not infer that an audience disclaimer changes actual use. Research, support contacts and product analytics may reveal a child audience even when marketing says otherwise. Escalate uncertain scope and fact-specific exemptions to qualified reviewers.

Design proportionate age signals with failure paths

An age gate can be self-declaration, estimation, assurance or identity-backed verification, each with different error and privacy risks. Choose a method proportionate to the product and harm. Record false acceptance, false rejection, circumvention, bias, accessibility and appeal considerations. Do not collect a government identifier simply because it appears decisive.

Specify what happens when age is unknown, disputed or changes. Avoid exposing a child’s status to other users. Limit raw evidence, separate verification tokens from product profiles where feasible and set a deletion event for verification artefacts.

Verify the adult and relationship without creating a new risk

The final Rules describe due diligence for checking that the individual identifying as the parent is an identifiable adult, including reliable details already available or voluntarily provided identity/age details or authorised virtual tokens. Translate that into a threat model: impersonation, shared devices, stolen documents, replay, coerced consent and support overrides.

Parent consent evidence should identify the product, child account, purpose, notice version, adult verification method, affirmative action and time without storing more identity material than needed. Provide a correction, withdrawal and support path that does not disclose the child’s account to an unauthorised person.

Treat exemptions as narrow, conditional routes

The Fourth Schedule describes classes such as specified health, education, childcare and transport contexts with conditions, as well as limited-purpose routes. It does not create a universal exemption for every organisation in those sectors or for every type of processing. Map the exact class, purpose and condition before relying on it.

Keep section 9 restrictions distinct. An exemption applying to one obligation or purpose must not be expanded by convenience. Product, legal and operations should record the decision, system boundaries and monitoring needed to keep the processing inside the condition.

Constrain features, access and human intervention

Review default visibility, messaging, recommendations, behavioural scoring, location, advertising, sharing and moderator tools. Apply least privilege to staff and support access. High-risk escalations should have trained reviewers and evidence, not informal screenshots in chat. Monitor abuse without turning every interaction into permanent surveillance.

Provide understandable information for both adult and child audiences where appropriate. Avoid manipulative design that pressures acceptance. Make safety, refusal and appeal routes usable on mobile and with assistive technology.

Plan transitions, withdrawal and deletion

A child account may become an adult account, a parent relationship may change and consent may be withdrawn. Define how the product identifies the transition, what new notice or choice is needed and which parent evidence expires. Do not carry restrictive or revealing child-status flags indefinitely.

Test search and deletion across profiles, messages, support records, safety systems, providers and backups using synthetic data. Record justified exceptions and residual copies. The exercise should include an unauthorised request and an inaccessible verification route so failure handling is evaluated, not only the happy path.

Put the next review into somebody's working queue.

A role label is a starting point. Assign named internal owners, evidence locations and review dates in an approved system; this site stores none of them.

01

Founder

  • Decide which child-facing risks the product will not accept.
  • Fund safety and appeal work before growth features.
02

Legal / Privacy

  • Map section 9 and any exemption narrowly to facts.
  • Review verification evidence, retention and transition rules.
03

IT / Security

  • Threat-model impersonation, tokens and support access.
  • Protect and expire raw verification material.
04

Product / Engineering

  • Remove unnecessary high-risk features and data.
  • Build accessible refusal, appeal, transition and deletion paths.
05

Operations

  • Train support for disputed relationships and safety escalation.
  • Prevent identity evidence from spreading through informal channels.

Verification is not the whole safety design

The strongest first question is whether the feature and data are needed for a child at all. Where processing continues, combine proportionate verification with restrained features, bounded evidence, trained operations and tested lifecycle paths.

The law and exemptions are conditional and future-cohort in this status record. Obtain qualified advice before relying on a route for a live product.

Sources and change log

Gazette instruments govern the text and commencement. Government explainers are contextual; this field note remains editorial analysis.

  1. Act No. 22 of 2023Digital Personal Data Protection Act, 2023

    Sections 2(f) and 9: child definition and processing obligations/restrictions

  2. G.S.R. 846(E)Digital Personal Data Protection Rules, 2025

    Rules 10–12: verifiable parent/guardian consent and exemptions

  3. G.S.R. 846(E)Digital Personal Data Protection Rules, 2025

    Fourth Schedule: conditional classes and purposes for section 9 exemptions

  4. G.S.R. 843(E)DPDP Act commencement notification

    Paragraph (c): section 9 and related Rules in the eighteen-month cohort

  5. G.S.R. 892(E)Corrigendum to the Digital Personal Data Protection Rules, 2025

    Fourth Schedule note lettering and other published corrections

Change log

Initial private-preview article created against the final Rules, commencement notification and published corrigendum.

Human-review gate: pinpoints, status and fact-specific interpretations must be rechecked before public reliance.

12 Continue with evidence

Turn the reading into a bounded operating record.

Use a template, inspect the mapped controls or answer the readiness assessment with only what your team can retrieve.

32-control catalogueOperating templatesReadiness assessment