What the DPDP Act actually asks of a school's student data

First, know which role you are in

Under the Digital Personal Data Protection Act, 2023, a school that decides why and how student records are processed is a Data Fiduciary. The student and their guardian are Data Principals. That carries most of the consequences: the duties land on the school, not on the software it uses, and they do not transfer by buying a product.

The Act and the final DPDP Rules, 2025 are being brought into force in stages, and several substantive requirements carry a later commencement date — check the schedule in the Rules themselves for the position on the date you are reading this. That is a reason to prepare deliberately, not to wait — most of the work below is record-keeping a well-run school benefits from anyway. Both are from MeitY: the DPDP Act 2023 (opens in a new tab) and the final Rules (opens in a new tab).

The obligations, in plain language

• Consent. Where consent is the applicable ground, process personal data only with free, specific and informed consent for a stated purpose — with a withdrawal path comparable to the way consent was given.
• Children's data (§9). For a child, obtain the verifiable consent of a parent or lawful guardian, and never undertake tracking, behavioural monitoring or targeted advertising directed at children. In a school that is the default posture, not an edge case.
• Purpose limitation. Use data for the purpose it was collected and consented for. A guardian number collected for absence alerts is not a marketing list.
• Data minimisation. Collect only what is necessary. Every extra field must be secured, retained, corrected and eventually erased.
• Accuracy. Keep records correct and complete. Mostly a workflow question: is there a route for a parent to report a changed phone number, and does it end in the record changing?
• Storage limitation. Erase personal data when the purpose is served — unless another law requires you to keep it. Financial and statutory records are the obvious exception, and must be excluded deliberately rather than by accident.
• Security safeguards. Protect the data with reasonable security. Role-based access and an audit trail are part of that, not extras.
• Breach. On a personal-data breach, notify the Data Protection Board and affected principals in the prescribed form and sequence. Write the procedure down before you need it.

What a parent can ask you for

Data Principals have the right to access a summary of their personal data and its processing; to correction, completion and updating of inaccurate data; to erasure of data no longer needed for the purpose, subject to lawful retention; to nominate; and to grievance redressal. A school needs a readily available means to exercise these rights and a named contact who answers.

The practical trap is erasure. A guardian asking you to delete everything is asking for something you cannot fully do — fee receipts, audit records and statutory registers are held under other obligations. The defensible answer is to redact identifying fields where you may, keep what the law requires in a restricted state, and be able to explain which is which. "We deleted it all" is usually either untrue or a compliance failure of a different kind.

Five things to do this term

1. Write down what you collect and why. One sheet per record type: what the field is, why you hold it, who can see it, how long you keep it. Most schools find two or three fields nobody can justify — the cheapest compliance win available.
2. Turn consent into evidence. A verbal yes at admission is not evidence twelve months later. Capture the decision and the exact notice wording it was given against, and make withdrawal a recorded decision too — not a phone call that leaves no trace.
3. Decide retention per record type, and accept the exceptions. Operational data such as notifications and message logs can age out on a schedule. Academic, financial, audit and consent records generally cannot; exclude them from any automatic purge and move them through a reviewed decision instead.
4. Restrict by role, not by trust. "Everyone in the office has the same administrator login" is the arrangement to look for first. A class teacher does not need the fee ledger; a fee clerk does not need medical notes. It is also the control that limits the damage of a shared password.
5. Treat special categories differently. Health, biometric, caste, disability and Aadhaar data demand stricter handling: store the minimum — the last four digits of an Aadhaar reference, not the number — restrict access by role, and never expose them to a third party, including an AI provider, without explicit consent.

If you use AI over student data, ask what leaves the building

AI features are standard in school software now, and they are the easiest place to lose control of children's data without noticing. Three questions are worth asking any vendor, including us. Does every model call go through one code path you can point at? What is removed before text leaves your system, and what is the honest limit of that removal? Which record types are excluded from the AI surface entirely?

For Vidyapeeth360: every model call routes through a single funnel; that funnel pattern-redacts common identifiers such as phone numbers, email addresses and government identifiers, and tokenises names when the calling flow supplies known values — permissions and the source records remain the real access boundary; and the named health, infirmary, wellbeing and counselling sources are excluded from the current student-AI context. Each is a checkable statement rather than a promise of universal redaction, which is the shape of answer to expect from anyone.

Where product controls help — and where they stop

Software can carry the evidence burden. Vidyapeeth360 provides an append-only consent ledger where each grant, rejection and withdrawal is a new immutable entry against the versioned notice it was given for; classification-driven retention where every record type carries a class and a window, and only allow-listed operational data self-purges; an internal timer that stamps a recorded breach with an operational deadline; a reviewed erasure path that redacts eligible fields while statutory records stay restricted; role-based access with an audit trail; and correction requests a parent or student files for the school to approve. These controls are designed to support a school's privacy programme as the framework commences in stages.

What no product can do: appoint your grievance contact, decide your lawful basis, write your notice, judge whether an incident is notifiable, or answer to the Data Protection Board. The internal 72-hour timer is operational evidence for your own follow-up — not the deadline for every notice, and not a determination that a notice is due. Product controls are not legal advice and not certification. Use them to make your programme provable; use your own advisers to make it correct.

A fuller mapping of each duty to the shipped control is on the DPDP readiness page, and the access model behind most of it is described under role and permission and user management.