Handling the personal data of children

Consent for a child's personal data is the hardest form of consent in the DPDP Act. Before processing any personal data of a child, you must obtain the verifiable consent of the child's parent or lawful guardian. And some processing is forbidden for children whatever consent you hold.

Two features make this duty heavier in India than many teams expect. The Act treats everyone under 18 as a child, while several frameworks elsewhere set a lower age for digital consent. And the consent must be verifiable, which puts the burden of proof on you. A declaration from whoever happens to be at the keyboard does not carry it. An "I am over 18" checkbox satisfies neither part.

An organisation meets four questions in sequence. First, finding out whether a user is a child at all, which the Rules allow you to process data for and which no method settles perfectly. Second, obtaining and verifying a parent, where Rule 10 of the DPDP Rules, 2025 points towards identity checks through government-backed credentials. Third, the prohibitions on tracking, behavioural monitoring and targeted advertising directed at children, which cut across how many products are built. Fourth, the exemptions in the Fourth Schedule to the Rules, which are available to defined classes for defined purposes and are narrower than they first appear.

The Schedule to the Act allows penalties of up to 200 crore rupees for breaching the additional duties around children's data, the same tier as failing to intimate a breach. These duties apply from around 13 May 2027, as notified, unless amended. They concern every organisation whose users may include people under 18, which covers education, gaming, social platforms, streaming, retail and a good deal else. This is not legal advice; take advice on your own facts.

Who the Act treats as a child

Everyone under 18

The Act defines a child as an individual who has not completed 18 years of age. That single definition sets the scope of every duty that follows, and its width is what makes the duty demanding. If your users include 17 year olds, you are processing children's personal data and you carry the full set of duties that follow, starting with verifiable parental consent before any processing begins. A coaching platform preparing Class 11 and 12 students for JEE and NEET is processing children's data for most of its users.

Teams working from frameworks built elsewhere often assume a lower threshold. Under the European General Data Protection Regulation, the age at which a young person can consent for themselves to online services can be set by a member state as low as 13. A product that gates age at 13 or 16 for a European launch, and reuses the same design in India, has been built for the wrong threshold. It will process the data of a large group of Indian users without a valid basis.

The Act does allow some flexibility. Under section 9, the Central Government may notify an age above which a particular Data Fiduciary is exempt from some or all of these duties, if it is satisfied that the fiduciary processes children's data in a manner that is verifiably safe. No such notification is in force, so 18 is the working figure. Build for 18, and note that a future notification could relax it for particular fiduciaries.

People with a lawful guardian

The same section extends the duty beyond children. Where the Data Principal is a person with disability who has a lawful guardian, you must obtain the verifiable consent of that guardian before processing. Rule 11 asks you to take due care to check that the guardian has been appointed by a court, or by a designated authority or local committee under the law governing guardianship. The mechanics resemble the parental case, but the group of people is different, so an organisation that builds only for children has covered part of the requirement.

This part of the duty gets less attention, and the Act does not say how an online service is meant to know that a user has a lawful guardian. A person whose disability does not affect their legal capacity consents for themselves in the ordinary way. Guardianship is a legal status established under other law, and an app cannot detect it. The practical position for most organisations is to provide a route through which a guardian can identify themselves, show their appointment and give consent, and to handle that route properly when it is used. Trying to detect guardianship from user behaviour would be both unreliable and intrusive.

Do not confuse this with nomination, which sits nearby in the Act. Nomination lets a Data Principal name someone in advance to exercise their rights in the event of death or incapacity. Guardian consent is given by the guardian for a person who cannot consent for themselves. Both need a route in the product, and they are different features serving different situations.

Finding out whether a user is a child

Why a declaration is not enough

To get a parent's consent before processing a child's data, you first need to know which users are children. That knowledge cannot rest on the user's own word. A checkbox confirming the user is over 18 is a statement by whoever is at the keyboard, and a child who wants to use the app will tick it. An organisation relying on that holds a record of a declaration and has no basis for processing.

A related shortcut fails for the same reason. Asking a child for a parent's email address and sending a message there proves that an address exists. It tells you nothing about who controls it or whether they agreed. The word "verifiable" is doing real work in the Act. It asks you to take measures sufficient to establish that the person giving consent is an identifiable adult standing in the parental or guardianship relationship, and a message to an unchecked address falls short of that.

This leaves organisations in an uncomfortable position. No online method of establishing age is complete. Every approach errs in both directions, refusing some adults and admitting some children, and each costs something in friction, in money or in the extra personal data you then have to handle. Realistic compliance here means choosing among imperfect methods, writing down why you chose as you did, and revisiting the choice as better options appear.

The methods available and what each costs

Several approaches are in use, and each has its own profile.

• Checking an official identity document. This gives high confidence about age, but you then hold identity documents, which are sensitive in themselves and carry their own security duties.
• Checking against a government-backed digital credential. This reduces what you store, because a token can confirm a fact, such as "this person is an adult", without handing over the document.
• Inferring age from behaviour or existing account data. This adds no friction and gives weak confidence.
• Estimating age from a facial image. Vendors offer this, and it involves collecting biometric data about a possible child.

The first two add friction that measurably lowers signup completion. The third carries a difficulty of its own: building a profile of someone in order to guess their age moves towards the behavioural monitoring the Act forbids for children. If you choose this route, think carefully about whether the inference itself is permissible for the very group you are trying to identify. Most organisations should treat the fourth with caution.

Before choosing any method, look at the product design, because a design choice can shrink the problem. A service that does not collect personal data until it needs to, and keeps children out of the features that require it, narrows the group whose age has to be established. A music learning app might let anyone browse free lessons without an account, and check age only when someone subscribes or joins a live group class. That is a product decision, and making it early costs far less than retrofitting age checks across an entire user base.

Processing in order to check

A loop appears once age checking is taken seriously. Finding out whether a user is a child means processing their personal data. If the user turns out to be a child, that processing needed parental consent, which you could not seek before you knew a parent was needed. The Rules deal with this. The Fourth Schedule allows processing limited to confirming that a Data Principal is not a child, as part of the due diligence expected of you.

That permission is narrow, and its narrowness is the point. Data collected to establish age is collected for that purpose only. Using an ID document submitted for an age check to enrich a marketing profile, or keeping it after the question is settled, falls outside the permission. Treat verification data as its own category with its own short retention rule, deleted or reduced to a minimal record once the check is done.

The minimal record should hold enough to show that a check was performed, when, by which method and with what outcome, without keeping the underlying document. A record stating that age was confirmed as above 18 on a given date through a named method, with a reference to the verification transaction, meets the evidential need and holds far less personal data than the document itself. Designing that record deliberately is one of the smaller pieces of this work and one of the more useful.

Obtaining a verifiable parent

What Rule 10 asks for

Rule 10 requires a Data Fiduciary to adopt appropriate technical and organisational measures to ensure that the verifiable consent of a parent is obtained before a child's data is processed. It also requires due diligence in checking that the person identifying as the parent is an adult who can be identified, if required, for compliance with law. Two duties sit inside that wording. The consent has to be verifiable, and the person giving it has to be identified as an adult. They are related, and they are separate.

For identification, the Rules point to reliable details of identity and age you already hold, or to identity and age details, or a virtual token mapped to them, issued by an entity entrusted by law or by the government, including through a Digital Locker service provider such as DigiLocker. A token lets you confirm that an identified adult is present without storing their credential. Organisations serving Indian consumers should expect this to become the common path. Design the flow so that other methods can be swapped in, because guidance in this area is still developing.

The relationship between parent and child is the least settled part. Proving that an identified adult is present is easier than proving that this adult is the parent or guardian of this particular child, and the available credentials do not always carry that link. Record what you relied on for the relationship, use the most reliable method available to you, and expect norms to develop as the Board and the market settle on practice.

Designing the consent flow

The flow that results has more steps than an ordinary signup, and the steps have to hold together. A user arrives, and the service establishes whether they are a child. If so, it explains what is needed and offers a route to involve a parent. The parent identifies themselves through the chosen method, reads the notice describing what will be processed and why, and consents. The service records the consent, the identification method, the notice version and the language, then allows processing within the purposes agreed.

A few details decide whether this works in practice:

• The parent may not be beside the child. In many households they will not be. The flow needs a route outside the child's session, with a durable link the parent can complete later on their own phone.
• The notice must be the itemised one the Rules require. It has to describe the data and the purposes clearly, in a language the parent reads. A parent in Lucknow may want Hindi; one in Surat, Gujarati; one in Kochi, Malayalam.
• Withdrawal must be as easy as giving consent. The parent needs a way back into a view where they can see and manage what they agreed to.

The record has to support the questions that arrive later: which parent consented, identified by what method, on what date, to which purposes, against which notice version and in which language, and on what basis the parent and child relationship was accepted. The same record serves consent generally; the child case adds the identification of the parent and the basis for the relationship. Organisations that build this properly can answer a question about a specific child years later. Organisations that record only a consent flag cannot answer any of it.

The processing the Act forbids

Tracking, behavioural monitoring and targeted advertising

Beyond the consent requirement, the Act sets prohibitions that consent cannot cure. Section 9 says a Data Fiduciary must not undertake tracking or behavioural monitoring of children, or targeted advertising directed at children. It also says you must not process a child's data in a manner likely to cause any detrimental effect on the child's well-being. A parent cannot authorise these activities on the child's behalf. Where the Data Principal is a child, the processing is out of bounds whatever consent exists, subject only to the exemptions in the Fourth Schedule.

Anyone building a consumer product should read this closely, because the prohibited activities describe how a large share of digital products are made engaging and earn money:

• recommendation systems that learn from a user's behaviour to decide what to show next;
• analytics that follow a user across sessions to measure engagement;
• advertising chosen on the basis of what the user has viewed;
• push notifications timed to observed usage patterns.

Each of these watches behaviour and adapts to it, and each needs examining against the prohibition wherever children are among your users.

The engineering consequence is that a product with children among its users needs two modes, and the difference between them has to be enforced inside the systems. A toggle in an admin screen will not hold. A recommendation service that does not know which users are children will personalise for all of them. Passing an indicator with every request, and having every system honour it, is the arrangement that works. Consent checks follow the same pattern with a different attribute, and organisations that build one can build the other.

What this asks of a product built on engagement

For some products the prohibition changes the offer itself, and the implementation follows from that. A service whose value rests on personalised recommendations, and whose revenue rests on advertising chosen from behaviour, cannot give a 14 year old what it gives an adult. There are three options: build a genuinely different experience for children, verify age and serve only adults, or drop the features that cannot be offered.

None of these is comfortable. The first costs development effort and produces a product with lower engagement for part of the user base. The second shrinks the market and adds friction for everyone. The third changes the product for all users. Choosing among them is a commercial decision for the people accountable for the product, made with an accurate view of what the law allows, and it should be made deliberately. Discovering it when the Board asks is the expensive way.

Organisations that never thought of themselves as serving children need to check too. A food delivery app, an OTT service, a bus booking site or a bank offering accounts for minors may have users under 18 without having designed for them. The duty attaches to the processing, whatever the organisation intended. Finding out whether children are present in your user base is therefore a first step across sectors, and many organisations will find a group they had not counted.

The exemptions and their limits

Classes and purposes

The Rules relieve certain classes of Data Fiduciary, and certain purposes, from the verifiable parental consent requirement and from the prohibition on tracking and behavioural monitoring. The relief is set out in the Fourth Schedule, and it is conditional. A class appears with a purpose attached, and the relief covers processing for that purpose and nothing further.

The pattern is easy to see in the classes listed. Clinical establishments, mental health establishments and healthcare professionals are covered on the condition that the processing is confined to providing health services to the child. A hospital emergency department treating an injured child cannot pause for a parental verification flow, and the exemption exists so that it does not have to. Educational institutions, creches and childcare centres, and those transporting children for them, are covered on conditions tied to the educational activity and to the safety of the children in their care. Tracking the location of a school bus for safety fits. Marketing to parents does not.

Reading an exemption correctly means holding onto the condition as tightly as the class. An organisation that qualifies for its core purpose does not thereby qualify for everything else it does. An edtech company working under a contract with a school may be covered for the academic processing at the centre of that contract, and sit outside the exemption for engagement tracking, promotional messages to families, or analytics shared with others. The same organisation can be exempt for one activity and fully bound for another, so the mapping has to be done activity by activity.

Working with an exemption responsibly

If you believe an exemption applies, document the position before you rely on it. Asserting it afterwards is far weaker. The record should state which class you fall into, which purposes you claim relief for, the conditions attached to that relief, and how you meet them. It should also state which of your activities sit outside the claim, because that boundary is the part a regulator will test.

A caution for anyone working from commentary: read the Rules themselves. The schedules in this area changed between the draft and the notified version, and further relief may be issued by notification. For anything not clearly inside a published exemption, the safe working assumption is that the full duty applies. If you build for the full duty and later find relief available, you can redirect the effort. If you assume relief and find none, you have been processing children's data without a valid basis, at the 200 crore rupee penalty tier.

The sequence that holds for any organisation in this position has four steps:

1. Find out whether children are among your users.
2. Build age assurance and parental consent for the processing that needs it, with records that will answer questions years later.
3. Separate the forbidden processing from the permitted processing inside your systems, where it is enforced by code.
4. Treat any exemption as a documented reduction of that work, never as a reason to postpone it.

Summary

The Act treats everyone under 18 as a child, a wider group than several other frameworks cover, and it requires verifiable consent from a parent or lawful guardian before any of that child's personal data is processed. "Verifiable" carries evidential weight, so a declaration by the user and a message to an unchecked address both fall short. Establishing age is therefore the first problem, and no method solves it completely. The realistic approach is to choose among imperfect methods, document the reasoning, keep verification data separate and short lived, and revisit the choice as practice develops. Rule 10 points towards identity checks through government-backed credentials for the parent, while the parent and child relationship remains the least settled part.

Beyond consent, the Act forbids tracking, behavioural monitoring and targeted advertising directed at children, and a parent cannot authorise them. That prohibition reaches into recommendations, cross-session analytics, behavioural advertising and usage-based messaging, which means a product with children among its users needs two modes enforced inside the systems. The exemptions in the Fourth Schedule attach to defined classes, with conditions tied to specific purposes. An organisation covered for its core function is not automatically covered for everything around it, and any claim of relief should be documented against its conditions before it is relied on. Children's data sits at the 200 crore rupee penalty tier, with the duties applying from around May 2027.

TrustOS lets you flag purposes and data sets that involve children, record the parental consent method used for each, keep that consent with the notice version shown, and hold your exemption reasoning as evidence. The product decisions about age checks, the two modes and the exemption boundary are yours to make first, and Code Colonies consulting works with product and engineering teams on exactly those decisions. For a shorter summary of the rules, see the guide to children's data. Processing without consent is covered in processing under the legitimate uses.