Handling the Personal Data of Children

Abstract

This article is the second in a three part series called Consent Under the DPDP Act. The first article dealt with consent arriving from a registered intermediary and the systems a data fiduciary needs in order to receive and act on it. This article deals with the hardest form of consent the Act contains. Before processing any personal data of a child, an organisation has to obtain the verifiable consent of that child’s parent or lawful guardian, and it has to refrain from certain processing regardless of any consent it holds.

Two features make this obligation heavier in India than the equivalent elsewhere. The Act treats everyone under the age of eighteen as a child, where several other frameworks set the threshold for digital consent considerably lower. And the consent required is verifiable, which places an evidentiary burden on the organisation instead of accepting a declaration from whoever is at the keyboard. A checkbox stating that the user is over eighteen satisfies neither part.

The article works through the sequence an organisation actually faces. Establishing whether a user is a child at all, which the Act permits processing for and which no method resolves perfectly. Obtaining and verifying a parent, where Rule 10 of the Digital Personal Data Protection Rules 2025 points toward identity verification through government backed credentials. The prohibitions on tracking, behavioural monitoring, and advertising directed at children, which cut across how many products are built. And the exemptions available to defined classes and purposes under the Fourth Schedule, which are narrower than they first appear.

The penalty position gives this obligation particular weight, with failures relating to children’s data sitting at the two hundred crore rupee tier alongside breach notification. The article is written for product and engineering leaders at organisations whose users may include people under eighteen, which covers education, gaming, social platforms, streaming, retail, and a good deal else besides. The third article in the series covers the circumstances in which the Act permits processing without consent at all.

1. Who the Act Treats as a Child

1.1 The age of eighteen

The Act defines a child as an individual who has not completed eighteen years of age. That single definition sets the scope of everything else in this article, and its width is what makes the obligation demanding. An organisation whose users include seventeen year olds is processing children’s personal data and carries the full set of duties that follow, including verifiable parental consent before any processing begins.

The threshold needs stating clearly, because teams working from frameworks developed elsewhere often assume a lower one. Under the General Data Protection Regulation the age at which a young person can consent for themselves to information society services can be set as low as thirteen by a member state. An organisation that has built age gating around thirteen for a European product, and reuses that design in India, has built for the wrong threshold and will be processing the data of a large group of users without a valid basis.

The Act does allow the age to be lowered by notification. Government may reduce it for a class of data fiduciary or a purpose, if satisfied that the fiduciary can process children’s data in a manner that is verifiably safe. No such reduction is in force, so eighteen is the operative figure, and an organisation planning its architecture should build for eighteen while noting that a future notification could relax it for particular sectors.

1.2 Persons with a lawful guardian

The same section of the Act extends the obligation beyond children. Where a data principal is a person with disability who has a lawful guardian, the fiduciary has to obtain the verifiable consent of that guardian before processing. The mechanics resemble the parental case and the population is different, which means an organisation building only for the child scenario has covered part of the requirement.

This part of the obligation receives less attention and it raises a question the Act does not resolve neatly. How is an organisation expected to know that a user has a lawful guardian. A person with a disability that does not affect legal capacity consents for themselves in the ordinary way. Guardianship is a legal status established under other law, and it is not something an online service can detect. The practical position for most organisations is to build a route through which a guardian can identify themselves and exercise the consent, and to handle it correctly when that route is used, without attempting detection.

Nomination, elsewhere in the Act, sits nearby and should not be confused with this. Nomination allows a data principal to name someone to exercise their rights in the event of death or incapacity, and it is exercised by the data principal in advance. Guardianship consent is exercised by the guardian on behalf of a person who cannot consent for themselves. Both need a route in the product and they are different features serving different situations.

2. Establishing Whether a User Is a Child

2.1 Why a declaration does not satisfy the obligation

The obligation is to obtain verifiable parental consent before processing a child’s personal data, and meeting it requires knowing which users are children. That knowledge cannot rest on the user’s own statement. A checkbox confirming that the user is over eighteen is a statement by whoever is at the keyboard, and a child who wishes to use a service will tick it. An organisation relying on that has a record of a declaration and no basis for processing.

A related shortcut fails for the same reason. Asking a child to supply a parent’s email address, and sending a message to it, establishes that an address exists and nothing about who controls it or whether they consented. The word verifiable in the Act is doing real work. It requires the organisation to have taken 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 unverified address does not reach that standard.

This leaves organisations in an uncomfortable position, and it deserves acknowledgement instead of a confident answer. No method of establishing age online is complete. Every approach carries error in both directions, refusing some adults and admitting some children, and each carries a cost in friction, in money, or in the additional personal data it requires the organisation to handle. Choosing among imperfect methods, documenting the choice and its reasoning, and revising it as stronger options appear is the realistic form of compliance here.

2.2 The methods available and what each costs

Several approaches to establishing age are in use and each has a distinct profile. Verifying an official identity credential establishes age with high confidence and requires the organisation to handle identity documents, themselves sensitive personal data attracting their own security obligations. Checking against a government backed digital credential service reduces what the organisation has to store, since a token can confirm a fact without transferring the underlying document. Both introduce friction that measurably reduces completion of a signup flow.

Inference from behaviour or from existing account data avoids friction and produces weak confidence. It also carries a difficulty of its own. Building a profile of a user in order to guess their age moves toward the behavioural monitoring the Act prohibits for children. An organisation choosing this route needs to think carefully about whether the inference itself is permissible for the group it is trying to identify. Age estimation from a facial image is offered by vendors and involves collecting biometric information about a possible child, which most organisations should approach with caution.

A design that avoids the problem is worth considering before any method is chosen. A service that does not collect personal data until it needs to, and that keeps children out of the features requiring it, narrows the population for which age has to be established. Where a core function works without an account, and verification is required only for a payment or a social feature, the product has a narrower and more clearly bounded verification problem. That is a product decision and not a compliance one, and taking it early costs far less than retrofitting verification across an entire user base.

2.3 The permission to process for verification

A circular difficulty appears once age verification is treated seriously. Establishing whether a user is a child involves processing that user’s personal data, and if the user is a child then processing requires parental consent, which cannot be obtained before the organisation knows a parent is needed. The Rules address this by permitting processing limited to confirming that a data principal is not a child, under the due diligence expected of the fiduciary.

That permission is narrow, and its narrowness is the point. Data collected in order to establish age is collected for that purpose and no other. Using an identity document supplied for age checking to enrich a marketing profile, or retaining it beyond the point where the age question is settled, moves outside what the permission covers. Organisations should treat verification data as a separate category with its own retention rule, deleted or reduced to a minimal record once the check is complete.

What the minimal record should contain is a practical question with a clear answer. It needs enough to show that a check was performed, when, by what method, and with what outcome, without keeping the underlying document. A record stating that age was confirmed above eighteen on a given date through a named method, with a reference to the verification transaction, satisfies 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.

3. Obtaining a Verifiable Parent

3.1 What Rule 10 asks for

Rule 10 of the Rules requires a data fiduciary to adopt appropriate technical and organisational measures to ensure that verifiable consent of a parent is obtained, and to observe due diligence in checking that the individual identifying themselves as a parent is an adult who is identifiable. Two obligations sit inside that sentence. The consent has to be verifiable, and the person giving it has to be identified as an adult, which are related and separate requirements.

For identification the Rules point toward details of identity and age already available to the fiduciary, or toward virtual tokens issued by an entity authorised by the government, including a digital locker service. In practice this points at the Aadhaar linked digital locker route, where a token confirms that an identified adult is present without requiring the organisation to hold the underlying credential. Organisations serving Indian consumers should expect this to become the common path, and should design the flow so that other methods can be substituted, since the guidance in this area continues to develop.

The relationship between parent and child is the part the Rules leave least settled. Establishing that an identified adult is in fact the parent or guardian of the particular child is harder than establishing that they are an adult, and the available credentials do not always carry the relationship. Organisations should record what they relied on for the relationship, apply the most reliable method available to them, and expect this to be an area where practice develops as the Board and the market settle on norms.

3.2 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. Where they are, the service explains what is needed and provides a route for a parent to be involved. The parent identifies themselves through the chosen method, receives the notice describing what will be processed and for what purposes, and gives consent. The service records the consent, the identification, the notice version, and the language, then permits processing within the purposes consented to.

Several details decide whether this works in practice. The parent needs a way to complete their part without sitting beside the child, since in many households they will not be. That calls for an out of band route with a durable link instead of a flow that must be finished in one session. The notice presented to the parent has to be the itemised notice the Rules require, in a language they can read, drawn from the Eighth Schedule set. Withdrawal has to be as easy as giving, so the parent needs a route back into a management view later.

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

4. The Processing the Act Forbids

4.1 Tracking, behavioural monitoring, and advertising

Beyond the consent requirement the Act imposes prohibitions that consent does not cure. A data fiduciary must not undertake tracking or behavioural monitoring of children, and must not direct targeted advertising at them. These are not activities a parent can authorise on the child’s behalf. Where the data principal is a child, the processing is out of bounds regardless of what consent exists, subject only to the exemptions covered in the next section.

The reach of this deserves careful reading by anyone building a consumer product, because the prohibited activities describe how a large share of digital products are made engaging and monetised. Recommendation systems that learn from a user’s behaviour to decide what to show next. Analytics that follow a user across sessions to understand engagement. Advertising selected on the basis of what the user has viewed. Push notifications timed according to observed usage patterns. Each of these involves monitoring behaviour and adapting to it, and each needs examination against this prohibition where children are among the users.

The engineering consequence is that a product with children among its users needs two modes instead of one, and the difference between them has to be enforced at the level of the systems and not by configuration in an interface. A recommendation service that has no knowledge of which users are children will personalise for all of them. Passing an indicator alongside every request, and having each system honour it, is the arrangement that holds. The same architectural pattern appeared in the first article for consent checking, applied there to a different attribute, and organisations that build one can build the other.

4.2 What this asks of a product built on engagement

For some products this prohibition changes the proposition and not the implementation. A service whose value rests on personalised recommendation, and whose revenue rests on advertising selected from behaviour, cannot offer the same thing to a fourteen year old that it offers to an adult. The honest options are to build a genuinely different experience for children, to require age verification and serve only adults, or to withdraw the features that cannot be offered.

None of these is comfortable and pretending otherwise would not help anyone. The first costs development effort and produces a product with lower engagement for a segment of users. The second reduces the addressable market and adds friction for everyone. The third affects the product for all users. Choosing among them is a commercial decision that belongs with the people accountable for the product, informed by an accurate account of what the law permits, and it should be taken deliberately and not discovered when a regulator asks.

There is a further consideration for organisations that have not thought of themselves as serving children at all. A retailer, a streaming service, a transport application, or a bank may have users under eighteen without having designed for them, and the obligation attaches to the processing and not to the organisation’s intention. Establishing whether children are present in the user base is therefore a first step for organisations across sectors, and a number of them will find a population they had not counted.

5. The Exemptions and Their Limits

5.1 Classes and purposes

Rule 10 establishes a framework of exemptions, under which certain classes of data fiduciary, and certain purposes, are relieved of the verifiable parental consent requirement and of the prohibition on tracking and behavioural monitoring. They are set out by reference to a schedule, and they are conditional and not general. A class appears with a purpose attached, and the relief applies to processing for that purpose and no further.

The pattern is visible in the examples that have been discussed since the draft stage. Clinical establishments, mental health establishments, and healthcare professionals appear, on the condition that the processing of a child’s data is confined to providing health services to that child. An emergency department treating a child cannot pause to complete a parental verification flow, and the exemption exists so that it does not have to. Educational institutions, day care centres, and those responsible for the care of children appear on conditions relating to the interests and safety of the children concerned, which covers matters such as tracking location for safety and not matters such as marketing.

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. A learning platform contracted by a school may be covered for the academic processing at the centre of its function while sitting outside the exemption for engagement tracking, promotional messaging to families, or analytics sold onward. The same institution can therefore be exempt for one activity and fully obligated for another, and the mapping has to be done activity by activity.

5.2 Working with an exemption responsibly

Where an organisation believes an exemption applies, the position should be documented before it is relied upon and not asserted afterward. The record needs to state which class the organisation falls into, which purposes it is claiming relief for, which conditions attach to that relief, and how the organisation satisfies them. It also needs to state which of the organisation’s activities sit outside the claim, since that boundary is the part a regulator will test.

A caution belongs here for organisations reading exemption commentary instead of the instrument. The schedules in this area have developed from draft to notified form, and further sectoral relief may be issued by notification. For anything not clearly within a published exemption, the safe operating assumption is that the full obligation applies. An organisation that builds for the full obligation and later finds relief available has spent effort it can redirect. One that assumes relief and finds none has been processing children’s data without a valid basis, at the two hundred crore penalty tier.

The prudent sequence for any organisation in this position runs in four steps. Establish whether children are among its users. Build verification and parental consent for the processing that needs it. Separate the prohibited activities from the permitted ones inside its systems. Treat any exemption as a documented reduction of that work and not as a reason to postpone it. The third article in this series turns from consent to the narrow set of circumstances in which the Act permits processing without it.

Conclusion

The Act treats everyone under eighteen as a child, a wider group than several other frameworks capture, and it requires verifiable consent from a parent or lawful guardian before any of that child’s personal data is processed. Verifiable carries evidentiary weight, so a declaration by the user and a message to an unconfirmed address both fall short. Establishing age is therefore the first problem, and no method resolves it completely, so the realistic form of compliance 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 toward identity confirmation through government backed credentials for the parent, while leaving the parent and child relationship as the least settled part.

Beyond consent the Act forbids tracking, behavioural monitoring, and advertising directed at children, and a parent cannot authorise those. That prohibition reaches into recommendation, 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 instead of one mode with a setting. The exemptions under Rule 10 attach to defined classes with conditions tied to specific purposes. An organisation covered for its core function is not covered for everything adjacent to it, and any claim of relief should be documented against its conditions before it is relied on. Children’s data sits at the two hundred crore penalty tier. The sequence that holds is to establish whether children are present, build for the full obligation, separate the prohibited processing inside the architecture, and treat exemptions as a documented reduction of that work.