Designing DPDP-Compliant Sign-Up Flows
In EdTech, your sign-up screen isn’t just a login—it’s a legal contract. Here is how to make it compliant without killing your conversion rate.
What DPDP expects from a “notice”
Your notice must be:
- standalone (understandable independently of any other information),
- written in clear, plain language, and
- include at minimum:
- an itemised description of the personal data you’ll process, and
- the specified purpose(s) and the service/use enabled by that processing.
It must also provide:
- the link/means to withdraw consent (as easy to withdraw as it was to give),
- the link/means to exercise rights, and
- the link/means to complain to the Board.
The golden rule for EdTech UX: “Just-in-time notices”
Instead of one long privacy notice at sign-up, use short notices at the exact moment you need data. This improves consent quality and reduces drop-offs.
Recommended “notice moments” in EdTech
- Account creation (student/parent/teacher)
- Profile completion (class, board, interests, location)
- Payments (billing and transaction identifiers)
- Marketing opt-in (WhatsApp/SMS/email updates)
- Camera/Mic access (classes, doubt sessions, proctoring)
- Sharing with third parties (video hosting, analytics, CRM, proctoring partners)
Each notice should clearly state:
• what data is collected now
• why it’s needed now
• what the user gets now
• how to withdraw / manage consent (one tap)
What is a “user account” in DPDP Rules (and why it matters)
The Rules define “user account” broadly: it includes profiles/handles/email/mobile number and similar presences used to access your services.
Practical implication for EdTech
Even “OTP login + phone number” can count as a user account context—so your notice and consent experience must be clean from the first screen.
DPDP-compliant sign-up flows (recommended patterns)
Screen 1: Choose account type
- Student (18+)
- Parent/Guardian
- Teacher/Tutor
- Institution Admin
Screen 2: Minimal sign-up
- Mobile/email + OTP
- Name (optional until later)
Notice block (must-have)
- Itemised data: mobile/email, device identifiers (if any), basic profile fields
- Purpose: account access, course access, support communications
- Links: withdraw consent / rights / complaint path
Screen 3: Consent controls
- Required: account + service communications
- Optional toggles: marketing, personalisation, analytics cookies (where applicable)
If the user is a child, you must ensure verifiable parental consent before processing the child’s personal data.
Recommended flow
- Child enters basic info → selects “I’m under 18”
- Parent verification step begins
- Parent reviews notice + gives verifiable consent
- Only then: child account is created / activated
Implementation note: Don’t allow a “full account” creation for a child until the parent step is completed.
This is often the lowest-friction model.
Recommended steps
- Parent signs up first (OTP)
- Parent sees a child-account notice + consent screen
- Parent adds child profile (only necessary fields)
- Parent dashboard: manage consent, withdraw, requests
The Rules also describe practical methods to verify parent/adult status (reliable identity+age details, authorised checks, virtual token, Digital Locker route).
For teachers, the highest risk is “over-broad access” to student data.
Recommended steps
- Teacher sign-up (minimal)
- Teacher verification (institution email, admin approval, or document check as per your policy)
- “Teacher Notice” specific to:
- what student data they can see
- purpose: teaching, doubt support, grading
Role-based access enforced technically (not policy-only)
Mandatory links you must publish
You should prominently publish:
Your notice must be:
You must also publish a grievance timeline not exceeding 90 days and implement measures to meet that timeline.
Practical UX tip
Put these links in:
– Sign-up notice footer (“Manage consent / Rights / Grievance”)
– App settings → “Privacy & DPDP”
– Help/Support page
What your sign-up notice should contain
High-risk EdTech screens
WhatsApp/SMS marketing opt-in
✔ Separate consent toggle (not bundled with “service messages”)
✔ Clear purpose (“offers, updates, reminders”)
Proctoring / camera / mic
✔ Explain what is captured, why, and how long it’s retained
✔ Provide alternative (where feasible) or clear necessity rationale
Third-party integrations
✔ If student data is shared with vendors (CRM, analytics, proctoring), add a short notice and link to the vendor list.
Implementation blueprint
Minimum backend objects (recommended)
Minimum logs to keep (audit-friendly)
Quick compliance checklist
Need these screens designed?
We deliver: UX copy + notice versions + consent ledger spec + parent consent flow + audit-ready evidence pack.