DPDP compliance for edtech in schools: a practical guide

India's Digital Personal Data Protection (DPDP) Act, and the Rules that followed it, changed the calculus for every school that handles student data - which is to say, every school. When that data includes minors and flows through an AI system, the stakes and the scrutiny go up together.

This is a practical guide for principals, trustees and IT coordinators, not a legal opinion. It explains, in plain terms, what DPDP asks of a school, where an AI vendor's responsibilities begin, and the specific questions you should ask before signing anything. Always have your own counsel review contract language before real student data is stored.

Who is responsible for what

DPDP draws a line between two roles, and getting this right is the foundation of everything else.

• The school is the Data Fiduciary. You decide why and how student data is collected and used. The legal responsibility for consent and for protecting students sits with you.
• A vendor like Pravachak is the Data Processor. We process data on your instructions, under a contract, and we must not use it for anything you have not authorised.

This distinction matters because it tells you where to focus. You cannot outsource your Fiduciary duty to a vendor - but you can and should demand that your Processor makes that duty easy to discharge, with the right consent tooling, controls and records.

The four things DPDP asks a school to get right

1. Verifiable parental consent for minors

DPDP requires verifiable parental consent before processing the personal data of anyone under 18. In practice, schools take one of two approaches:

• Institutional attestation, where the school attests that its enrolment process already obtained parental consent, and a consent record is stored on the student's first login.
• Per-student verifiable consent, where each parent confirms via a tokenised email link or OTP before the child's account activates.

Per-student consent is the legally safer model; institutional attestation is more practical at pilot scale. A responsible platform should support the safer model as you grow: parental consent emails sent to the registered parent address, a tokenised link that writes a consent record on click, and - crucially - the ability to gate AI features until consent is granted, so a student can read content but cannot use the tutor until the record exists.

2. Data minimisation and PII protection

Collect only what you need, and protect it in transit. A strong AI vendor masks personally identifiable information before a student's message ever reaches the language model, so names, phone numbers and similar details are stripped from the prompt at the gateway. Ask specifically: at what point in the pipeline is PII masked, and is masking on by default?

3. Data residency

Where does student data physically live? For schools across Bharat, data held in data centres in India is the defensible default and increasingly an expectation of boards and parents. Pravachak is built for data residency in India from day one - not as a later migration.

4. Audit, export and deletion

DPDP gives individuals rights over their data, and schools need the tooling to honour them:

• An immutable audit log of who did what - provisioning, role changes, logins, exports, deletions - that an administrator can filter and export.
• Data export on request: a student's personal data collected into a downloadable file within a defined window.
• Deletion workflows with a review window, where personal fields are overwritten while the audit skeleton (event types and timestamps, no PII) is retained for the school's own compliance record.

These are not features to build later. If they are not in the product on day one, the platform was not designed with DPDP in mind.

DPDP is a design decision, not a checkbox

The single most useful test of a vendor is when they built for privacy. Compliance bolted on after the fact is brittle - it shows up as manual processes, spreadsheets of consent, and "we'll get to that." Compliance designed into the data model is durable.

Pravachak treats DPDP as native from day one: consent records created at onboarding, PII masked at the AI gateway before any prompt leaves the school's environment, immutable audit logs, data export and deletion workflows, and data residency in India - all designed into the data model before any real student PII is stored, not added in a later phase.

There is a subtle governance point worth knowing, too. A well-designed platform limits even its own operators: when a Pravachak support engineer needs to help troubleshoot, individual student rows are masked and only aggregated, non-attributable views are visible. Support should never require exposing a child's quiz scores or chat sessions.

A checklist to take into any vendor conversation

Before you sign with any AI ed-tech vendor, ask:

1. Are you our Data Processor under a written Data Processing Agreement?
2. How do you support verifiable parental consent for under-18 students, and can AI features be gated on consent status?
3. At what point is PII masked in the pipeline, and is it on by default?
4. Where does our data physically reside?
5. Can we produce an audit log, data export and deletion for any student, ourselves, without filing a support ticket?
6. What happens to our data if we do not renew - what is the export window before deletion?

If a vendor cannot answer these crisply, that is your answer.

Where Pravachak fits

We built Pravachak so that a school can discharge its DPDP obligations as a Data Fiduciary with the tooling a modern platform should provide - consent, masking, audit, export, deletion and residency in India, all in the product. That is what lets school leaders adopt classroom AI with confidence rather than caveats.

Want a walkthrough of the consent, audit and data-residency controls with your IT coordinator on the call? Book a demo. And if you are weighing which tier fits your school's data and governance needs, our pricing page lays out what is included at each level.