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 ledger01 Children + guardians
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.
Code-native system diagram
Product need is challenged before age or parent evidence is requested, then access and lifecycle remain bounded.
02 Provision-aware reading
· 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· 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 ledgerPreparation record · not a statutory status
Build a retrievable operating record now: owner, system, evidence, test result, exception and next review. This is readiness work, not a prescribed certification pack or legal conclusion.
Check the phased ledgerExecutive summary
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.
Operating note · 01
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.
Operating note · 02
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.
Operating note · 03
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.
Operating note · 04
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.
Operating note · 05
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.
Operating note · 06
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.
Five-role checklist
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.
Conclusion
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.
Pinpoint official record
Gazette instruments govern the text and commencement. Government explainers are contextual; this field note remains editorial analysis.
Sections 2(f) and 9: child definition and processing obligations/restrictions
↗Rules 10–12: verifiable parent/guardian consent and exemptions
↗Fourth Schedule: conditional classes and purposes for section 9 exemptions
↗Paragraph (c): section 9 and related Rules in the eighteen-month cohort
↗Fourth Schedule note lettering and other published corrections
↗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
Use a template, inspect the mapped controls or answer the readiness assessment with only what your team can retrieve.