Parental consent for schools and apps: what to ask before collecting a child's data

At a glance

Before you collect a child’s data — whether you’re a school on an admission form or an app at signup — the DPDP discipline is the same: ask for less, and verify who’s consenting. Collect only what the purpose needs, get verifiable parental consent (a real check that an adult guardian agreed, not a tick box), and bind the data to that purpose. Schools acting for genuine educational or safety purposes get some defined relief; commercial apps get none and must build the full parental-consent route.

Educational resource only. This explains what schools and apps should ask before collecting a child’s data under India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and its Rules; it is not formal legal advice.

The situation

Whether it’s a school admission form or an app onboarding screen, the instinct is to collect everything that might be useful — full family details, IDs, contact numbers, medical notes — because it’s easier than going back later. With a child’s data, that instinct is exactly the one to resist. The Act’s expectations start before consent: with what you ask for, and who you confirm is agreeing. Getting those two right is most of the job.

Ask less: data minimisation matters more for children

The first question isn’t “how do we get consent” — it’s “do we need this field at all.” The Act’s purpose-limitation and minimisation principles apply to everyone, but the stakes are highest with children’s data, where over-collection is both more common and more sensitive. A school form that asks for a parent’s PAN, both parents’ employers, and a sibling’s details “for records” is collecting well beyond what admitting a child requires. An app that pulls a child’s precise location or contact list to deliver a feature that doesn’t need it is doing the same. Every field you collect about a child is data you then have to justify, secure, retain on a schedule, and be able to delete. The cheapest way to reduce that burden — and the risk that comes with it — is not to collect what the purpose doesn’t genuinely need in the first place.

What “verifiable” means before you collect

Consent for a child’s data has to come from a verified adult guardian — a “parent” checkbox verifies nothing. The Act requires verifiable parental consent, meaning you have a reliable basis for believing the person consenting really is an adult and the child’s parent or guardian, not just someone who ticked a box saying so. The Rules set out accepted ways to do that verification — reusing reliable adult-identity details you already hold, or a voluntary identity check via an authorised virtual token such as a DigiLocker-issued one — and the mechanics of those routes are covered in depth in the dedicated verifiable-parental-consent guide. What matters at the asking stage is to design for verification from the start: the flow collects the child’s data only after an adult guardian’s consent has actually been confirmed, not in parallel with an unverified claim.

Schools vs apps: one duty, two settings

The minimise-and-verify duty is universal; the relief available splits sharply by what you actually do. The two settings sit differently under the Act:

• Consumer and commercial apps — an ed-tech product, a game, a social or learning app — get no blanket exemption. They have to build the full verifiable-parental-consent route and honour the tracking-and-targeting ban. “It’s educational software” is not, by itself, an exemption.
• Educational institutions acting for genuine educational or child-safety purposes fall within a defined relief for certain child-data restrictions — a school tracking a bus for safety, or processing needed to actually educate and safeguard the child, has a basis the commercial app doesn’t. But the relief is scoped to those genuine purposes: a school running a commercial marketing programme, or an ed-tech vendor sitting behind the school, doesn’t inherit the institution’s relief for that activity.

The practical read: decide honestly which side a given activity sits on. The same organisation can be inside the relief for its core educational processing and outside it for anything commercial bolted on.

Step by step: what to ask, and how

Scope the fields to the purpose, then verify the adult before the child’s data lands.

1. Write down the specific purpose for this collection — admitting the child, delivering a lesson, enabling a feature. One clear purpose, not “for our records.”
2. List only the fields that purpose actually needs, and cut the rest. If you can’t tie a field to the stated purpose in a sentence, don’t ask for it.
3. Identify the adult guardian and verify them before collecting the child’s data — reusing reliable details you hold, or an authorised virtual-token check for a new relationship.
4. Present a plain-language notice to the parent: what you’re collecting about the child, the single purpose, how long you’ll keep it, and how to withdraw or ask for deletion.
5. Collect the child’s data only after verification and consent are in place — never let an unverified signup complete and backfill consent afterwards.
6. Turn off profiling for the child’s account by default — the tracking-and-targeting ban applies regardless of what the parent agreed to.
7. Log the consent record — who was verified, when, by what method, and for which purpose — as your proof if it’s ever questioned.

Binding the data to the purpose you asked for

What you asked consent for is the fence around what you may do — children’s data especially can’t quietly migrate to new uses. Consent obtained to admit a child, or to run a lesson, covers that and nothing more. Feeding those same records into a marketing list, an analytics profile, or a new feature is a fresh purpose that would need its own basis — and for a child, several of those onward uses (behavioural profiling, targeted ads) are barred outright, consent or not. The discipline that makes this manageable is to bind each field to the purpose you collected it for and check any new use against that fence before you build it. Asked narrowly and kept on-purpose, a child’s data stays a small, defensible set; asked broadly and left to drift, it becomes the exposure the Act treats most seriously.

FAQ