Section 9 of the DPDP Act sets out strict protections for children's personal data. Contraventions can attract penalties of up to Rs. 200 crore, while the Act's highest listed penalty, up to Rs. 250 crore, applies to certain security-safeguard failures.
If your product serves students, learners, or any user base that includes people under 18, Section 9 applies to you. Not just edtech companies. Gaming platforms, social media apps, content platforms, tutoring marketplaces, school management systems, ed-infra providers, and any product where minors create accounts or generate data.
The penalties for Section 9 violations reach Rs. 200 crore per contravention. That is not the maximum across the entire Act. That is the maximum for children's data specifically. The Act subjects children's data to additional statutory protections.
This guide covers the specific obligations, the engineering requirements, and the implementation failures we see most commonly across Indian edtech. The audit data behind those patterns is in The State of DPDP Compliance in India (2026).
What Section 9 actually says
Three provisions, each with significant engineering implications:
Section 9(1): Verifiable parental consent
Before processing any personal data of a child (defined as anyone under 18), the Data Fiduciary must obtain verifiable consent from the child's parent or lawful guardian.
Key words: verifiable. Not "a checkbox that says I am over 18." Not "an age gate that anyone can click through." Verifiable means you must have a reasonable mechanism to confirm that the person giving consent is actually the parent or guardian, and that the child is actually under 18.
Section 9(2): Prohibition on behavioral tracking and targeted advertising
No Data Fiduciary shall process children's personal data for the purpose of tracking or behavioral monitoring, or for targeted advertising directed at children.
Key words: shall not. As a baseline, consent does not make prohibited tracking or targeted advertising permissible. The final Rules, however, create limited, conditional exemptions from specified Section 9 obligations for certain classes of Data Fiduciaries and purposes. Do not assume an exemption applies without checking the Fourth Schedule and its conditions.
This means:
- No analytics that tracks individual child behavior (session recording, event tracking tied to user identity, behavioral segmentation)
- No retargeting pixels or ad SDKs that fire for accounts identified as belonging to minors
- No recommendation algorithms that personalize content based on a child's behavioral profile
- No A/B testing that segments children by behavior
Section 9(3): Exemptions
The final Rules now contain limited, conditional exemptions in Rule 12 and the Fourth Schedule. They apply only to specified classes of Data Fiduciaries or specified purposes, and only subject to the stated conditions. Edtech companies should not assume that a school or educational purpose automatically creates an exemption for the edtech provider.
The age problem: how do you know who is under 18?
Before you can comply with Section 9, you need to know which of your users are children. This is the first and hardest implementation challenge.
The wrong approaches
Self-declared age gate. "Are you over 18? [Yes] [No]." This is not verifiable. Anyone can click Yes. It provides no compliance defense.
Date of birth field with no verification. "Enter your date of birth: [field]." A 14-year-old enters a birth year of 2004 and passes. No verification means no compliance.
No age collection at all. If you don't ask and don't know, you are processing children's data without parental consent and without behavioral tracking restrictions. Ignorance is not a defense.
Many platforms still use the US COPPA threshold of 13 instead of DPDP's 18 — one of the recurring gaps in our 300+ startup audits. For the GDPR vs DPDP difference on age definition, see GDPR vs DPDP for Indian Companies.
The workable approaches
What the final Rules say. Rule 10 requires appropriate technical and organisational measures to obtain verifiable parental consent before processing a child's personal data, and reasonable due diligence to establish that the person identifying themselves as the parent is an adult. The Rules allow this to be established using reliable identity and age details already available to the Data Fiduciary, identity and age details voluntarily provided by the parent, or a virtual token linked to such details and issued by an authorised entity.
Engineering implication. Choose a verification flow that fits your product and risk profile, document why it is reliable, minimise the identity data you retain, and avoid treating a generic OTP or a nominal payment as automatically sufficient legal verification. Where a third-party identity or age service is used, map its role and data flow explicitly.
Operational default. If your product cannot reliably determine whether an account belongs to a child, design conservative controls around child-facing features and avoid relying on a simple self-declared age gate as your only safeguard.
Verifiable parental consent: implementation
Once you identify an account as belonging to a minor, you need verifiable parental consent before processing their data. Here is the implementation:
Step 1: Parent identification
The minor provides a parent or guardian's contact information (email, phone number). This is the entry point for the consent flow.
Step 2: Parent verification
Verify that the contact belongs to an actual adult, and ideally to the actual parent or guardian:
Do not treat OTP alone as proof of parenthood. An OTP can establish access to a contact channel, but the final Rules focus on reliable identity and age details or authorised virtual tokens.
Use the verification mechanisms available under Rule 10. Depending on the product, this may involve reliable details already held by the Data Fiduciary, voluntarily provided identity and age details, or an authorised virtual token. Minimise the identity information you retain after the verification step.
Choose the mechanism based on the actual risk and the data you process, and document the verification decision. Do not market Aadhaar, a credit-card check, or a school document as a universally required or automatically sufficient DPDP mechanism.
Step 3: Informed consent capture
Present the parent with a clear, specific consent notice:
- What personal data of the child will be collected
- For what specific purposes
- How long it will be retained
- Who will process it (including third-party processors)
- What rights the parent has (access, correction, erasure on behalf of the child)
- That behavioral tracking and targeted advertising are not permitted regardless of consent
- How to withdraw consent
The consent request must be presented in clear and plain language, with an option to access it in English or any language specified in the Eighth Schedule (Section 6(3)).
Step 4: Consent recording
Record the parent's consent in your consent ledger with:
- Child's account ID
- Parent's verified identity
- Timestamp of consent
- Notice version shown
- Language of notice
- Verification method used
- Specific purposes consented to
Step 5: Consent renewal
Children age. A 16-year-old becomes 18 in two years. At that point, Section 9 restrictions no longer apply, but you should offer the now-adult user the opportunity to provide their own consent, review data collected during their minority, and make their own decisions about data processing.
Build an age-up workflow: on the user's 18th birthday (based on verified DOB), prompt them to review and confirm their own consent preferences.
Behavioral tracking prohibition: implementation
Section 9(2) prohibits tracking and behavioral monitoring of children. This requires engineering controls, not just policy statements.
What must be disabled for child accounts
Analytics: User-level event tracking (Mixpanel, PostHog, Amplitude) must not fire for child accounts. Aggregate, non-identifiable analytics (total page views, feature usage counts without user attribution) may be permissible.
Session recording: Hotjar, FullStory, LogRocket must not record sessions for child accounts. Implement a feature flag that disables recording SDKs when the logged-in user is identified as a minor.
Recommendation engines: Any system that personalizes content based on individual behavioral history must serve a default, non-personalized experience to child accounts.
A/B testing: Behavioral segmentation of children is prohibited. If your A/B testing framework segments by user behavior, child accounts must be excluded or placed in a neutral cohort.
Retargeting and advertising: Meta Pixel, Google Ads tag, any ad network SDK must not fire for child accounts. This includes suppressing the user from custom audiences and remarketing lists.
Third-party SDKs: Audit every third-party SDK in your product. Any SDK that collects behavioral data must be disabled for child accounts. This includes "free" SDKs that monetize through behavioral data collection.
Implementation approach: feature flags
The cleanest implementation is a server-side feature flag tied to the user's minor status:
When user.is_minor is true:
- Disable all non-essential analytics tracking
- Disable session recording
- Disable recommendation personalization
- Disable retargeting pixels
- Disable A/B testing behavioral segmentation
- Serve age-appropriate content only
When user.is_minor transitions to false (user turns 18):
- Prompt user for their own consent
- Enable features based on their consent choices
This approach centralizes the control and makes compliance auditable: you can demonstrate that the flag is checked at every relevant point in your product.
The B2B edtech model: school as intermediary
Many Indian edtech companies sell to schools, not directly to students. In this model:
In a B2B model, classify the roles from the actual arrangement. If the school determines the purposes and means and you process student data on its behalf, the school may be the Data Fiduciary and the edtech provider a Data Processor. If the provider determines its own purposes or means for some processing, it may have separate Data Fiduciary responsibilities for that activity.
For school deployments:
- Determine which party is responsible for the relevant child-data processing and consent/verification workflow
- Do not assume that a school's exemption automatically transfers to an edtech provider
- Define in the DPA who handles parental/guardian verification where it is required
- Define permitted purposes, processor instructions, deletion/return obligations, and incident notification
- Implement the applicable Section 9 restrictions and any Rule 12/ Fourth Schedule conditions that apply to the actual processing
- Support the school with Data Principal rights and evidence where required
The DPA with the school should include:
- Explicit prohibition on using student data for your own purposes (model training, product analytics, marketing)
- Commitment that behavioral tracking and targeted advertising are disabled for all student accounts
- Breach notification SLA (24 to 48 hours to the school)
- Data deletion upon contract termination
- Sub-processor list and consent mechanism
For the processor-mapping workflow behind school DPAs, see How to Map Data Flows to Third-Party Processors Under DPDP.
Data retention for children's data
Section 8(7) requires proactive erasure when the purpose is fulfilled. For edtech, this creates specific scenarios:
Student graduates or leaves the school. Reassess the purpose and applicable retention requirements. If the data is no longer needed for the relevant purpose and no legal retention requirement applies, trigger the appropriate deletion or return workflow.
Subscription expires. Reassess the purpose and contractual/legal retention requirements. Do not assume that expiry automatically creates an immediate statutory deletion deadline.
Child turns 18. They are no longer a child under the DPDP definition. Re-classify the account and assess the processing under the ordinary DPDP framework, including whether fresh consent or another lawful basis is required for future processing.
Build automated retention policies for each scenario. Manual processes will miss edge cases at scale.
The eight edtech compliance failures
Failure 1: Age gate theater. A "click if you're over 18" button that no minor has ever been stopped by.
Failure 2: Parental consent as a checkbox. "I confirm I am the parent" with no verification. This is not verifiable consent.
Failure 3: Behavioral tracking running on all accounts. Mixpanel, Hotjar, and Google Analytics firing for every user, including minors. Each event is a Section 9(2) violation.
Failure 4: Ad SDKs in the product. Meta Pixel, Google Ads, or third-party ad SDKs that fire for child accounts. Each impression is a Section 9(2) violation.
Failure 5: Using student data for model training. Your AI tutoring product uses student interaction data to improve the model. If this is not a purpose the school (or parent) consented to, it is unauthorized processing of children's data.
Failure 6: No age-up workflow. A student who signed up at 15 turns 18. Their account is still classified as a minor. No prompt to re-consent. Section 9 restrictions continue unnecessarily, and the user has no opportunity to make their own choices.
Failure 7: School DPA missing Section 9 provisions. Your DPA with the school does not mention children's data, behavioral tracking prohibitions, or parental consent obligations. The school assumed you handle it. You assumed they handle it. Nobody handles it.
Failure 8: Indefinite retention of student data. Students from 2019 who no longer use the platform still have full data in your systems. No retention policy, no cleanup, no proactive erasure.
The self-test for edtech companies
- What percentage of your user base is under 18?
- How do you verify age? Is the verification method defensible under "verifiable" standard?
- For accounts identified as minors, do you have verifiable parental consent on file?
- Are analytics, session recording, and ad SDKs disabled for minor accounts?
- If a school's contract with you ends, what happens to the student data within 30 days?
- When a student turns 18, does your system prompt them for their own consent?
If any answer is "we don't know" or "not currently," those are your Section 9 priorities.
Where Privra fits
Privra runs DPDP compliance programs specifically designed for edtech and children's data processors. Our system handles age verification workflows, parental consent capture and audit trails, behavioral tracking suppression for minor accounts, school DPA management, and retention enforcement for student data.
Section 9 carries penalties of up to Rs. 200 crore for specified contraventions. The implementation challenge is also highly technical: age classification, parental verification, purpose controls, tracking suppression, retention, and evidence all have to work together. We help you build the infrastructure that keeps those controls operational.
Talk to us about children's data compliance.
This article has been reviewed against the notified Digital Personal Data Protection Rules, 2025 and the Digital Personal Data Protection Act, 2023. Legal requirements and Privra's recommended engineering practices are intentionally distinguished.