Verifiable Parental Consent for EdTech

If your user is under 18, a checkbox isn’t enough. Here is the technical workflow for compliant onboarding under India’s DPDP Act.

The Compliance Requirement

Bridging the Compliance Gap

If your EdTech platform processes personal data of children, DPDP requires you to obtain verifiable consent from the parent/guardian before you process the child’s data. “Verifiable consent” is specifically the consent mechanism set out in the Rules.

Who this page is for

This guidance is relevant for Indian EdTech platforms that onboard or serve:

  • K–12 students
  • Coaching/test-prep students under 18
  • Tuition apps, doubt-solving apps, learning communities
  • Any platform that creates a “user account” for a child (as defined in the Rules).

What DPDP expects

You must implement technical + organisational measures so that verifiable consent of the parent is obtained before processing any personal data of a child.

You must check that the person claiming to be the parent is:

  • an adult (18+), and
  • identifiable if required for compliance with Indian law.

The Rules provide acceptable reference methods, including:

  • reliable identity + age details already available with you, or
  • identity + age details voluntarily provided by the parent, including via a virtual token issued by an authorised entity (and the Rules also recognise verification via a Digital Locker service provider).

Practical consent flows for EdTech

Case 1: Child signs up, parent is already your verified user

  • Child declares they are a child and names the parent.
  • Parent identifies via your app/website and confirms they are the parent.
  • Before creating the child’s account, you confirm you already hold the parent’s reliable identity + age details and that the parent is an identifiable adult.

Case 2: Child signs up, parent is not your user yet

  • Parent identifies via your app/website and confirms they are the parent.
  • Parent is not registered on your platform.
  • You verify parent adult status by reference to identity + age details issued by an authorised entity or through a virtual token mapped to identity + age.
  • Parent may voluntarily provide such details using a Digital Locker service provider.

Case 3: Parent creates the child account, parent is already your verified user

  • Parent initiates child account creation.
  • You check you already have parent’s reliable identity + age details and parent is an identifiable adult.

Case 4: Parent creates the child account, parent is not your user yet

  • Parent initiates child account creation without being registered.
  • You verify parent adult status using authorised identity/age references or virtual token (Digital Locker path permitted).

UX design: what your consent screen must include

A) Give a clear DPDP notice before asking for consent

Your notice must be:

  • understandable on its own
  • in clear, plain language
  • include an itemised description of personal data
  • include the specified purpose(s) and what service/features it enables
  • include a link/means to withdraw consent, exercise rights, and complain to the Board.

B) Make withdrawal as easy as giving consent

Your notice must include a withdrawal path with ease comparable to how consent was given.

Best practice for EdTech: show “just-in-time” notices:

✔ Account creation
✔ Payments
✔ Camera/mic access (proctoring)
✔ Marketing/WhatsApp updates
✔ Sharing with tutors/coaching centres

What to Store (For each child account)

  • Child identifier (internal)
  • Parent identifier (internal)
  • Date/time consent requested
  • Date/time consent granted/denied
  • Notice version ID shown at consent time
  • Consent scope (purposes) + any optional toggles
  • Withdrawal history (if withdrawn)
  • Verification method used

Technical Implementation Blueprint

Data Model

  • ParentIdentity (minimal verified adult flag + method + timestamp)
  • ChildAccount (linked to parent)
  • ConsentLedger (append-only events: requested / granted / denied / withdrawn)
  • NoticeVersions (each notice has version + effective date + language)

API Endpoints

POST /parent/identify
POST /parent/verify-adult
POST /child/account/create (blocked unless verified)
POST /consent/grant
POST /consent/withdraw

Operational controls

  • Role-based access (only authorised teams can view verification status)
  • Strong logging + tamper-evident audit trail
  • Minimal data retention for verification artefacts (store “verification result”, not extra documents unless truly necessary)

Compliance checklist

  • Age gate / child identification step
  • Parent identification step inside app/website
  • Adult verification using one of the permitted methods
  • Consent captured before child data processing begins
  • Plain-language notice shown before consent
  • Withdrawal path is easy and visible
  • Rights + grievance system published (response time ≤ 90 days)
  • Consent evidence pack + logs retained (audit-ready)

FAQ

OTP can help with account control, but DPDP’s “verifiable consent” requirement focuses on due diligence that the parent is an identifiable adult, using reliable identity+age details or authorised verification routes described in the Rules.

Not mandatory in all cases, but the Rules explicitly allow voluntary use of a Digital Locker service provider for providing identity/age details in certain flows.

Yes—publish a grievance response timeline not exceeding 90 days and implement measures to meet it.

Need this flow built in 10 days?

We deliver the UX screens, notice language, and consent ledger schema.

Get the Tech Specs