Edtech is one of the few sectors where the DPDP Act's children's provisions are not a peripheral risk -they are the primary compliance surface. The moment a platform onboards a single user under eighteen, Section 9 stops being a footnote and becomes the section that shapes product decisions: how sign-up works, what a recommendation engine is allowed to do, and who is legally accountable when something goes wrong.
This piece works through what Section 9 actually requires, how to build parental consent that holds up under scrutiny, why targeted advertising and behavioural tracking are off the table for child users regardless of consent, how responsibility splits between a school and the platform it licenses, and what a realistic compliance checklist looks like for a product team shipping features every sprint.
Section 9 - The Children's Data Rules
Section 9 of the DPDP Act applies whenever a Data Fiduciary processes the personal data of a child -anyone under eighteen. It does two separate things, and it is worth keeping them separate in your compliance thinking. First, it requires verifiable consent from a parent or lawful guardian before that processing can lawfully begin. Second, independent of consent, it prohibits processing that could cause any detrimental effect on the wellbeing of a child, and it separately bars tracking, behavioural monitoring, and targeted advertising directed at children.
That second point trips up a lot of edtech teams, because it is easy to assume that once a parent has consented, the platform has broad latitude to build on that consent -collecting usage data, running analytics, personalising the experience however it likes. Section 9 does not work that way. Consent unlocks processing for the purposes disclosed; it does not unlock tracking or advertising aimed at the child, because those are barred outright rather than gated behind consent.
For a deeper walkthrough of how Section 9 applies across sectors, not just edtech, see our dedicated piece on children's data under DPDP. The rest of this article focuses on what that means specifically for a platform built around students.
DPDP does not distinguish a sixteen-year-old finishing school from a six-year-old in primary class. If a user is under eighteen, Section 9 applies to their account in full, and platform design should treat "the user might be a minor" as the default assumption for any sign-up flow that is not explicitly adult-only.
Age Assurance & Parental Consent
Verifiable parental consent is the hardest operational problem in this entire piece, because the DPDP Act sets the requirement without prescribing a single approved mechanism. Until the Rules provide more granular guidance, the practical approach is to build a consent flow that can withstand an audit: it identifies who the consenting adult is, confirms their relationship to the child, records exactly what processing they agreed to, timestamps the event, and makes withdrawal at least as easy as the original consent.
Age-gating comes first, because consent only matters once you know a user is a child. Self-declared date of birth at sign-up is the simplest pattern and the easiest to implement, but on its own it is weak -nothing stops a student from entering an adult birth year to skip the parental flow. Stronger patterns pair the declared age with a verification step: routing the consent capture through a parent's own account rather than the child's, requiring a parent email or phone number that receives a separate consent confirmation, or -where the platform sells into schools rather than directly to families -relying on the enrollment process the institution already runs, since the school has typically already collected guardian information as part of admission.
That institutional route is worth building deliberately if a meaningful share of your users come through school licences rather than direct sign-up, because it turns one hard consent problem into a much smaller one: the school captures guardian consent once as part of its own onboarding, and your platform inherits a documented, auditable trail instead of running thousands of individual parent verifications on its own. For the mechanics of building consent capture into a web or app sign-up flow more broadly, see our consent mechanism guide.
Whatever pattern you choose, log it. A parental consent flow that is not recorded with a timestamp, the specific purposes covered, and a way to prove it happened is not meaningfully different from having no consent flow at all if the Data Protection Board of India ever asks you to demonstrate compliance.
The Ban on Tracking & Targeted Ads
This is the part of Section 9 that has nothing to do with consent. Even where a parent has agreed to let their child use the platform, the DPDP Act separately prohibits tracking, behavioural monitoring, and advertising targeted at children. No level of parental sign-off reopens that door -it is a hard boundary on what the platform is allowed to do with a child's activity data, not a permission that can be negotiated away.
For a typical edtech product, this reaches further than the obvious case of avoiding ad networks aimed at kids. Any feature that profiles a child's behaviour across sessions -what they click, how long they linger, what content keeps them engaged -in order to target advertising or build a marketing profile falls inside the prohibition. Third-party ad SDKs, cross-app tracking pixels, and marketing analytics tools that build behavioural profiles for monetisation purposes should be disabled entirely for accounts flagged as belonging to a child.
Recommendation engines sit in genuinely more ambiguous territory, and it is worth being precise about why. A system that adapts a learning path based on a student's quiz scores, time-on-task for a specific skill, or which practice questions they got wrong is working from academic performance signals -the kind of data an adaptive-learning product exists to collect and act on. That is a materially different thing from a behavioural profile assembled to decide what to advertise or what unrelated content to surface for engagement. The Act's core concern is tracking and targeting a child commercially, not a platform using performance data to teach better. Until the Rules draw a brighter line, the defensible position is to keep any personalisation strictly tied to academic signals, document that boundary internally, and treat anything that starts to resemble engagement-maximisation or ad-style targeting as off-limits for child accounts.
School as Fiduciary, Platform as Processor
Edtech companies typically sell through one of two paths, and the DPDP obligations land differently depending on which one applies to a given customer relationship.
Institutional deployment -school licenses the platform
When a school or educational institution licenses your platform for its students and controls how their data is used -what gets collected, what it is used for, how long it is kept -the school is generally the Data Fiduciary, and your platform acts as a Data Processor carrying out instructions on the school's behalf. That does not remove your obligations; it changes their shape. Your contract with the school needs to specify security standards, breach notification timelines back to the school, and confirmation that consent has been properly captured at the institutional level. For the full breakdown of how fiduciary and processor obligations differ, see our piece on Data Fiduciaries and Processors.
Direct-to-student -family signs up without a school in between
When students or parents sign up for your product directly -a consumer learning app, a tutoring platform, an exam-prep tool bought by a family rather than issued by a school -your platform determines the purpose and means of processing on its own. That makes you the Data Fiduciary, and every Section 9 obligation, including verifiable parental consent, sits with you directly. There is no institutional intermediary to lean on for consent capture, which is why direct-to-consumer edtech products typically need the most robust in-app consent and age-assurance flows in the sector.
Student Data, Access & Deletion
What an edtech platform typically collects goes well beyond a name and an email: enrollment details, academic performance and assessment results, attendance or session logs, sometimes device and location data, and increasingly biometric or proctoring data for assessment integrity. Every category deserves a purpose-limitation check -collect what the learning product actually needs, and be able to explain why each field exists.
Once that data exists, the DPDP Act's data principal rights apply, and for a child, a parent or lawful guardian exercises them on the child's behalf. The Act sets out eight rights for data principals in total, covering access to processing information, correction and completion of inaccurate data, erasure once the purpose is served, grievance redressal, the right to nominate someone to exercise these rights if the principal is unable to, and related protections. In practice for an edtech platform, the two that generate the most operational work are access -a parent asking what data you hold on their child -and erasure, particularly when a student leaves the school, graduates, or a family simply stops using the product.
Build a defined deletion path for that last scenario before you need it under pressure. When a student's relationship with the platform ends, decide upfront how long academic records are retained (schools and exam boards often have their own retention expectations that run alongside DPDP), what gets deleted immediately versus archived, and how a parent or the school itself can trigger a deletion request and get confirmation it was carried out. For the mechanics of handling these requests end to end, see our guide on erasure and deletion requests.
Treat "the student graduated" the same way you would treat "the customer churned" in any other product -a known, tested offboarding path, not a one-off support ticket handled manually the first time it happens.
Compliance Checklist
Pulling the article together into something a product and legal team can actually work from:
| Area | What To Have In Place | Why It Matters |
|---|---|---|
| Age assurance | A sign-up flow that identifies under-18 users before processing begins | Section 9 applies from first contact, not after the fact |
| Parental consent | Verifiable, timestamped, purpose-specific consent capture with an easy withdrawal path | Your audit trail if the Board asks you to demonstrate compliance |
| Institutional consent | Confirmation that schools capture guardian consent during enrollment for licensed deployments | Institutional route reduces per-family verification load |
| Ad & tracking SDKs | Disabled entirely for child accounts, including third-party analytics that build behavioural profiles | The tracking and targeted-advertising bar applies regardless of consent |
| Recommendation logic | Personalisation limited to academic performance signals, documented internally | Keeps adaptive learning distinct from prohibited behavioural targeting |
| Data inventory | A record of every data category collected from student accounts and its purpose | Needed for both access requests and purpose-limitation review |
| Deletion path | A tested offboarding flow triggered when a student leaves or graduates | Erasure rights apply, and "build it later" is not a plan |
| Fiduciary mapping | Clarity, per customer type, on whether the school or the platform is the Data Fiduciary | Determines who owns which compliance obligation in each contract |
None of these are one-time projects. Age assurance and consent capture live in the sign-up flow your team ships changes to every quarter; the checklist above is a baseline to re-run whenever the product changes meaningfully, not a box to tick once and file away.
Edtech is not exempt from the parts of DPDP that other sectors find optional to think about early. Section 9 is not a compliance afterthought for a platform built around students -it is close to the whole compliance picture. Get age assurance, parental consent, the tracking-and-ads boundary, and the fiduciary split right, and most of the rest of the DPDP Act's requirements -notices, breach handling, data principal rights -slot in around a foundation that was built the right way from the start.
Building an edtech product that has to get children's data right?
SecComply maps your student data flows, builds a parental consent flow that holds up to scrutiny, and reviews where your school-licensed and direct-to-student deployments split fiduciary responsibility.
Book a compliance review call →FAQ
Anyone under the age of 18. The DPDP Act does not create tiered age bands the way some other data protection regimes do -a 17-year-old and a 7-year-old are treated identically as children for consent and processing purposes. If your platform serves K-12 students, undergraduate-prep programmes, or any user base that includes under-18s, Section 9 applies in full to those users.
Section 9 requires Data Fiduciaries to obtain verifiable consent from a parent or lawful guardian before processing a child's personal data, and it separately prohibits processing that causes any detrimental effect on the wellbeing of a child, along with tracking, behavioural monitoring, and targeted advertising directed at children. These are two distinct obligations -consent is a gate you pass through, while the tracking and advertising bar applies regardless of whether consent was obtained.
There is no single government-approved mechanism yet, so the practical approach is to build a consent flow that is verifiable, auditable, and repeatable: capture the guardian's identity and relationship to the child at the point of enrollment or account creation, log the consent event with a timestamp and the specific processing purposes covered, and make it just as easy for the guardian to withdraw consent later. Where a school or institution is the account holder, you can often route consent capture through the enrollment process the school already runs, rather than building a parallel flow directly with each family.
Targeted advertising directed at children is prohibited outright, and so is behavioural monitoring or tracking used to build the profiles that power it -consent does not create an exception. Recommendation logic based purely on academic signals, such as a student's quiz performance or course progress, sits in different territory from an ad-tech-style profile built from browsing and engagement behaviour, but the safest posture until the Rules provide more clarity is to keep any personalization strictly non-behavioural and disable third-party ad and tracking SDKs for child accounts entirely.
It depends on who determines the purpose and means of processing. When a school licenses your platform and controls how student data is used, the school is typically the Data Fiduciary and your platform is the Data Processor acting on its instructions -though your contract still needs to spell out security and consent obligations clearly. When students or parents sign up directly for your product without an institutional intermediary, your platform is the Data Fiduciary and carries the compliance obligations, including Section 9 consent, directly.