Children, parents and guardians
Section 9 and Rules 10–12 are scheduled for 13 May 2027.
The Act defines a child as an individual under eighteen. Before processing a child’s personal data, a Data Fiduciary must obtain verifiable consent of the parent, subject to the Act and Rules. The framework also addresses lawful guardians of persons with disability.
Prohibitions and safeguards
Section titled “Prohibitions and safeguards”A Fiduciary must not undertake processing likely to cause a detrimental effect on a child’s well-being, or tracking/behavioural monitoring of children or targeted advertising directed at children, subject to statutory exceptions. Product teams must inventory analytics, advertising, push, recommendation, location and third-party SDK paths; a front-door age gate does not neutralise hidden tracking.
Assurance ladder
Section titled “Assurance ladder”Use the least intrusive method that reaches the required confidence:
- an already verified adult account with a known relationship;
- service-held age/relationship facts collected for another lawful purpose;
- token or attribute assertion from an approved external provider;
- manual assisted evidence with redaction and rapid disposal;
- regulated identity/authentication only where legally available and proportionate.
Do not collect or store Aadhaar merely because it is convenient. If Aadhaar authentication or offline verification is used, the entity must have the correct UIDAI role, consent, security, storage and audit controls under the current consolidated regulations.
Data model
Section titled “Data model”ChildAssuranceCase tenant_id, case_id, child_subject_ref service_id, risk_tier, selected_method, rationale parent_or_guardian_subject_ref relationship_type, assurance_provider_ref verification_outcome, verified_at, expires_at evidence_ref (redacted/tokenised), disposal_at exception_id, reviewer_id, audit_event_ids[]Raw documents are not copied into the control plane by default.
Exceptions
Section titled “Exceptions”Rules 10–12 and the Fourth Schedule create fact- and entity-specific exceptions, including defined healthcare, educational, safety and childcare contexts and possible age-relaxation processes. OpenDPDP offers an exception catalogue that requires:
- exact Schedule entry or notification;
- entity/service facts;
- allowed processing and prohibited spillover;
- expiry/review date;
- legal approver;
- regression test.
An exception is not a blanket “child mode off” switch.
Failure and abuse
Section titled “Failure and abuse”- Parent account takeover triggers re-verification before a new grant or export.
- Conflicting guardians enter manual legal review.
- A child ageing into adulthood creates a policy re-evaluation; it does not silently preserve parental control forever.
- Repeated age claims across linked accounts are risk signals, not automatic proof of fraud.
- Advertising SDK egress in a child-configured journey is a release-blocking test failure.
Acceptance tests
Section titled “Acceptance tests”- Given a low-risk education service and an already verified parent relationship, when consent is requested, then no new identity document is collected.
- Given a targeted-advertising SDK is enabled, when the child policy test runs, then production approval fails.
- Given a healthcare exception is asserted, when its purpose expands to marketing, then the exception does not apply and a new legal decision is required.