Children now access digital services across education, gaming, entertainment, healthcare, social interaction and commerce. For a business operating such a service, the immediate compliance question is often framed simply: has parental consent been obtained? Under India’s Digital Personal Data Protection framework, however, consent is only part of the inquiry. The more fundamental question is whether the business can establish that the individual providing consent is an adult who is identifiable and is acting as the child’s parent or lawful guardian.[1]
The Digital Personal Data Protection Act, 2023 (“DPDP Act”) treats every individual below eighteen years as a “child”.[2] Before processing a child’s personal data, a Data Fiduciary must obtain the verifiable consent of the child’s parent; this includes the consent of a lawful guardian where applicable.[3] The Digital Personal Data Protection Rules, 2025 (“DPDP Rules”) give this requirement operational content by requiring appropriate technical and organisational measures, together with due diligence regarding the age and identity of the individual presenting herself as the parent.[4]
This changes the design problem for digital businesses. A parental declaration, a check-box or an OTP may record an affirmative action, but may not, by itself, demonstrate the “verifiable consent” contemplated by the framework. The relevant compliance exercise is therefore a “parental-verification flow”: a structured process through which a business identifies a child-data interaction, verifies the adult seeking to provide consent, delivers the relevant notice, and only then enables the proposed processing.
The framework is not presently operative in full. Rule 10 is scheduled to come into force eighteen months after publication of the DPDP Rules, i.e., on 13 May 2027.[5] Businesses nevertheless have a limited window to reassess onboarding, analytics and advertising practices before child-data compliance becomes a live product-governance issue.
The Legal Baseline: Children, Consent and Section 9
1. Consumer Protection Layer
The framework adopts a bright-line standard: an individual who has not completed eighteen years of age is treated as a child. This removes the need for a business to assess a user’s maturity, digital literacy or ability to understand data practices on a case-by-case basis. Once the child threshold is engaged, the additional safeguards under Section 9 apply.
2. Consent Remains Purpose-Bound
The child-data regime operates within the wider consent framework under the DPDP Act. Consent must be free, specific, informed, unconditional and unambiguous, and must be expressed through clear affirmative action. It must also be limited to personal data necessary for the specified purpose.[6] The consent request must be presented in clear and plain language, with the prescribed language-access options and relevant contact details.
For child-data processing, however, the relevant affirmative action must come through the parental-verification flow. The business must therefore be able to demonstrate not only that consent was recorded, but also that the consent was obtained from the appropriate adult before the proposed processing begins.
3. Section 9: Consent Is Only One Safeguard
Section 9 does not treat parental consent as an unrestricted permission. A Data Fiduciary must not undertake processing likely to cause any detrimental effect on a child’s well-being. It must also not track or behaviourally monitor children, or direct targeted advertising at them, except to the limited extent permitted through the prescribed exemptions.
Accordingly, the legal inquiry has two dimensions. First, has valid verifiable parental consent been obtained for the specified purpose? Second, is the proposed processing itself permissible under the child-protection restrictions? A compliant consent flow cannot cure a processing activity that is independently prohibited by Section 9.
What “Verifiable” Really Means
“Verifiable consent” is not a separate species of consent obtained merely by adding a parental declaration to an ordinary sign-up flow. The DPDP Rules define it by reference to the prescribed verification framework; in effect, consent becomes verifiable only when the Data Fiduciary can demonstrate that the individual providing it has been subject to the required age-and-identity diligence.[7]
This creates two related, but distinct, compliance questions. The first is whether consent has been validly obtained for the stated processing purpose. The second is whether the individual presenting herself as the parent is an identifiable adult. The parental-verification flow must address both.
The Rules do not mandate one uniform technology or identity document. Instead, they permit the Data Fiduciary to rely either on reliable identity-and-age details already available with it, or on identity-and-age details voluntarily furnished by the individual, including through a virtual token issued by an authorised entity.[8] The focus is therefore on the reliability of the verification pathway, rather than on a prescribed interface or a single government-issued credential.
Importantly, the Rules require due diligence in relation to the adult identifying herself as the parent. They do not lay down a separate exhaustive documentary test for proving the parent-child relationship.[9] Businesses should nevertheless consider proportionate escalation measures for disputed, unusual or higher-risk cases, including where guardianship is asserted or account access is contested.
A declaration, OTP or confirmation email may support the consent record. Standing alone, however, it is unlikely to discharge the verification exercise contemplated by the Rules.
Rule 10’s Two Routes to Verifiable Parental Consent
Rule 10 of the DPDP Rules adopts a deliberately technology-neutral approach. It does not prescribe a particular identity document, authentication provider or interface. Instead, it permits the parental-verification flow to be built around two routes: first, the use of reliable identity-and-age details already available with the data fiduciary; and second, the use of identity-and-age details voluntarily made available by the individual who identifies herself as the parent.
1. Route One: Reliable Details Already Available with the Data Fiduciary
The first route is relevant where the individual identifying herself as the parent is already known to the data fiduciary through an existing user relationship. In such cases, the Data Fiduciary may rely on identity-and-age details already held by it, provided that those details are reliable and sufficient to confirm that the individual is an identifiable adult.
The Rule 10 illustrations apply this route both where a child initiates the account-creation process and names a parent, and where the parent directly initiates the child’s account. In each case, the relevant step is not merely to locate an existing profile. The data fiduciary must check that it holds reliable details of the parent’s identity and age, and that the parent is an identifiable adult.[10]
This distinction is material. A pre-existing account based only on an email address, mobile number or self-declared date of birth may not necessarily provide the level of reliability expected under the framework. Businesses will therefore need to assess whether their existing customer-verification, KYC or account-onboarding processes can support this route, rather than assume that every registered user qualifies as a verified parent.
2. Route Two: Details Voluntarily Provided by the Parent
The second route is intended for cases where the parent is not an existing verified user, or where the data fiduciary cannot reasonably rely on information already held by it. Here, the individual may voluntarily provide identity-and-age details that enable the data fiduciary to check that she is an identifiable adult.
The illustrations indicate that such details may be sourced from an entity entrusted by law, the Central Government or a State Government with issuing or maintaining those details.[11] This route gives businesses flexibility to create an external verification step without requiring every parent to establish a full customer relationship with the platform.
The verification process should nevertheless remain proportionate. The objective is to establish the adult identity and age of the individual providing consent, not to collect a broader set of personal data than necessary for that purpose. A data fiduciary should therefore design the flow to obtain only the minimum information required, apply suitable security safeguards, and avoid retaining supporting identity material longer than necessary.
3. Virtual Tokens and Digital Locker-Enabled Verification
Rule 10 of the DPDP Rules also permits the use of a virtual token mapped to identity-and-age details, where the token is issued by an authorised entity. An authorised entity includes an entity entrusted by law or Government with issuing such details, as well as a person appointed or permitted by that entity. The framework further recognises details or tokens made available and verified through a Digital Locker Service Provider.[12]
This route is significant because it allows a data fiduciary to rely on a verification outcome or tokenised credential rather than collect and retain raw identity documents. Properly implemented, this may better reconcile the need for verifiable consent with data-minimisation principles.
4. A Practical Design Principle
The four illustrations lead to a simple operational rule: where reliable adult identity-and-age details are already available, the data fiduciary should validate those records; where they are not available, it should enable the parent to provide verified details or a recognised virtual token. The choice of route may differ by product, user journey and risk profile, but the compliance outcome must remain the same—an auditable basis for treating the consenting individual as an identifiable adult.
The Correct Sequence: Age Triage, Verification and Consent
1. A Limited Pre-Consent Step
The parental-verification flow need not begin only after a business has conclusively determined that an individual is a child. A Data Fiduciary may need to process limited information at the outset to assess whether the child-data framework is engaged and, where necessary, to undertake the relevant verification exercise. The Fourth Schedule expressly recognises this operational reality by permitting processing, to the extent necessary, for confirming that a Data Principal is not a child and for observing the due diligence contemplated under Rule 10.
This is a narrow facilitative carve-out, not a general authority to activate a child account, collect broad usage information or begin delivering the substantive service before the requisite safeguards are completed.
2. The Recommended Onboarding Sequence
A legally coherent flow should ordinarily proceed in the following order:
a. Age triage: obtain only the information reasonably required to identify whether the user may be a child;
b. Child-data determination: where the child threshold is triggered, pause the ordinary onboarding journey;
c. Parent contact: enable the parent to identify herself through an appropriate channel;
d. Adult verification: apply the relevant verification route based on whether reliable identity-and-age details are already available;
e. Consent request: provide the relevant notice and obtain the parent’s affirmative consent for the specified purpose; and
f. Service activation: process the child’s personal data only within the scope of that consent and the applicable legal restrictions
3. What the Flow Should Not Become
Businesses should avoid creating the child account first and regularising consent later. They should also avoid collecting extensive identity material merely because a user may be a child. The verification step should be necessary, proportionate and clearly segregated from the wider data collection associated with the service.
Parental Consent Has Hard Limit
The parental-verification flow is an essential gateway to lawful child-data processing, but it is not a general permission slip. Even where consent has been validly obtained, the Data Fiduciary must independently assess whether the intended processing is permissible in light of the child-protection restrictions under the framework.
Accordingly, a business cannot rely on parental consent to justify processing that is likely to cause a detrimental effect on a child’s well-being. The same principle applies to tracking, behavioural monitoring and targeted advertising directed at children. These restrictions require businesses to look beyond the initial onboarding flow and examine how the service operates after the account has been activated.
This has direct implications for product, analytics and advertising design. A child-facing or child-accessible service should carefully review, among other things:
a. recommendation and content-personalisation systems;
b. engagement, retention and gamification features;
c. third-party analytics software development kits;
d. advertising pixels, audience-segmentation tools and ad-tech integrations; and
e. profiling tools that infer interests, behaviour or likely preferences from a child’s activity
The legal question is therefore not limited to whether a parent has agreed to the collection of data. It is whether the proposed use of that data remains consistent with the child-protection boundaries built into the framework.
Certain processing activities may fall within the targeted exemptions under the Fourth Schedule, including specified safety, healthcare, educational and content-screening purposes. These exemptions should be treated as purpose-specific and conditional, rather than as a broader relaxation for platforms that serve children.
Exemptions: Targeted, Conditional and Not a Safe Harbour
1. The Scope of the Exemptions
The exemptions under the framework are intentionally narrow. Rule 12 disapplies only the requirements relating to verifiable parental consent and the prohibition on tracking, behavioural monitoring and targeted advertising, and only for the specified classes of data fiduciaries or purposes set out in the Fourth Schedule.[13] They do not disapply the wider prohibition on processing likely to cause a detrimental effect on a child’s well-being.
Accordingly, an exemption does not create a general child-data safe harbour. It permits a defined processing activity only where the relevant class, purpose and conditions are satisfied.
2. Class-Based and Purpose-Based Relief
Part A of the Fourth Schedule provides limited relief for certain regulated or child-focused contexts. These include healthcare establishments and professionals providing health services necessary for the protection of a child’s health; educational institutions undertaking tracking or behavioural monitoring for educational activities or child safety; and childcare or transport providers processing limited data for safety-related purposes.
Part B is purpose-specific. It covers, among other matters, processing necessary for child-related statutory functions, provision of public benefits, creation of an email-only account, real-time location tracking for safety or security, preventing a child’s access to harmful information or services, and undertaking age confirmation or the parental-verification flow. In every instance, processing must remain limited to what is necessary for the relevant purpose.
3. “Verifiably Safe” Processing Is Not Yet a General Exemption
The DPDP Act also permits the Central Government to notify a Data Fiduciary or class of Data Fiduciaries as exempt from specified child-data obligations where its processing is “verifiably safe”.[14] This is a notification-based mechanism, not an exemption that businesses may self-assess or invoke merely because their service is child-friendly, educational or socially beneficial.
The practical position is therefore clear: exemptions must be interpreted narrowly, operationalised against their stated conditions, and supported by a documented assessment of necessity. A business should not treat its broader public-interest objective as a substitute for compliance.
Compliance Design: What Businesses Should Build Before May 2027
1. Build the Child-Data Journey into Product Design
Compliance should begin before a user reaches the consent screen. Businesses should map every point at which a child may access, register for or interact with their service, including guest journeys, shared-device access, referral flows and third-party sign-ins. This mapping should inform age-triage prompts, child-specific onboarding branches, parent-contact mechanisms and account-activation controls.
The parental-verification flow should be designed as a distinct stage, rather than embedded invisibly within a general sign-up process. It should also ensure that the child’s account cannot access processing features that exceed the stated purpose or applicable child-protection boundaries.
2. Maintain an Auditable Consent Record
A Data Fiduciary should be able to demonstrate how it reached the conclusion that consent was obtained from an identifiable adult. Its records should capture, at a minimum, the verification route used, the date and time of verification, the consent notice presented, the specified purpose, the affirmative action taken and any subsequent withdrawal or account-access request.
These records should be supported by clear internal ownership. Product, legal, compliance, engineering and customer-support teams should have defined responsibilities for exceptions, disputed parentage, claimed guardianship and account-recovery requests.
3. Review Analytics, Advertising and Vendor Architecture
The compliance exercise should extend beyond first-party product flows. Businesses should review whether analytics tools, software development kits, advertising pixels, recommendation engines and customer-engagement platforms collect or infer behavioural information from child accounts. Default settings should be configured to prevent prohibited tracking, behavioural monitoring and targeted advertising.
Contracts with processors and service providers should also require appropriate safeguards. In particular, vendors should be restricted from using child-data for their own analytics, profiling, product-improvement or advertising purposes unless such use is independently permitted.
4. Apply Data Minimisation Throughout
Verification should not become a reason to build an unnecessary identity repository. Businesses should collect only the information necessary for age triage, adult verification and the stated service purpose; restrict access to such information; and adopt defined retention and deletion controls.
The objective is not simply to create a compliant consent record. It is to build a service environment in which child-data processing remains limited, explainable and capable of withstanding regulatory scrutiny.
Conclusion
The forthcoming child-data framework under the DPDP regime is built on a simple but demanding proposition: where a service may process a child’s personal data, the business must be able to show more than a recorded parental click. It must identify the relevant child-data interaction, apply an appropriate parental-verification flow, obtain meaningful consent for a defined purpose, and ensure that the subsequent processing remains within the statutory limits.
Rule 10 of the DPDP Rules offers flexibility in how verification may be designed, but not in the outcome expected. Whether a data fiduciary relies on reliable details already available with it or on details voluntarily provided through an appropriate verification route, it must have an auditable basis for treating the consenting individual as an identifiable adult.
The larger compliance challenge, however, extends beyond onboarding. Product analytics, recommendation systems, advertising architecture, vendor arrangements and account-management processes must all be assessed against the child-protection boundaries under the framework.
Businesses that use the period before May 2027 to redesign these systems will be better placed to treat child-data compliance not as a late-stage consent exercise, but as a core element of responsible digital governance.
[1] Digital Personal Data Protection Act, 2023, s. 9(1); Digital Personal Data Protection Rules, 2025, r. 10(1)
[2] Digital Personal Data Protection Act, 2023, s. 2(f)
[3] Digital Personal Data Protection Act, 2023, s. 9(1) and Explanation
[4] Digital Personal Data Protection Rules, 2025, r. 10(1)
[5] Digital Personal Data Protection Rules, 2025, r. 1(4)
[6] Digital Personal Data Protection Act, 2023, s. 6(1)
[7] Digital Personal Data Protection Rules, 2025, r. 2(1)(d)
[8] Digital Personal Data Protection Rules, 2025, r. 10(1)(a)–(b)
[9] Digital Personal Data Protection Rules, 2025, r. 10 and Illustrations
[10] Digital Personal Data Protection Rules, 2025, r. 10, Illustration, Cases 1 and 3
[11] Digital Personal Data Protection Rules, 2025, r. 10, Illustration, Cases 2 and 4
[12] Digital Personal Data Protection Rules, 2025, r. 10(2)(b)–(c)
[13] Digital Personal Data Protection Rules, 2025, r. 12
[14] Digital Personal Data Protection Act, 2023, s. 9(5)