DPDPA children's data and Section 9 obligations

ControlForge free guide · 2026-05-24 · Reflects DPDP Act 2023 Section 9, DPDP Rules 2025 Rule 10, and the Schedule 4 exemption framework

Quick reference

The hard fact: India's DPDPA defines a "child" as anyone under 18 — one of the most conservative definitions globally (compare GDPR's 16 with member-state discretion to 13, US COPPA's 13). For most Indian consumer-facing organisations, the majority of teenage users become legally children for DPDPA purposes.
Section 9 imposes three operationally hard requirements:
Verifiable parental consent before processing any personal data of a child (Section 9(1)) — a click-through cannot satisfy "verifiable".
Prohibition on processing likely to cause detrimental effect on the well-being of a child (Section 9(2)) — an intentionally open-ended standard.
Prohibition on tracking, behavioural monitoring, and targeted advertising directed at children (Section 9(3)) — substantial restrictions with narrow exemptions.
Penalty exposure: failure to fulfil obligations in respect of children's data is in the highest penalty tier under DPDPA Schedule, up to ₹200 crore per violation.
Schedule 4 / Rule 10 exemptions: certain classes of Data Fiduciaries (healthcare, educational institutions for limited purposes, providers for child safety) face narrower Section 9 obligations. The Fourth Schedule has not been fully published as of mid-2026; organisations should operate under the assumption that full Section 9 compliance is required absent specific exemption.
Audience: Product Managers, UX leads, DPOs, Privacy Counsel, CTOs at consumer-facing digital services — gaming, social media, education, content, e-commerce, financial services with minor customers.
ControlForge density: 15+ controls across cl-consent-management, cl-data-subject-rights, cl-children-data-protection, cl-age-verification, and cl-notice-and-transparency; cross-walked with GDPR Article 8, COPPA, and emerging international children's privacy regimes.

Why this matters disproportionately to Indian organisations

Three structural features of DPDPA make children's data compliance harder for Indian organisations than the equivalent compliance under GDPR or COPPA.

First, the age threshold is 18 — the highest of major privacy regimes. GDPR sets the threshold at 16 (with Member States allowed to lower it to 13); US COPPA applies under 13; Australia's Privacy Act treats under 18 as a vulnerability factor but does not impose absolute consent rules. India's blanket 18-year threshold means a teenager who can drive, work, sign contracts under many provincial laws, or vote in some restricted-purpose contexts is still legally a "child" under DPDPA. The implication: a far larger portion of the consumer-facing user base than most organisations realise falls under Section 9 obligations.

Second, the "verifiable" standard is structurally demanding. The DPDPA explicitly rejects approaches that GDPR Article 8 implementations have often relied upon — clicking a checkbox attesting to parental status, typing a parent's email, age self-declaration. The DPDPA Rules 2025 Rule 10 elaborates the verification standard. Practical verification techniques that have emerged: - Government ID-based verification of the parent (Aadhaar, PAN, passport with adult attestation). - Credit card or banking-based verification (a transaction from an account presumptively held by an adult). - Video-KYC of the parent in the same flow as the child's account creation. - Digital identity attestation through services that bind to Aadhaar with virtual identity / tokenisation.

None of these is operationally cheap. All add friction to the user journey. The trade-off between friction and verifiability is the central UX decision.

Third, Section 9(3) prohibitions are absolute, not consent-mediated. Under GDPR, behavioural advertising to a minor with valid parental consent and assessed legitimate interest can sometimes be defensible. Under DPDPA, tracking, behavioural monitoring, and targeted advertising directed at children is prohibited regardless of parental consent. The Section 9(3) categories cannot be unlocked by consent — they are absolute prohibitions for the protected category.

The net effect: many consumer-facing business models that work for adults need substantial re-architecture for minor users. Lighter ad targeting (or no targeting), reduced behavioural analytics, restricted personalisation, and substantial friction in account creation are all design consequences.

What Section 9 requires

The statutory language: "The Data Fiduciary shall, before processing any personal data of a child or a person with disability who has a lawful guardian, obtain verifiable consent of the parent of such child or the lawful guardian, as the case may be, in such manner as may be prescribed."

Three non-negotiable elements: - "Before processing" — verification must complete before any personal data is collected or processed. The trust-then-verify pattern (collect first, verify retroactively) is explicitly impermissible. Even collecting "name + email to verify" counts as processing; you must have parental consent before that step. - "Verifiable" — independent confirmation of two things: (a) the person providing consent is actually the parent or guardian, (b) that person is an identifiable adult. - "In such manner as may be prescribed" — meaning following the DPDPA Rules 2025 Rule 10 framework.

Verification methods deemed acceptable in 2026 practice: - Aadhaar-based verification with virtual ID / tokenisation for the parent. - DigiLocker-based attestation providing government-issued identity verification. - Video KYC of the parent with subsequent signature on the consent record. - Credit card / banking transaction from the parent (where the transaction acts as the verification). - Government ID upload with face match / liveness check.

Verification methods not acceptable: - Parent's name typed by the child. - Email address of the parent typed by the child (without verification). - Self-attestation by the child ("I am over 18"). - Parent's signature on a paper form returned via mail (acceptable as a backup but typically insufficient as primary verification given the operational fraud risk).

Section 9(2) — the well-being standard

The statutory language: "A Data Fiduciary shall not undertake processing of personal data that is likely to cause any detrimental effect on the well-being of a child."

The intentional open-endedness: this is a higher-order standard not dependent on specific prohibitions. The DPBI is expected to issue guidance over time on what constitutes "detrimental effect on well-being". Anticipated areas of concern: - Processing that exposes children to predatory content or contact. - Processing that drives behavioural patterns (e.g. excessive engagement, gambling-adjacent patterns). - Processing that creates discrimination against children based on profile data. - Processing that exposes children's data to third parties without strict necessity.

Operational implication: organisations processing minors' data should conduct a child-well-being impact assessment as part of the product development / DPIA cycle. Document the assessment and the mitigations.

Section 9(3) — absolute prohibitions

The statutory language: prohibits tracking or behavioural monitoring of children and targeted advertising directed at children, with narrow exemptions (via Schedule 4 / Rule 10).

Behavioural monitoring: includes profile-building, engagement analytics, persistent device tracking, cross-context tracking. The Section 9(3) reading is strict — these activities are not permissible for child users even with parental consent.

Targeted advertising: includes any advertising selected based on the child's profile, behaviour, characteristics, or inferred attributes. Untargeted advertising (context-only, not user-specific) is generally permissible.

Exemptions under Schedule 4 / Rule 10: - Healthcare providers processing children's data for medical treatment purposes are exempt from the verifiable parental consent requirement for that specific purpose. - Educational institutions for educational purposes have specific carve-outs (the precise scope is in the Schedule 4 framework that is partially published). - Child safety purposes — processing to detect child safety risks, abuse patterns, etc.

The exemption framework is narrow and purpose-bound. An exempt entity (e.g. a healthcare provider) does not become broadly exempt from Section 9; the exemption applies only to processing within the specified purpose.

The age-verification problem

Before parental consent comes age verification: knowing the user is a child. This is operationally where many Indian implementations stumble.

Age verification approaches in 2026 practice:

Self-declaration: the user enters age or date of birth. This is the most common pattern; it is the least reliable. The DPDPA does not explicitly require more than self-declaration where there is no reason to suspect the declaration is false, but the "reason to suspect" standard is operationally vague.

Account-pattern-based detection: behavioural signals (device usage patterns, account characteristics, content consumption patterns) that suggest the user may be a minor. Section 9(3) prohibition on behavioural monitoring of children creates a regulatory loop here — using behavioural patterns to detect children is itself behavioural processing of (potential) children. The cleanest position is to use the signals to trigger age re-verification, not to act on the inference directly.

Document-based verification: government ID upload at signup. High-friction; produces high cart abandonment in low-engagement contexts.

Third-party age estimation services: emerging market — services that estimate age from selfie images, document scans, or other biometric signals. Operating quality varies; reliance on these requires due diligence.

Account-linkage: where the user already has a verified Aadhaar / KYC profile through another service, age can be derived from that profile.

The pragmatic 2026 architecture: - Lower-friction default: age self-declaration at signup with attestation. - Triggered verification: behavioural / contextual signals trigger explicit age verification before continuing. - Document or biometric verification for known-high-risk contexts (gaming, gambling-adjacent, certain financial services). - Account linkage where the user has a verified profile through an Aadhaar-tied service.

Reasoning about the architecture — a 2026 design pattern

A 2026-mature implementation for processing minors' data follows this design pattern:

Pre-account creation flow:

Initial age gate at the start of any data-collection journey. Self-declaration acceptable.
If the user declares as adult: standard adult flow.
If the user declares as minor (under 18): - Pause data collection. - Trigger parental verification flow. - Notify the user that parental consent is required.
Parental verification flow: - Collect the parent's contact information (email, phone) from the child. - Reach out to the parent through a separate channel (email + SMS). - Verify the parent's identity through one of the verification methods. - Capture the parent's consent in the verifiable manner.
Account activation: - Account becomes active only after parental verification + consent completes. - Consent record logged with timestamps, verification method, parent identity (or tokenised reference).
Account configuration for minor user: - Behavioural analytics suppressed. - Targeted advertising disabled. - Cross-context tracking disabled. - Recommendation engines configured for context-only (not profile-based) for the minor user.

Ongoing operation: - Parental consent withdrawal flow available with operational symmetry to consent capture. - Periodic refresh of parental consent (recommended annually). - Age transition handling: when the user reaches 18, transition to adult flow with adult notice and adult consent capture.

Edge cases: - Orphans / children without identifiable guardian: handle through legal guardian verification or institutional consent (where lawful guardianship is established). - Parents without digital identity: offline / phone-based verification with documented procedure. - Disputed guardianship: legal escalation; suspended processing. - Children claiming to be 18: false declaration discovered later; treatment per the DPDPA reasonable-effort standard.

Sectoral applications

The Section 9 framework applies broadly but takes specific shape across sectors:

Social media platforms: the highest-impact sector. Verification of millions of new minor accounts annually. Section 9(3) prohibition on tracking + targeted advertising materially affects the platform's monetisation model for the minor user base. Some platforms have introduced "teen accounts" with default Section 9-compliant settings as a structural response.

Gaming platforms: gameplay tracking, in-game purchase decisions, social features for minors all touch Section 9. The Section 9(2) well-being standard creates exposure around addictive design, predatory monetisation. Section 9(3) prohibits in-game ads targeted to minor profiles.

EdTech: educational platforms have specific carve-outs under Schedule 4 / Rule 10 for educational purposes — but the exemption is narrow. Marketing of additional courses, behavioural analytics for engagement, cross-platform tracking remain in scope of Section 9.

Financial services with minor accounts: junior savings accounts, prepaid cards for minors, student loans, etc. Customer data collection requires parental verification; sectoral RBI rules layer on top.

Healthcare: limited exemption under Schedule 4 for treatment purposes; broader processing outside treatment (analytics, research, marketing) remains in scope.

E-commerce: customer accounts of minors are common (gifts, hobbies, family device accounts). The customer experience needs minor-specific treatment.

Content platforms (streaming, music, video): subscriber profiles, recommendation engines, behavioural-pattern-driven content delivery all touch Section 9 for minor users.

Common implementation failures observed in 2024–26

Five recurring patterns:

1. Age verification limited to self-declaration with no friction beyond. The user declares as 18, the system trusts; the "reason to suspect" standard is interpreted as never satisfied. SEBI / DPBI / consumer protection bodies are starting to push back where the design is obviously inviting false declaration.

2. Parental consent collected from email typed by the child. The child types the parent's email; the consent flow goes to that email. The parent verification is the email-receipt confirmation. This is not verification in the DPDPA sense.

3. Section 9(3) prohibitions ignored even when consent collected. Parental consent treated as unlocking all processing including behavioural monitoring and targeted ads. Section 9(3) is absolute; consent does not unlock it.

4. Schedule 4 exemption mis-applied. Healthcare providers claim broad Section 9 exemption; the exemption is purpose-bound to treatment. Marketing, research, secondary processing remain in scope.

5. Age transition not handled. Minor user turns 18; the system doesn't transition to adult flow; behavioural analytics remain suppressed beyond the minor period; or worse, adult features activate without adult consent capture.

Two further patterns:

6. Children of illiterate or low-digital-literacy parents. Operational reality in India means many parents cannot complete digital verification flows. The blanket digital-verification approach excludes legitimate users; the design needs offline / phone-based alternatives.

7. Disabled users with lawful guardians. Section 9 applies equally to persons with disabilities who have lawful guardians. Implementation often forgets this category, focusing entirely on minor users.

How ControlForge supports this

Relevant clusters: - cl-children-data-protection — children-specific data protection. - cl-age-verification — age verification mechanisms. - cl-consent-management — operational consent capture for parental verification. - cl-data-subject-rights — rights mechanisms applicable to children + guardians. - cl-notice-and-transparency — child-appropriate notice content. - cl-impact-assessment — child-well-being impact assessment.

The synthesis surfaces the strictest-clause across DPDPA Section 9 + GDPR Article 8 + COPPA + UK Age Appropriate Design Code + emerging APAC children's privacy. For multi-jurisdiction organisations, the synthesis allows a single child-data architecture to satisfy overlapping obligations, with India's 18-year threshold being the operational baseline.

A 90-day children's data compliance uplift

For consumer-facing organisations with minor user bases:

Days 1–30: Inventory and impact assessment. - Identify processing activities involving minor users. - Inventory current age-verification approach. - Inventory current parental consent approach (if any). - Conduct a child-well-being impact assessment per Section 9(2). - Identify Section 9(3) exposures (behavioural monitoring, targeted advertising).

Days 31–60: Architecture remediation. - Implement age-verification gate at all data-collection points. - Build / refresh the parental verification flow. - Configure Section 9(3) suppression (behavioural analytics, targeted ads, cross-context tracking) for minor users. - Build the consent withdrawal flow with operational symmetry.

Days 61–90: Operationalisation and inspection-readiness. - Document the architecture and the design choices. - Brief Board / management on the children's data posture. - Internal audit review of the implementation. - External counsel review. - Continuous improvement cadence.

A worked example — an EdTech platform

An EdTech platform serving school students arrives at the children's data compliance posture:

Profile: 2 million registered students aged 8–17 across India; teachers and parents also have accounts; the platform offers educational content, assessments, and peer interaction features.

Schedule 4 / Rule 10 exemption analysis: the EdTech is an educational provider; the Schedule 4 framework anticipates exemption from Section 9(1) verifiable parental consent for educational purposes specifically. However: - The exemption is narrow and purpose-bound. - Marketing of additional services to students or parents is outside the educational purpose. - Behavioural analytics for engagement / churn is outside the educational purpose. - Peer interaction features creating social-platform dynamics are arguably outside the educational purpose.

Implementation architecture chosen: - Account creation with age self-declaration at start. - For under-18 declarations: parental verification flow with Aadhaar-based attestation via DigiLocker. - Core educational activity (assigned coursework, assessments, teacher-led interactions) under the Schedule 4 educational-purpose exemption. - Behavioural analytics suppressed for under-18 user accounts. - Targeted advertising disabled for under-18 user accounts. Even on the parent-facing pages, behavioural targeting based on the child's data is disabled. - Peer interaction features: limited to teacher-moderated interactions; open social features disabled for under-18s. - Account transition at 18 with adult notice and consent capture.

Child-well-being impact assessment documented: - Risk of academic stress from continuous-assessment patterns mitigated via session-time limits. - Risk of social comparison from rankings mitigated by configurable visibility (default off for under-18). - Risk of inappropriate peer contact mitigated by teacher-moderation requirement.

Ongoing posture: - Quarterly review of the children's data programme at the Board / Risk Committee. - Periodic re-validation of parental consent (annually). - Compliance with future DPBI guidance on Section 9(2) "detrimental effect" standard.

The EdTech's specific learnings during implementation: (a) Aadhaar-based parental verification produced ~25% drop-off in account creation in low-digital-literacy regions; an alternative paper-based + phone-verification flow was needed; (b) the Schedule 4 exemption boundary required active design discipline — the team's instinct to add behavioural-analytics-driven recommendations was rejected because it crosses the boundary; (c) teacher-account access to student data required additional access-control review under Section 9 considerations. These patterns are common in EdTech and content platforms serving minors.

Cross-references

Section 9 interacts with:

General DPDPA obligations under Sections 5–8 — apply equally for children's data.
DPDPA Section 10 SDF obligations — large processors of children's data may be designated SDFs with enhanced obligations.
IT (Intermediary Guidelines) Amendment Rules 2026 — additional content moderation and child safety obligations for intermediaries.
POCSO Act 2012 (Protection of Children from Sexual Offences) — separate criminal regime, intersects with content platforms.
Sectoral consumer-protection — RBI / SEBI / IRDAI consumer-protection frameworks layer additional obligations for minor financial-services customers.
EU AI Act + IT Rules 2026 SGI — for AI-generated content directed at or involving minors.

DPDPA children's data and verifiable parental consent — a 2026 practitioner reference