Children’s data under the DPDP Act: what schools and apps must plan

The Act defines a child by age and treats their data as a special case, so a parent or guardian must give consent and that consent must be verifiable.

Behavioural tracking and targeted advertising aimed at children are restricted too, and the Act lets the government exempt certain classes of business or purpose through the Rules. Those exemptions change, so check current text.

This is a plain reading for planning. It is not legal advice. Your lawyer decides how the wording applies to your school, your paediatric clinic or your app, and which exemption, if any, you can rely on today.

Start with a headcount, not a policy. Ask which tables hold a minor’s name, photo, marks, attendance, health note or location, because a school ERP, a transport tracker and a library app each hold a slice.

Paediatric clinics have the same problem. Vaccination cards, growth charts and school certificates all sit in files linked to a child’s record, and marketing lists often carry that child’s birthday for a greeting.

Record each field, its purpose and every role that can see it, and delete any field that has no purpose a teacher or parent could name. Fewer fields mean less to protect.

Ask for date of birth at sign-up, before anything else is stored, and if the age falls below the threshold the child’s record stays pending until a parent confirms.

Link accounts through the parent’s own login. A school can use the guardian mobile number on the admission form to send a one-time code, while an app can ask for a parent email.

Keep the relationship explicit. Names alone are not enough. One parent record can hold two children and one child may have two guardians, so model the link as a join table rather than a text field.

The consent record needs the same skeleton as any other: purpose, notice version, source and timestamp, plus the parent’s identifier, the child’s ID and how they were verified.

Verification can be a code sent to a number the school already trusts, or a signed form scanned into the child’s file, whichever the risk justifies. A marksheet photo upload needs a lighter check than a health file, where a signed form or a match against an existing parent account is more suitable.

Withdrawal sits on the same screen. A withdrawal should switch off the feature, queue the child’s data for deletion and write a log entry showing who acted and at what time.

Audit every script on a child-facing page. Analytics, ad pixels, session replay and push-notification SDKs are the usual suspects, so remove the ones you cannot defend and block the rest for child accounts.

Then limit access: teachers need marks for their own class, not the full discipline history, and a transport coordinator needs a pickup address, not a medical note.

Finish with a dated list of three fixes you will ship this term, each assigned to one person and given a review date in the school calendar. Small and finished beats a grand plan.