DPDP-Act for schools — what the new law means for student data

This isn't legal advice. It's the operational checklist we run with schools to make sure their day-to-day data handling holds up under the DPDP-Act 2023.

If you've read the bulletin from your bar association already and your eyes glazed over — this post is for you.

What changed

The DPDP-Act came into force in late 2023 and is rolling out via rules through 2024–2026. For schools handling children's data (which is the whole school, by definition), the act imposes specific obligations:

1. Verifiable parental consent before collecting any child's personal data.
2. No behavioural monitoring that could harm the child.
3. No targeted advertising at children.
4. A named Data Protection Officer for schools above a threshold (still being defined).
5. Right to access · correction · erasure · withdraw consent — exercisable by the parent.
6. Breach notification to the Data Protection Board within 72 hours.

Schools that don't comply can be fined up to ₹250 crore for severe breaches. Probably never invoked at that level for a school — but ₹50 lakh – ₹1 crore for routine breaches is plausible.

The operational checklist

1. Consent

What the law wants: verifiable consent from the parent before collecting any data about a student under 18.

What this means operationally:

• The admission form is your one moment of clean consent capture. The form must list what data you collect, what it's used for, who it's shared with, and how long it's retained. The parent ticks a checkbox to consent.
• Re-consent if you add new uses. Started using the parent's email for newsletters when admission consent was for "school communication"? Re-consent needed.
• One-click withdrawal. If the parent wants to stop SMS notifications, that's a withdrawal — has to be honoured within reasonable time.

What we shipped: consent registry on the parent record. Every event the school can communicate about (attendance, fee due, exam result, holiday, marketing newsletter) is a separate consent line item. Parent can toggle each independently via the parent app or contact the school.

2. Data minimisation

What the law wants: collect only what you need.

What this means operationally:

• Audit your admission form. Why do you ask for the parent's PAN? You don't need it for admission — unless you're issuing 80G receipts. If you only need it for 80G, separate that into an optional field that triggers a different consent.
• Don't collect "in case useful later". Specific purpose, specific consent.

What we shipped: every field on a student / parent record has a Purpose tag. Auditors can see which fields are used for which workflow.

3. Storage limitation

What the law wants: delete what you no longer need.

What this means operationally:

• 5-year retention on student data after they leave? 7-year? Pick a number, document it, enforce it.
• Marketing leads (parents who enquired but didn't admit) have a shorter retention than enrolled students.
• The CCTV at the school gate keeps footage for 30 days, not forever.

What we shipped: soft-delete by default with retention-based hard-delete jobs. Configurable per data category per tenant. Audit log retained longer than the data it audits.

4. Security

What the law wants: "reasonable security safeguards" — undefined but enforced.

What this means operationally:

• TLS everywhere (you're not running an unencrypted parent portal).
• Per-tenant data isolation. A bug in school A's code can't return school B's students.
• Role-based access. The PE teacher doesn't see fee data.
• Audit log of who accessed what.
• Backup encryption.
• Breach detection.

What we shipped: all of the above. See /product/security for the architectural detail.

5. Cross-border transfer

What the law wants: notify when data crosses borders; some recipient countries are restricted.

What this means operationally:

• If your school's ERP hosts data in Singapore or the US, that's a cross-border transfer. Document it.
• If your AI provider is OpenAI (US-hosted), AI prompts containing student data cross borders.

What we shipped: per-tenant data residency. Indian customers can require Indian-only regions. AI: BYOK means you control where calls go (and which provider sees what); the platform-default option uses a region-locked endpoint.

6. Children-specific obligations

What the law wants: no behavioural monitoring that could harm the child; no targeted advertising; no profiling-driven decisions.

What this means operationally:

• Attendance tracking? Fine — operational necessity.
• "Behavioural scoring" of students for college recommendations? Risky. Probably need explicit, separate consent.
• Ads inside the parent app? No. Just no.

What we shipped: zero ads anywhere in the parent app, student app, school portal. AI features that could profile a student (recommendation, classification) are opt-in per tenant, with documented use of the output.

7. Right to access / correction / erasure

What the law wants: the parent can ask "what do you have on my child", "fix this", or "delete this".

What this means operationally:

• A documented process — who at the school receives the request, who acts on it, in what timeline (usually 30 days under DPDP).
• For erasure, the school has to balance against statutory retention. School records have to be kept for X years by board regulation; that takes precedence over parental erasure.

What we shipped: a tenant-admin "DPDP requests" inbox. Receives requests, routes to the right team, tracks 30-day SLA, archives the handled request for audit.

8. Breach notification

What the law wants: notify the Data Protection Board within 72 hours of becoming aware of a breach; notify affected individuals "without undue delay".

What this means operationally:

• Your incident response runbook needs a "DPDP notification" step.
• The 72 hours starts when you become aware, not when the breach actually happened.

What we shipped: post-mortem template includes a "DPDP notification required?" decision tree. Incident routing to the named DPO at the tenant.

What to do this week

1. Make sure your admission form has a consent section (most don't yet).
2. Audit one routine collection (e.g. the parent's PAN) — is it justified?
3. Identify your DPO. Make them visible internally; their email goes on the school website footer eventually.
4. Document your retention policy (a one-page table is enough to start).
5. Audit who has access to student records. Who in your school can pull every student's address right now? Fewer is better.

What we don't claim

DPDP-Act compliance isn't a software setting. It's an organisational discipline that good software supports.

The act is also still rolling out. The Data Protection Board hasn't been seated as of writing. The rules continue to be drafted. The fines we mentioned are theoretical maximums.

But schools that wait until the first major fine to start their compliance journey will be too late. Start small, document everything, escalate over time.

For schools using School Console: most of the technical controls above are already in your tenant. The organisational discipline — DPO, consent forms, retention policy — is yours to set. Talk to us if you want a 30-minute walk-through of how it's all wired.

This post is informational. Consult a qualified data-protection lawyer for advice specific to your situation.