DPDP for Indian edtech — verifiable parental consent, Section 9 prohibitions, and what compliance looks like

India's edtech sector is exposed to the DPDP Act in a way no other consumer category is. The Act sets the bar for a 'child' at 18 — higher than GDPR (16, often 13) and higher than COPPA (13). Section 9 then bans three things outright when processing children's data: tracking or behavioural monitoring, targeted advertising, and any processing 'likely to cause any detrimental effect on the well-being of a child'. These prohibitions are not unlocked by parental consent — they are absolute. On top of that, you cannot process a child's personal data without 'verifiable consent of the parent or lawful guardian'. For an Indian edtech, that means re-architecting the consent layer, the analytics layer, the ad layer and the personalisation layer at once.

**Step 1 — Age determination before anything else.** The first decision your platform must make on every signup is: is this user under 18? Self-attestation ('I am over 18') is acceptable when there is no signal otherwise, but most edtechs have signals — a school domain on the email, a parent-purchased account, an age field in the curriculum. If signals exist, you cannot rely on self-attestation alone; you need a verification step. Implementation: a four-state user record — `unknown`, `self-attested-adult`, `self-attested-minor`, `parentally-verified-minor`. Every API call checks state before processing.

**Step 2 — Verifiable parental consent.** The DPDP Rules give you flexibility on the verification method, but the spirit is unambiguous: a tick-box saying 'my parent agrees' does not count. Workable methods, in rough order of cost and friction: (a) a ₹1 refundable charge from a parent's UPI or card (COPPA-style payment verification — the lowest friction at scale), (b) a DigiLocker-backed parent ID handshake (cleanest, but requires DigiLocker integration), (c) an Aadhaar-OTP linked to a parent's mobile (constrained by what UIDAI permits for your sector), (d) a signed parental authorisation uploaded as a document (high friction; reserved for edge cases). Build at least two methods so parents who fail one have a fallback.

**Step 3 — Strictly-necessary processing only for verified minors.** Once a user is verified as a child, your stack must process the minimum data needed to deliver the educational service and nothing else. No Google Analytics. No Mixpanel. No retargeting pixels. No 'recommended for you' personalisation that infers behavioural traits. The Rules give exempted categories some phased relief — healthcare providers, educational institutions and crèches get a lighter touch when processing is for the child's welfare — but a consumer edtech does not get to assume the same relief without a documented welfare argument.

**Step 4 — Separate the ad stack from the learning stack.** Most Indian consumer edtech serves under-18 users alongside 18+ test-prep aspirants. The DPDP Act does not let you run the same ad pipeline on both; you have to ad-gate by verified age status. Practical pattern: ad SDK only initialises when `user.verifiedAge >= 18`. Anything below that threshold sees no third-party ads, ever — and you have to document the gate to the Board if asked. If your CMS or LMS shows social-share buttons that load third-party trackers, those need to be replaced with no-tracker fallbacks for minor users.

**Step 5 — Notice and rights mechanism for both child and parent.** Your Section 5 notice has to be written so a 16-year-old can understand it. Plain English, no legal-ese. Both the child and the parent need rights handles: the child can read their data and ask for corrections; the parent can withdraw consent, request deletion, and escalate to your Grievance Officer. The withdrawal flow follows the same Section 6(4) ease-of-withdrawal rule as adult flows — a parent must be able to revoke consent as easily as they granted it.

**Step 6 — Vendor inventory and DPAs.** Every external service that touches student data needs a DPA on file, and the DPA must specifically permit processing of children's data. Most US-based analytics and CRM vendors have COPPA-aligned DPA clauses that are reusable; many Indian SaaS vendors have not yet built one, and you will need to ask. Common vendors to audit for an edtech: learning analytics (Mixpanel, Amplitude, PostHog), video infrastructure (Mux, Vimeo, Cloudflare Stream), payment gateway (Razorpay, Cashfree), email (SES, SendGrid), in-product chat (Intercom, Crisp), and any AI/LLM API processing student input.

**Step 7 — The Significant Data Fiduciary question.** Edtech at scale — anyone serving low-millions of children's accounts — is a leading candidate for SDF designation under Section 10. That layers four extra obligations: India-resident DPO reporting to the board, periodic independent audit, DPIA on material new processing, and additional reporting. The procurement cycle for an empanelled independent auditor will be long — getting in line now is cheaper than scrambling after a gazette notification.

**Step 8 — Run the scanner regularly.** The [checkDPDP scanner](/scan) catches the visible-from-browser failures — trackers firing before age determination, banners that do not handle the parental-consent flow, missing Grievance Officer, absent privacy notice for minors. The /edtech industry guide at [industries/edtech](/industries/edtech) walks you through the sector-specific checks. Most Indian edtech sites today fail four or more of the ten categories on a first scan; the path from there to defensible is real engineering work, but every category has a documented fix.

**Penalty exposure.** Section 9 violations sit in a ₹200 crore band — second-highest after Section 8(5) security. The 'gravity' factor in Section 33(2) is heavily weighted for children's data, so a serious Section 9 finding in an edtech at scale will not get the discounts that a comparable adult-data finding might. The conservative assumption: comply now, document the compliance, and treat children's-data processing as the single highest-priority programme on your DPDP roadmap.