Chapter 13 — Children, Parents and Lawful Guardians

1. The hardest edge of the regime

Almost every obligation in this book is about balancing an enterprise’s interest in data against a principal’s interest in privacy. Children turn that balance into something the law treats as sharply non-negotiable. When the person whose data is being processed has not yet the age, the judgment, or the standing to decide for herself, DPDP stops asking the data principal to consent on her own behalf and instead hands the decision to an adult — a parent or lawful guardian — and surrounds that transfer of authority with a layer of protective prohibitions that do not exist for adults.

This is the chapter where the abstract idea of “consent” meets its hardest, most consequential case. And because the stakes are so much higher, the law’s demands here are correspondingly stricter, with narrowly conditioned exceptions. The idea this chapter is built around can be stated plainly:

The idea. Child protection under DPDP is not a “minor-safety label” or a compliance courtesy. It is a cluster of hard obligations with real engineering weight: verifiable parental consent before processing within Section 9(1), the separate well-being prohibition in Section 9(2), and the Section 9(3) restrictions on tracking, behavioural monitoring and targeted advertising. Relief under Section 9(4)/(5) is conditional and does not remove Section 9(2). An age gate alone establishes none of these outcomes. ACT:386–403.[1]

The Schedule sets a ceiling of ₹200 crore for failure to observe the additional obligations concerning children, alongside the same notification ceiling; the safeguard ceiling is higher, at ₹250 crore. These are maxima, not automatic fines, and the text does not explain them as a pricing model for legislative intent. The design consequence is simpler: test the processing itself, including supplier routes, rather than infer protection from an age label. ACT:1010–1030.[1]

2. The statutory frame, read carefully

2.1 Who the “principal” is for a child (Section 2(j))

A child is an individual who has not completed eighteen years of age (Section 2(f), ACT:63–64). The Act also does something important in its definitions.[1] Section 2(j) says that where the individual is a child, the “Data Principal” includes the parents or lawful guardian of such a child; and where the individual is a person with disability, it includes their lawful guardian, acting on her behalf. This is not a cosmetic detail. It means the rights a principal can exercise — the rights of Chapters 4 and 12 — are exercised on the child’s behalf by the parent or guardian, and that the consent that makes processing lawful is likewise theirs.

Any rights service the enterprise builds must therefore handle guardians: who the guardian is, how that is verified, and how the guardian’s consent or rights request is processed. The Chapter 12 identity-assurance machinery is guardian-aware by necessity: a request that arrives “for” a child must be authenticated against the adult, and the case record must distinguish the data subject (the child) from the requesting principal (the guardian) — the same actor/subject distinction implemented in Chapter 12. Grievances belong to Section 13 and Chapter 12, not to this chapter number.

2.2 Verifiable consent of the parent (Section 9(1))

Subject to an actually applicable exemption, before processing personal data of a child — or of a person with disability who has a lawful guardian — the Data Fiduciary must obtain the verifiable consent of the parent or lawful guardian, in the prescribed manner (Rule 10 for a child; Rule 11 for a person with disability). The word “verifiable” is the operative term and it carries engineering weight: the enterprise must be able to establish that the adult consenting is genuinely the parent or guardian, not merely that a form was ticked. This is a substantively higher bar than the general consent of Chapter 9.

Rule 10 requires appropriate technical and organisational measures and due diligence to check that the person identifying herself as the parent is an adult identifiable when required in connection with compliance with Indian law. The routes are reliable identity/age details already held, or voluntarily provided identity/age details, including a virtual token mapped to those details from an authorised entity. Its illustrations distinguish existing reliable records from new-parent verification using issued details or a mapped token; Digital Locker is a permitted route, not the sole mandated product. RULES:1173–1227.[5]

These routes implement the actual due diligence; a “low-risk” category cannot switch it off. Adult identity and age do not conclusively prove parentage. Record the parent declaration and any contrary evidence, escalate disputes, and collect additional relationship evidence only on an explained need. A child’s full identity document or biometrics are not this chapter’s default requirement. The consent action still needs a purpose, understandable notice and binding to the child record. RULES:1173–1227; ACT:204–216.[1][5]

Rule 11 is a separate route for a person with disability who has a lawful guardian: verify appointment by a court, designated authority or local level committee under the applicable guardianship law. It includes supported-decision and defined-person conditions; a disability label alone neither removes capacity nor authorises an adult to act. Store the appointment reference, scope and verification, not merely a relative’s assertion. RULES:1228–1267.[5]

2.3 The well-being gate (Section 9(2))

The fiduciary must not undertake processing likely to cause a detrimental effect on the well-being of a child. This is not a narrow “don’t show children scary content” rule; it is a forward-looking test applied at design time: does this processing risk harming the child’s well-being? It pulls a well-being assessment into any product that touches children, alongside the risk-to-rights assessment of the DPIA (Chapter 20).

The gate’s design-time placement is what makes it a gate rather than a review: it runs before the processing exists, alongside the Chapter 20 DPIA, and its artefact is a recorded assessment with a named owner. For products with child audiences, the assessment question set is concrete: does the processing enable contact with unknown adults; does it drive compulsive engagement patterns; does it expose the child to commercial pressure; does it make inferences about the child that a guardian could not see? A “no” answer set that cannot cite the design artefacts that make each no true is an assessment in name only.

2.4 Prohibitions with specific, not implied, relief

Section 9(3) prohibits tracking or behavioural monitoring of children or targeted advertising directed at them. “For their benefit” and parental consent are not general exceptions. But saying that no beneficial-monitoring carve-out exists is also wrong: Section 9(4), Rule 12 and the Fourth Schedule provide limited class/purpose relief. An educational institution’s qualifying education/safety monitoring is one example. Marketing does not become educational monitoring by relabelling the same profile. ACT:392–403; RULES:1269–1275,1701–1716.[1][5]

The prohibition’s reach through the modern adtech stack deserves explicit engineering treatment, because this is where products fail without ever intending to: the analytics SDK that builds behavioural profiles “for product improvement”; the advertising SDK that segments by device even when the user is a declared child; the personalisation engine whose “recommendations” are behavioural targeting under a kinder name. Each is Section 9(3) processing if it tracks or behaviourally monitors a child or targets advertising at one — and the enforcement question is not intent but the pipeline’s actual behaviour against child-flagged users. The recommended design rule: the child flag is an enforcement attribute, not a metadata field — it must gate the SDK configurations, the ad segments, and the profiling pipelines at runtime (Chapter 8’s entitlement model applied to this chapter’s prohibitions), and the negative tests (§5) provide bounded evidence about covered routes, not universal absence of profiling.

2.5 Exception eligibility is a decision, not a badge

The following is a condensed lookup, not permission to omit the full conditions. Rule 12 disapplies only Section 9(1) and (3) for the qualifying processing; Section 9(2) remains. The corrected Fourth Schedule definition labels are (a)–(g), including advertisement and educational institution; the corrigendum changes those labels, not the safety conditions. RULES:1269–1275,1682–1765; CORR:36–38.[5][6]

Section 9(5) separately permits a Government notification for verifiably safe processing by a specified fiduciary, specifying the age and relieved obligations. Neither a favourable product review nor this book’s fixture creates that notification. Q01’s search did not establish exhaustive absence of such instruments; no applicable instrument is established for these examples. Their decisions therefore claim no Section 9(5) relief. ACT:399–403.[1]

A reviewer should ask whether the proposed action is still within the exception after a product change. School-safety location access confined to a journey is different from an advertising SDK reading the same coordinates overnight. Keep the latter denied even if a parent agreed and the institution legitimately operates the former. This is a control boundary, not a word choice in the privacy notice.

3. The tension: verifying the adult without over-collecting the child

Here is the tension that makes children engineering genuinely hard, and it deserves to be met directly because the two halves pull against each other.

The verification half. To comply with Section 9(1) — verifiable parental consent — the enterprise needs some way to establish that the adult consenting is the parent or lawful guardian. That implies identity and age signals about the adult, and a mechanism to bind that adult to the child’s record.

The minimisation half. But every extra verification signal, and especially any that collects more data about the child (a photo, a document scan, biographical details), is itself additional processing — and DPDP’s necessity anchor (Chapter 8) says processing must be limited to what is necessary for the purpose. Collecting a child’s biometric or documentary proof “just to prove” an adult consented can violate necessity while creating a new, larger data risk. The thing being protected becomes the thing being over-collected.

The failure modes sit on either pole:

• Under-verification: an age gate a user can trivially lie about (a self-selected birth year, no guardian step, no verification link), leaving Section 9(1) unmet and the child’s data flowing into forbidden processing. The “consent” is ornamental.
• Over-collection: demanding a child’s sensitive documentation or an adult’s full identity pack merely to “verify” the relationship, violating necessity and amassing exactly the kind of sensitive data the Act is meant to protect.

The reconciliation is proportionate data collection while preserving the actual due diligence. Risk may determine extra checks, review depth and dispute handling; it cannot waive Rule 10’s adult/identifiable check or Rule 11’s appointment check. Use a reference to reliable evidence rather than copying a complete identity pack into every consent receipt. Restrict verification evidence to its reviewed purpose and apply Chapter 14’s retention decision, including the one-year layer where applicable. There is no exemption from security because the data was collected to protect a child. RULES:1173–1232,1153–1166.[5]

For an account with conflicting parent declarations, the recommended transition is to pause the disputed consent/representation authority, not delete the child’s history or award control to the last adult who logged in. Keep necessary safety/service decisions separately owned. For an adulthood transition, re-evaluate authority at the verified eighteenth birthday: retire parent-based prospective authority, invite the person’s own applicable choices and avoid converting old guardian consent into a new adult-marketing grant. Existing lawful evidence and pending rights cases retain their subject IDs. These are author-designed transitions rather than a statutory birthday API.

4. The design pattern: classify, verify, enforce, monitor

The controls for children form a four-step loop, and it is worth keeping the steps distinct because each has a different obligation behind it.

4.1 Classify

Determine whether the user may be a child — an age gate, a declared date of birth, contextual signals, or a combination. It is essential to be honest here: an age gate is a signal with an error rate, not a certainty. The enterprise should know — and be able to state — the accuracy of its classification method. This is the empirical-versus- hypothetical boundary that runs through the whole book: a claimed age-estimation accuracy is only as good as the evidence for it.

The classification decision also has a documented default posture: what happens to a user who declines to state an age, or whose signals conflict? The design recommendation this chapter makes explicit: unknown-age users in a child-plausible product are treated as children until proven otherwise — the fail-closed posture the rest of the book applies to legal status, applied to age. This is a conservative product choice, not a statutory rule for every unknown-age user.

4.2 Verify

Where child/parent processing applies, obtain the verifiable consent of the parent or lawful guardian under the applicable Section 9(1) and Rule 10/11 route, without risk-tier waivers of required due diligence. Apply a documented exception only to the processing it actually covers.[1][5]

4.3 Enforce

Apply the Section 9(2) prohibition through a recommended design review and monitor actual behaviour. Enforce Section 9(3) at runtime except where a recorded, applicable Section 9(4)/(5) exemption covers that specific processing; parental consent alone never supplies the exemption. ACT:386–403.[1] For an AI/adtech product (Chapter 21) that could serve a child audience, this is a concrete control, not a policy aspiration — the child flag gates the pipelines, per §2.4.

4.4 Monitor

Detect attempts to bypass the classification — an age-gate evasion, a guardian step skipped, a child’s data re-entering a monitoring flow — and log the evidence. The monitoring control exists to catch the failure that enforcement was meant to prevent. The abuse signals (§5’s tests) are the monitor’s fixtures: the evasion attempt itself, the re-entry of child-flagged data into a prohibited pipeline, the SDK that reconfigures itself around the flag.

5. A populated verification record and release specification

The child-control record is explicitly synthetic. CASE-101 uses SUB-004, born 2012-09-01, and claimed parent SUB-005. CHILD-CONSENT-001 records a held-details route with a stipulated reliable issuer reference and adult check, the parent’s declaration, a non-targeted account purpose and notice reference. It contains no real government identifier and claims no completed Digital Locker integration. DEC-002 rejects PUR-011, the separate child-targeted campaign, despite this token. Marketing cannot borrow the account consent.

The verification record also records the adverse branch: another adult challenges the relationship. The proposed state becomes disputed, and representation-based disclosure is paused for manual adjudication; the subject remains SUB-004. The birthday branch calls for fresh prospective authority, not a new subject ID. A separate Rule 11 specimen is an appointment-verification specification only: absence of appointment evidence means no guardian-authorised access. These records are useful precisely because they do not pretend the identity integration has already been implemented.

The SDK failure is the most instructive boundary. A gaming app can suppress its own campaign while an embedded mediation component still sends device identifiers. The delivered loopback exercise captures an actual HTTP request made by a deliberately leaking synthetic client and then tests a corrected client that omits the advertising call for a child. Captured bytes are local test evidence, not a vendor’s traffic, production telemetry or proof that every third-party endpoint is silent. The transcript and exact run outcome are in sdk-network-results.json. No request goes to an external ad network.

A real release must extend the specification across application versions, platforms, background jobs, consent changes and network destinations; inspect payloads and server-side profiles where contractually possible. A sample with no requests cannot show absence of a delayed server-side profile or establish that a behavioural model is harmless. Where supplier inspection is unavailable, record that limitation and prohibit the risky path rather than mark it proven safe.

6. Two decisions that must stay different

In CASE-103 an institution of learning provides a school-safety service to an enrolled child. The specimen restricts monitoring to that institution’s safety activity, names the responsible school role and excludes advertising, unrelated commercial analytics and open-ended location history. This illustrates the Part A3 condition; the implementation still needs an actual class assessment and a child-well-being assessment. A commercial edtech vendor cannot inherit the institution’s class just by selling it software. If it processes solely on instructions, record the processor relationship; its independent profile-building is a different activity. RULES:1701–1707,1757–1758.[5]

In CASE-101 the campaign owner proposes targeted promotions to SUB-004 after receiving a parent token. DEC-002 rejects the campaign because no applicable exception is established. Removing the ad SDK from the child path and using a non-targeted, separately reviewed experience is a redesign option; it is not a declaration that every contextual advertisement or recommendation is lawful. The DPO owns legal applicability, the child-safety specialist owns the well-being assessment and engineering owns the outbound-path evidence. None can substitute its approval for the other’s work.

This separation protects useful services as well as children. A blanket prohibition on every safety monitor would remove a deliberately conditioned route in the Rules. A blanket parental-consent override would erase the separate protection in Section 9(3). The chapter’s acceptance record preserves both sides instead of simplifying the law to a single boolean.

7. Remaining application and evidence work

Known Rules routes and Fourth Schedule conditions are supplied above, not left unread. Real use still needs reliable identity sources, appointment/relationship dispute resolution, product-specific well-being review, current notification checks and supplier/network coverage. Q01’s QL-004 bounds current-law completeness. The local SDK test does not qualify a supplier; the verification specimen does not validate any actual parent or guardian. Later launch review must replace those explicit assumptions with evidence.

The exercise for a reader is to take the school-safety record, add a proposed advertising destination, and explain why the former may remain conditionally permitted while the latter is stopped. Then change the parent’s status to disputed without changing the child’s identifier. The artifact is acceptable only if both decisions remain separately attributable and the grievance route continues through Chapter 12.

The question that hands the book its next chapter

Personal data, once lawfully collected under consent or a legitimate use — and under the stricter protections of this chapter — is never indefinite. The erasure trigger must be reconciled with the Rules retention layer and other applicable law, without retaining permission for unrelated use. That counterweight is the subject of Chapter 14, Retention, Deletion, Backups and Legal Holds — the deletion control plane that turns purpose completion into an evidenced erasure.

Sources

[1] https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf — Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) [2] https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf — G.S.R. 843(E), DPDP Act commencement notification [5] https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf — Digital Personal Data Protection Rules, 2025, G.S.R. 846(E) [6] https://www.meity.gov.in/static/uploads/2025/12/3c7ebbae0e5456f493f486e6845df86b.pdf — Corrigenda to G.S.R. 846(E), G.S.R. 892(E)

Contents · Reader guide and citation conventions · Artifact index