CHAPTER II - OBLIGATIONS OF DATA FIDUCIARY

Section 9 - Processing of personal data of children

Official text

(1)The Data Fiduciary shall, before processing any personal data of a child or a person with disability who has a lawful guardian obtain verifiable consent of the parent of such child or the lawful guardian, as the case may be, in such manner as may be prescribed.

Explanation.—For the purpose of this sub-section, the expression “consent of the parent” includes the consent of lawful guardian, wherever applicable.

(2)A Data Fiduciary shall not undertake such processing of personal data that is likely to cause any detrimental effect on the well-being of a child.

(3)A Data Fiduciary shall not undertake tracking or behavioural monitoring of children or targeted advertising directed at children.

(4)The provisions of sub-sections (1) and (3) shall not be applicable to processing of personal data of a child by such classes of Data Fiduciaries or for such purposes, and subject to such conditions, as may be prescribed.

(5)The Central Government may, if satisfied that a Data Fiduciary has ensured that its processing of personal data of children is done in a manner that is verifiably safe, notify for such processing by such Data Fiduciary the age above which that Data Fiduciary shall be exempt from the applicability of all or any of the obligations under sub-sections (1) and (3) in respect of processing by that Data Fiduciary as the notification may specify.

Cross-references

Section 9

Commentary

Key point

Final clause-by-clause commentary incorporating Sections 4 to 8, Rules 10 to 12, the Fourth Schedule, and applications to AI, advertising, education, healthcare, CCTV, age assurance, employment and vendor processing

1. “The Data Fiduciary shall”

Section 9(1) opens by placing the obligation on the Data Fiduciary. The responsible person is therefore the person who, alone or in conjunction with another person, determines the purpose and means of processing the child’s personal data.

The role must be identified factually for each processing operation.

A school will ordinarily be the Data Fiduciary when it decides to collect children’s attendance, academic progress and safety information. A school-management platform may act as a Data Processor where it stores and manages that information exclusively on the school’s instructions. If the platform independently combines records from several schools to develop its own commercial student-prediction product, it determines an additional purpose and may become a separate Data Fiduciary for that operation.

The same analysis applies to hospitals, gaming platforms, social-media services, child-transport providers, CCTV vendors and AI providers. Contractual descriptions are relevant but not conclusive. A provider cannot avoid the obligations of a Data Fiduciary by calling itself a processor when it independently decides why children’s information will be used.

Section 8(1) remains central. A Data Fiduciary cannot outsource Section 9 compliance. Where a processor collects parental consent, hosts child profiles, tracks a school bus or operates educational analytics on behalf of the Data Fiduciary, the Data Fiduciary remains responsible for processing undertaken on its behalf.

Accordingly, Section 9 compliance requires the Data Fiduciary to understand the complete processing chain:

  • the interface through which the child enters the service;

  • the age-assurance provider;

  • the parent-verification service;

  • the identity or token provider;

  • the cloud host;

  • the analytics vendor;

  • the communications provider;

  • each advertising or software development kit;

  • every subprocessor;

  • each entity receiving or independently using child data.

A Data Fiduciary cannot establish compliance merely by showing that its own interface does not display targeted advertisements if a software development kit embedded in the application tracks the child for advertising elsewhere.

The word “shall” makes the duties mandatory. Compliance does not depend upon the parent requesting protection, the child complaining, the organisation intending harm or the service describing itself as child-directed.

2. “Before processing”

The requirement is temporal. Verifiable parental or guardian consent must precede the processing of the child’s personal data unless a precise exemption applies.

The ordinary sequence is:

  1. Determine whether the proposed processing involves personal data
  2. Assess whether the Data Principal is a child
  3. Identify the person claiming to be the parent
  4. Perform the adult-status and identifiability checks under Rule 10
  5. Provide the notice required by Section 5 and Rule 3
  6. Obtain consent satisfying Section 6
  7. Create and preserve the verification and consent record
  8. Begin only the processing covered by that consent

The Data Fiduciary must not collect a complete child profile and treat parental consent as an administrative formality to be completed afterwards.

Example

For example, a gaming platform cannot, before parental consent:

  • create a persistent advertising identifier;

  • record the child’s gameplay over several sessions;

  • create a likely-purchase score;

  • analyse the child’s failure points;

  • upload information to an advertising platform;

  • train a user-engagement model.

Similarly, an educational application cannot silently process a child’s learning behaviour for several days and ask the parent to approve the account later.

Consent subsequently obtained cannot retrospectively validate processing already carried out without an available ground.

3. The preliminary-processing problem

The rule that consent must precede processing creates a practical circularity. The Data Fiduciary may need to process some limited personal data to determine whether the individual is a child and to obtain parental consent.

The Fourth Schedule addresses this issue by disapplying Sections 9(1) and 9(3) for processing undertaken to:

  • confirm that the Data Principal is not a child; and

  • observe the due-diligence requirements under Rule 10, provided processing is restricted to what is necessary for that confirmation or due diligence.

This is not an exemption for general onboarding. It is a narrow enabling provision.

The processing may reasonably include:

  • declared age or date of birth;

  • an age-threshold result;

  • limited contact information needed to reach the parent;

  • adult-status verification;

  • a virtual token;

  • verification source and time;

  • a record that consent was granted or refused.

It does not ordinarily justify collecting:

  • a contact list;

  • precise continuous location;

  • browsing history;

  • advertising identifiers;

  • social relationships;

  • payment propensity;

  • emotional state;

  • voice samples unrelated to verification;

  • complete device history.

The age-assurance exemption should therefore be implemented as a separate and restricted processing flow. Data collected during that flow should not automatically enter marketing, analytics or model-training systems.

4. “Any personal data of a child”

The phrase “any personal data” is deliberately broad. Section 9 is not confined to information submitted directly by the child or to conventional identifiers such as name and date of birth.

It may cover:

  • name and contact information;

  • image, voice and video;

  • school and class;

  • location;

  • route history;

  • device and account identifiers;

  • search and browsing history;

  • game activity;

  • viewing behaviour;

  • attendance;

  • academic results;

  • learning difficulties;

  • disciplinary information;

  • friendships and communications;

  • health records;

  • biometric templates;

  • CCTV footage;

  • parent and family details connected with the child;

  • inferred interests;

  • emotional-state estimates;

  • model-generated learning or risk scores.

A teacher’s observation about a child is personal data even though the child did not provide it. A model-generated prediction is personal data where it relates to an identifiable child. A persistent device identifier may be personal data even where the platform does not display the child’s name.

The fact that information is pseudonymous does not automatically remove it from Section 9. If the information remains linkable to the child, account or device, it continues to be personal data.

The provision also applies where personal data is obtained indirectly. A school may enter a child’s information into an educational platform. A parent may provide a child’s medical information to a hospital. A camera may record a child. A platform may infer interests from activity. Section 9 is concerned with the personal data being processed, not simply with who typed it into the system.

5. Who is a child?

Under the DPDPA, a child is an individual who has not completed eighteen years of age.

This produces a bright statutory threshold.

IndividualStatus under the DPDPA
Seventeen years and eleven months oldChild
Eighteen years oldAdult
Student below eighteenChild
Employee or apprentice below eighteenChild
Married individual below eighteenChild
Minor creator or business-account holderChild
Sixteen-year-old capable of understanding the serviceChild unless processing-specific relief applies under Section 9(5)

There is no generally applicable mature-minor exception in Section 9. A person does not become an adult for the DPDPA merely because she works, earns, lives independently or understands the proposed processing.

Section 9(5) permits the Central Government to modify the applicable age threshold for specified processing by a particular Data Fiduciary where that processing is verifiably safe. Unless such a notification actually applies, the statutory threshold remains eighteen.

A Data Fiduciary should therefore not simply copy a thirteen-year or sixteen-year threshold from a COPPA or GDPR programme into its Indian onboarding system.

6. Age assurance and services not specifically directed at children

Section 9 applies to children’s personal data even where the service is intended for a general audience.

Potentially affected services include:

  • e-commerce;

  • food delivery;

  • banking;

  • video streaming;

  • search;

  • gaming;

  • social media;

  • healthcare;

  • hotels;

  • travel;

  • education;

  • recruitment;

  • employment;

  • AI assistance;

  • public CCTV;

  • loyalty programmes.

However, the DPDPA does not expressly say that every service accessible on the internet must collect identity documents from all users. The organisation must determine an appropriate age-assurance approach.

The strength of the mechanism should correspond with:

  • likelihood that children use the service;

  • nature of the service;

  • data collected;

  • existence of tracking or advertising;

  • consequences of misclassification;

  • availability of less intrusive verification;

  • risks created by the age-verification method itself.

A universal identity-document requirement may reduce underage access but create a large database of identity information. A simple self-declaration may minimise collection but provide weak assurance. Section 8(4), Rule 10 and the Section 9(2) well-being requirement require the Data Fiduciary to balance these issues through appropriate technical and organisational measures.

Where a user’s age is uncertain, the Data Fiduciary may adopt child-protective defaults rather than collecting maximum identity data. For example, it may:

  • disable targeted advertising by default;

  • avoid persistent behavioural profiles;

  • limit location;

  • place high-risk features behind verified adult access;

  • provide age-appropriate privacy settings;

  • request stronger assurance only when the user seeks a high-risk feature.

A contractual statement that the service is “not for persons below eighteen” is relevant but cannot be the entire compliance architecture if the service knowingly attracts children or has substantial evidence of underage use.

Section 9(1) requires more than the child’s own agreement and more than an unverified assertion of parenthood.

The legal requirements operate in two layers:

LAYER ONE: VERIFICATION

Was the person identifying herself as the parent checked as an identifiable adult in accordance with Rule 10?

LAYER TWO: VALID CONSENT

Did that person receive the required notice and give free, specific, informed, unconditional and unambiguous consent through clear affirmative action?

The first layer concerns the identity and status of the consent-giver. The second concerns the quality and scope of the consent.

An adult-status check followed by a pre-ticked consent box does not produce valid consent. Equally, an excellently drafted consent clicked by a child using a second email address does not satisfy the requirement for verifiable parental consent.

8. Rule 10: “Appropriate technical and organisational measures”

Rule 10 requires the Data Fiduciary to adopt appropriate technical and organisational measures to ensure that verifiable parental consent is obtained before processing.

This wording connects Rule 10 with Section 8(4). A legal notice alone is insufficient. The organisation must build the statutory sequence into its system.

9. Technical measures

Depending on context, technical measures may include:

  • age-assurance controls;

  • a restricted pre-consent environment;

  • separation of child and parent interfaces;

  • parent authentication;

  • adult-status verification;

  • token processing;

  • prevention of account activation before consent;

  • purpose-level consent choices;

  • parental withdrawal controls;

  • deletion and cessation workflows;

  • audit logs;

  • transition controls when the child turns eighteen.

A child’s account should not become fully active while parent verification remains pending.

If the platform uses advertising or analytics software development kits, those components should not begin child-level tracking before the parental process is completed. Preferably, prohibited components should remain disabled for child accounts even after consent because parental consent cannot override Section 9(3).

10. Organisational measures

Organisational measures may include:

  • a written parental-consent standard;

  • documented assurance levels for different services;

  • procedures for uncertain age;

  • procedures for disputed parenthood;

  • staff training;

  • escalation for high-risk accounts;

  • processor due diligence;

  • access restrictions;

  • retention schedules;

  • reviews of failed and suspicious verification;

  • periodic testing of consent workflows;

  • procedures for withdrawal and adulthood transition.

Appropriateness is contextual. The same mechanism need not be used for every service. A platform providing live child location, financial services or confidential medical records reasonably requires stronger assurance than an email-only account with no broader functionality.

11. “Due diligence”

Rule 10 does not demand absolute certainty. It requires due diligence.

Due diligence ordinarily requires reasonable, proportionate and documented care suited to the circumstances. The Data Fiduciary should be able to explain:

  • the risk it identified;

  • the verification method selected;

  • why the source is reliable;

  • what information was checked;

  • what information was deliberately not retained;

  • how suspicious or conflicting cases are handled;

  • how the process is tested;

  • how misuse is detected.

A Data Fiduciary cannot guarantee that no child will ever deceive an age gate or use a parent’s device. The legal inquiry is whether it implemented a credible system rather than a knowingly ineffective formality.

A checkbox reading “I am the parent and over eighteen” records an assertion but does not, standing alone, demonstrate the due diligence contemplated by Rule 10.

Similarly, sending an email to an address supplied by the child proves that someone controlling that email clicked the link. It may not prove that the person is an adult.

An SMS OTP proves control of a mobile number. It does not necessarily prove adulthood unless the number is connected with reliable age or identity information.

12. What Rule 10 requires the Data Fiduciary to check

The person identifying herself as the parent must be checked as:

  1. an adult who has completed eighteen years; and

  2. identifiable where identification is required in connection with compliance with Indian law.

The Rule permits verification through:

  • reliable identity and age details already available with the Data Fiduciary;

  • identity and age details voluntarily provided by the individual;

  • a virtual token mapped to those details and issued by an authorised entity.

The Rule’s emphasis is significant. It expressly requires verification of adult status and identifiability. It does not prescribe a universal documentary test of the biological or legal relationship between the adult and child in every transaction.

That omission should not be interpreted to mean that the Data Fiduciary may ignore obvious risks of false parental claims. The appropriate relationship assurance should depend upon the processing.

Example

For example:

  • a low-risk email-only account may justify a lighter relationship-assurance process;

  • access to a child’s complete medical record may require stronger proof of authority;

  • authorising live location monitoring may justify additional checks;

  • access to private communications or financial accounts may require formal evidence.

The organisation should distinguish three matters:

  1. the person asserts that she is the parent;

  2. the organisation verifies that she is an adult;

  3. the organisation assesses whether sufficient assurance exists that she may authorise the specific processing.

Rule 10 expressly addresses the second. The first and third remain relevant to whether the process genuinely obtains “consent of the parent” under Section 9(1).

13. Reliable details already available

Rule 10 permits the Data Fiduciary to use reliable identity and age details already held.

Prior availability is not enough. The details must be reliable.

The organisation should ask:

  • Were the details previously verified?

  • Was the source trustworthy?

  • Are the details current?

  • Is the account controlled by the supposed parent?

  • Is there evidence that the user is at least eighteen?

  • Can the individual be identified if legally required?

An adult age entered during unverified registration should not automatically be treated as reliable simply because it has remained in the database for several years.

14. Case 1: Child initiates, parent is an existing user

The child tells the Data Fiduciary that she is a child and identifies a parent. The platform enables the parent to identify herself through its application, website or another appropriate channel.

The parent states that she is an existing user and previously supplied identity and age information.

Before processing the child’s data, the Data Fiduciary must confirm that:

  • reliable age and identity details are actually held;

  • those details concern the person completing the consent flow;

  • the person is an identifiable adult;

  • the appropriate notice was given;

  • consent was affirmatively provided for the defined purpose.

The illustration does not permit the child to complete the parent step by entering the parent’s username.

15. Case 3: Parent initiates, parent is an existing user

The parent directly opens the account for the child and identifies herself as the parent. The Data Fiduciary may check reliable identity and age information held from the parent’s existing account.

The fact that the parent initiates the process does not eliminate the need for:

  • Section 5 notice;

  • valid Section 6 consent;

  • necessity;

  • purpose limitation;

  • Section 9(2) well-being analysis;

  • Section 9(3) prohibitions;

  • Section 8 security and retention.

16. Details provided by the individual or through a virtual token

Where the purported parent is not an existing verified user, Rule 10 permits the Data Fiduciary to use identity and age details voluntarily supplied by the individual or a virtual token mapped to those details and issued by an authorised entity.

17. Case 2: Child initiates, parent is not registered

The child identifies a purported parent. The Data Fiduciary enables the adult to complete a separate verification process.

Before creating the child’s account, the Data Fiduciary checks adult status and identifiability by reference to:

  • identity and age details issued by an authorised entity; or

  • an authorised virtual token.

The adult may voluntarily provide those details through Digital Locker.

The verification step should be completed by the adult, not merely by the child using details known within the household.

18. Case 4: Parent initiates, parent is not registered

The parent directly requests the child’s account but has no existing verified profile. The Data Fiduciary must complete the same adult-status and identifiability check before processing begins. Digital Locker may be used voluntarily.

The four illustrations establish that the legal standard does not depend upon whether the child or parent begins the account flow. The decisive issue is whether the purported parent is checked as an identifiable adult before processing.

19. “Authorised entity”

An authorised entity includes:

  • an entity entrusted by law, the Central Government or a State Government to issue identity and age details or a virtual token mapped to those details;

  • a person appointed or permitted by such an entity;

  • identity and age details or tokens made available and verified through a qualifying Digital Locker service provider.

A private age-assurance provider does not automatically become an authorised entity merely because it offers identity technology.

The Data Fiduciary should verify:

  • source of legal or governmental authority;

  • scope of appointment;

  • reliability of the token;

  • assurance provided by the token;

  • whether the provider stores source documents;

  • whether it acts as a processor or separate Data Fiduciary;

  • retention and security;

  • whether the token is reusable across contexts.

A token confirming that an individual has completed eighteen years may provide better data minimisation than transmission of the person’s complete identity document.

20. Digital Locker service provider

A Digital Locker service provider is a qualifying intermediary, body corporate or government agency notified under the relevant Information Technology Act framework.

Rule 10 recognises Digital Locker as a route through which identity, age details or an authorised token may be voluntarily supplied.

It does not require every parent to:

  • hold a Digital Locker account;

  • create one;

  • use a specific document;

  • disclose more information than needed.

The Data Fiduciary should structure the integration to receive the minimum useful result. For example:

Adult status: Confirmed

Verification source: Authorised token

Verification date: 17 August 2026

Consent record: CR-10481

This may be preferable to retaining:

  • full identity-document number;

  • complete address;

  • photograph;

  • unrelated demographic information;

  • a permanent copy of the source document.

The verification data is itself personal data and must be protected, retained only for a justified period and excluded from advertising or unrelated analytics.

21. Aadhaar, cards, video KYC and similar mechanisms

Rule 10 does not prescribe a closed list of mandatory methods consisting of Aadhaar OTP, payment-card verification, video KYC, bank micro-deposits, digital signatures or notarised documents.

These mechanisms may be relevant in particular contexts, but each requires separate analysis.

21.1 Aadhaar

The organisation must establish whether it is lawfully entitled to request or use Aadhaar information. Aadhaar should not become the default simply because it can prove age and identity.

21.2 Payment card

Possession of a payment card may indicate access to a financial instrument, but it does not necessarily prove adult status, identity or authority over the child.

21.3 Video KYC

Video verification may provide strong identity assurance but can be disproportionate for low-risk services. It also creates additional facial and audiovisual personal data.

21.4 Parent email

An email approval proves control of an email address, not necessarily that the person is an adult.

21.5 Parent phone OTP

An OTP proves control of a device or number. It does not by itself establish adult status.

21.6 Paper form

A signed form may record consent but does not automatically establish that the signatory was verified. The assurance depends on how identity and authority were checked.

The correct question is not whether the mechanism sounds strong. It is whether it lawfully and proportionately satisfies the Rule 10 due-diligence requirement in the relevant context.

22. Data minimisation in parental verification

Parental verification can create a paradox: in attempting to protect the child, the Data Fiduciary may collect excessive data about the parent.

Section 6(1) limits consent to personal data necessary for the specified purpose. Section 8 requires technical and organisational controls and erasure when the purpose ends.

The Data Fiduciary should therefore distinguish:

  • proof that the person meets the adult threshold;

  • information needed to associate the consent with the child’s account;

  • information needed to prove compliance;

  • information not needed for any of those purposes.

It should not retain the parent’s identity document for marketing, profiling, credit scoring or product development.

Where a token confirms adult status, the organisation should avoid collecting underlying identity information unless another law independently requires it.

Parental verification does not replace notice.

Before requesting consent, the Data Fiduciary must explain:

  • what personal data of the child will be processed;

  • each specified purpose;

  • the goods, service or function enabled;

  • how consent may be withdrawn;

  • how rights may be exercised;

  • how a grievance may be raised;

  • how the Board may be approached;

  • who can answer questions;

  • available language options.

The parent’s consent must then satisfy every Section 6 requirement.

24. Free

The parent must not be pressured into unnecessary processing.

A school should not make access to ordinary education conditional upon consenting to unrelated commercial AI training.

25. Specific

Separate choices may be needed for:

  • account administration;

  • optional publication of a child’s photograph;

  • future communications;

  • research;

  • model training;

  • third-party sharing.

26. Informed

The notice must describe the actual processing. “Improving education” does not adequately describe emotion analysis or general model training.

27. Unconditional

The service should not be tied to unnecessary data uses.

28. Unambiguous and affirmative

Silence, pre-ticked boxes and continued use do not establish consent.

29. Necessary data only

Even verified parental consent cannot authorise unnecessary collection.

30. Child-facing transparency

The parent is the statutory consent-giver, but the child remains the Data Principal.

The child should therefore receive an age-appropriate explanation where she is capable of understanding it.

A useful child-facing explanation may state:

  • what information is being used;

  • why the service needs it;

  • who may see it;

  • which information should not be shared;

  • how to ask the parent or organisation for help;

  • how to report a problem;

  • whether location or camera functions are active.

The explanation should be adapted to the relevant age group. A notice for a six-year-old and a seventeen-year-old should not be identical.

Parent consent should not be used to silence the child’s own views. This is especially important where the service involves:

  • confidential communications;

  • mental-health support;

  • education;

  • publication of images;

  • continuous location;

  • social interaction.

A parent who gave consent must be able to withdraw it under Section 6.

The process should be comparably easy to giving consent. If the parent consented through an application, the organisation should not require an in-person visit merely to withdraw.

After withdrawal:

  • consent-dependent processing must cease within a reasonable time;

  • processors must be instructed to cease;

  • personal data must be erased unless retention is authorised or required by law;

  • consent-dependent services may become unavailable;

  • unrelated punitive consequences should not arise.

Withdrawal should operate purpose by purpose where consent was granular.

A parent may withdraw consent for publication of a photograph without necessarily withdrawing consent for a child’s learning account.

If some processing continues under a Fourth Schedule exemption or another statutory basis, the Data Fiduciary should explain:

  • what continues;

  • why;

  • what information is retained;

  • how long it will remain;

  • what rights remain available.

32. Section 9(2): “Shall not undertake”

Section 9(2) is an independent prohibition. It is not merely a factor for deciding whether parental consent is adequate.

The prohibition cannot be waived by:

  • the parent;

  • the child;

  • a service contract;

  • school terms;

  • platform rules;

  • a vendor agreement.

Section 6(2) makes consent invalid to the extent it infringes the Act. A parent therefore cannot authorise processing prohibited by Section 9(2).

33. “Such processing of personal data”

The detrimental effect must arise from or be sufficiently connected with personal-data processing.

Section 9(2) is not a universal code controlling every feature of every child-facing product.

The required link exists where personal data is used to:

  • identify emotional vulnerability;

  • select harmful content;

  • promote excessive engagement;

  • expose location;

  • reveal confidential information;

  • classify a child unfairly;

  • discriminate;

  • facilitate bullying;

  • pressure spending;

  • create unsafe social connections.

A harmful feature that uses no personal data may be governed by consumer, child-protection or other law, but Section 9(2) requires the data-processing connection.

34. “Likely to cause”

The provision is preventive. Actual harm need not already have occurred.

At the same time, “likely” should not be reduced to any remote or speculative possibility. The Data Fiduciary should assess:

  • probability;

  • foreseeability;

  • severity;

  • repetition;

  • duration;

  • reversibility;

  • child’s age;

  • nature of personal data;

  • scale;

  • vulnerability;

  • available safeguards;

  • evidence from testing, incidents and complaints.

Probability and severity should be considered together.

A relatively low probability of physical danger arising from disclosure of precise child location may justify strong intervention because the potential consequence is severe. A frequent but minor inconvenience may not necessarily amount to a detrimental effect on well-being.

The Data Fiduciary should not wait for a child to suffer measurable injury before acting. It should assess the system before launch and reconsider it after:

  • a significant design change;

  • a new AI model;

  • a new advertising vendor;

  • evidence of unexpected use;

  • complaints;

  • a safety incident;

  • a breach.

35. “Any detrimental effect”

The word “any” gives the provision broad coverage, but the effect must still be detrimental to well-being.

Potential detriments include:

  • physical danger;

  • psychological distress;

  • humiliation;

  • reputational injury;

  • cyberbullying;

  • social exclusion;

  • discrimination;

  • educational disadvantage;

  • compulsive use;

  • economic exploitation;

  • interference with autonomy;

  • long-term digital labelling.

The analysis should remain evidence-based. Ordinary correction of misconduct or an age-appropriate educational assessment is not detrimental merely because the child dislikes the result.

36. “Well-being of a child”

Well-being is not defined in the Act. It should be interpreted broadly enough to capture the multiple ways in which personal-data processing can affect childhood.

37. Physical well-being

Relevant risks include:

  • exposure of live location;

  • stalking;

  • unauthorised pickup;

  • unsafe challenges;

  • disclosure of health information;

  • identification of the child’s school or route.

38. Mental and emotional well-being

Relevant risks include:

  • body-image manipulation;

  • anxiety;

  • compulsive engagement;

  • humiliation;

  • exploitation of fear or loneliness;

  • harmful ranking;

  • personalised exposure to distressing content.

39. Social well-being

Relevant risks include:

  • public disclosure of friendships;

  • cyberbullying;

  • social exclusion;

  • reputational labelling;

  • exposure of private communications;

  • interference with healthy relationships.

40. Educational and developmental well-being

Relevant risks include:

  • inaccurate learning labels;

  • permanently lowered opportunities;

  • excessive surveillance;

  • discouragement from experimentation;

  • discriminatory pathways;

  • treating predictive scores as fixed ability.

41. Economic well-being

Relevant risks include:

  • targeting children likely to make impulse purchases;

  • personalised pressure to buy virtual items;

  • monetisation of family circumstances;

  • manipulation through scarcity or fear of exclusion.

42. Applications of Section 9(2)

43. Harmful recommendations

A platform uses viewing history to recommend increasingly extreme dieting or self-harm-related material.

The use of the child’s history to select content creates a direct connection between personal-data processing and foreseeable psychological or physical harm. It may also constitute behavioural monitoring under Section 9(3).

44. Public academic ranking

A school publishes a named ranking using marks, attendance and behaviour records.

Although the underlying records may serve educational functions, public rankings can expose children to humiliation or bullying. The public-disclosure operation requires a separate Section 9(2) analysis.

45. Location exposure

A social application publishes the child’s live or recent location to nearby users by default.

The processing creates foreseeable physical-safety risks. Parent consent alone cannot cure a design likely to expose the child to harm.

46. Engagement manipulation

A platform identifies that a child is most responsive late at night and schedules personalised notifications to extend use.

This may constitute behavioural monitoring and may adversely affect sleep, education and mental well-being.

47. AI labelling

An educational model categorises a child as “low potential” based on incomplete historical records and uses that label to restrict future learning opportunities.

Section 8(3) governs completeness and accuracy. Section 9(2) separately addresses the likely detrimental effect on development and education.

48. Child well-being assessment

The Act does not expressly require every Data Fiduciary to prepare a document titled a child impact assessment. Nevertheless, compliance with Section 9(2) requires a reasoned pre-processing inquiry.

A useful assessment should examine:

  • age groups;

  • information collected;

  • inferred information;

  • purpose;

  • frequency;

  • retention;

  • location;

  • social interaction;

  • recommendation systems;

  • advertising;

  • automated decisions;

  • risk of manipulation;

  • educational consequences;

  • physical-safety consequences;

  • less intrusive alternatives;

  • child and parent controls;

  • mitigation;

  • testing;

  • incident and complaint data.

A bare conclusion stating “the feature is safe” provides little evidence of compliance.

49. Section 9(3): Three distinct prohibitions

Section 9(3) prohibits:

  1. tracking of children;

  2. behavioural monitoring of children;

  3. targeted advertising directed at children.

The prohibition is strong but not universally absolute because Section 9(4), Rule 12 and the Fourth Schedule create narrowly defined and conditional exemptions from Sections 9(1) and 9(3).

Parental consent alone is not an exemption.

50. Tracking

The Act does not define tracking. The term should be applied according to the nature, continuity and purpose of the processing.

Tracking may include systematic following or recording of a child’s:

  • location;

  • movement;

  • browsing;

  • application use;

  • device activity;

  • searches;

  • interactions;

  • transactions;

  • transitions across services.

Clear examples include:

  • cross-site advertising cookies;

  • cross-application software development kits;

  • persistent advertising identifiers;

  • tracking pixels;

  • continuous GPS history;

  • retargeting;

  • social graph mapping.

Use of a pseudonymous identifier does not prevent the activity from being tracking where the identifier follows or links the child.

51. One-time events

A one-time technical event may be different from systematic tracking.

A weather application may use approximate current location for a single request and discard it. That activity may be distinguishable from keeping precise location history.

The Data Fiduciary should consider:

  • whether movement is followed over time;

  • whether information is retained;

  • whether it is linked with other data;

  • whether it contributes to a profile;

  • whether less precise data would work;

  • whether an exemption applies.

No single factor is necessarily decisive.

52. Behavioural monitoring

Behavioural monitoring may include observing, recording, analysing or predicting a child’s:

  • engagement;

  • habits;

  • preferences;

  • performance;

  • emotions;

  • attention;

  • spending;

  • social interactions;

  • response to prompts;

  • future behaviour.

It may be automated or manual and may occur within one service.

The contention that internal or within-app analytics is automatically permissible is therefore incorrect.

A game that records every session, failure, pause and purchase response at child level may be behaviourally monitoring the child even if no information leaves the application.

Aggregate statistics that cannot reasonably be connected with an identifiable child present a different position.

53. A/B testing

Not every technical experiment is necessarily behavioural monitoring.

A system-level test using non-identifiable aggregate performance data may differ from an experiment that records which interface makes each child spend more time or money.

Relevant questions include:

  • Is child-level behaviour recorded?

  • Are children selected by personal data?

  • Does the output enter individual profiles?

  • Is the purpose to influence engagement?

  • Does the test exploit vulnerability?

  • Is an educational or safety exemption available?

A categorical statement that all A/B testing involving child users is prohibited would be too broad. The actual monitoring operation must be analysed.

54. Sentiment and emotion analysis

Analysing voice, text, facial expressions or interactions to infer emotional state is likely to constitute behavioural monitoring.

Risk increases where the inference is used to:

  • intensify engagement;

  • select advertisements;

  • identify purchase vulnerability;

  • impose discipline;

  • predict mental health;

  • disclose the result to third parties.

A safety tool intended to detect immediate risk may present a different purpose, but it still requires an exact exemption or other statutory basis and must satisfy Section 9(2).

55. Targeted advertising directed at children

Advertising is targeted where personal data is used to select, tailor or direct an advertisement to a child.

Relevant data may include:

  • identity;

  • age;

  • location;

  • browsing history;

  • game activity;

  • viewing history;

  • purchases;

  • inferred interests;

  • emotional state;

  • school;

  • family circumstances.

55.1 Prohibited examples

  • behavioural advertisements;

  • retargeting;

  • lookalike child audiences;

  • precise-location advertisements;

  • purchase-propensity targeting;

  • advertisements selected from educational weaknesses;

  • emotion-based commercial prompts;

  • advertisements selected using social relationships.

Parent consent cannot independently authorise these operations.

56. Contextual advertising

An advertisement selected solely because of the immediate content being viewed and shown identically without using child-level personal data may fall outside targeted advertising.

Example

For example, the same advertisement for a mathematics book shown to every visitor on a mathematics page may be contextual.

The conclusion depends on substance. If the platform also uses:

  • account identity;

  • previous pages;

  • age band;

  • interests;

  • prior purchases;

  • location;

  • device history;

the advertisement may be targeted despite being related to the current page.

Contextual advertising remains subject to Section 9(2), consumer law and other advertising restrictions. Non-targeted does not mean harmless.

57. Recommendations, promotions and advertising

A platform may describe personalised commercial content as:

  • a recommendation;

  • sponsored discovery;

  • engagement content;

  • a suggested experience;

  • an offer.

The label is not decisive.

The analysis should ask:

  • Is a product or service being promoted?

  • Has consideration been paid?

  • Is placement driven by personal data?

  • Is the purpose to influence a commercial decision?

  • Is the material selected using child behaviour?

  • Does the system independently constitute behavioural monitoring?

A streaming recommendation within a paid service may not always be an advertisement. However, the behavioural monitoring used to generate it may remain prohibited unless an exemption applies.

58. Section 9(4) and Rule 12: Conditional exemptions

Section 9(4) allows the Rules to disapply Sections 9(1) and 9(3):

  • for prescribed classes of Data Fiduciaries;

  • for prescribed purposes;

  • subject to prescribed conditions.

Rule 12 implements this through the Fourth Schedule.

The exemption must be interpreted narrowly.

A Data Fiduciary should document:

  • the precise Schedule entry;

  • whether it qualifies as the listed class;

  • the exact processing operation;

  • the permitted purpose;

  • personal data involved;

  • why the processing is necessary;

  • applicable time and scope limitations;

  • continuing safeguards.

The exemption does not disapply:

  • Section 9(2);

  • Sections 4 to 8;

  • security;

  • processor contracts;

  • breach notification;

  • retention;

  • grievance redressal;

  • data quality;

  • other applicable laws.

59. Clinical establishments, mental-health establishments and healthcare professionals

The Fourth Schedule provides relief where processing is restricted to the provision of health services to the child, to the extent necessary to protect the child’s health.

This is a purpose-bound exemption.

59.1 Potentially covered

  • diagnosis;

  • treatment;

  • medication;

  • monitoring;

  • emergency support;

  • referral;

  • necessary patient administration.

59.2 Not automatically covered

  • advertising;

  • sale of child health profiles;

  • product marketing;

  • unrelated research;

  • publication;

  • general commercial AI training;

  • insurance profiling unrelated to treatment.

A hospital is not exempt for every operation merely because it is a clinical establishment.

If it uses a paediatric patient’s records to provide treatment, the exemption may apply. If it transfers identifiable records to an AI company to create a commercial product, that independent purpose requires separate analysis.

Section 9(2) continues to apply. A health system must not process information in a manner likely to harm the child merely because it is a qualifying healthcare provider.

60. Allied healthcare professionals

The allied-healthcare exemption is restricted to supporting implementation of a healthcare treatment and referral plan recommended for the child, to the extent necessary to protect health.

Potential examples include:

  • physiotherapy;

  • diagnostic support;

  • rehabilitation;

  • therapeutic assistance;

  • referral coordination.

The exemption follows the treatment plan. It should not be extended to independent marketing, unrelated profiling or product development.

61. Educational institutions

The educational-institution exemption is confined to tracking and behavioural monitoring:

  • for the educational activities of that institution; or

  • in the interests of safety of children enrolled with that institution.

This does not create an institution-wide exemption from Section 9.

62. Educational activities

Potentially covered processing may include:

  • attendance;

  • completion of assignments;

  • academic progress;

  • examination activity;

  • learning support;

  • classroom participation;

  • identification of areas requiring educational intervention.

The processing must relate to the educational activities of the particular institution.

An education-technology company that pools student behaviour across unrelated schools to train a commercial model for sale is not automatically carrying out the educational activities of each school. It may be determining an independent product-development purpose.

63. Safety

Potentially covered safety processing may include:

  • access control;

  • emergency attendance;

  • school-bus coordination;

  • necessary CCTV;

  • incident monitoring;

  • authorised pickup.

The safety purpose should not become a general justification for continuous surveillance.

64. Limits

The exemption does not automatically authorise:

  • behavioural advertising;

  • student-profile sales;

  • unrelated vendor model training;

  • family-income inference;

  • public student rankings;

  • indefinite retention;

  • emotional manipulation;

  • advertising based on learning difficulty.

Section 9(2) remains applicable.

65. Crèches and childcare centres

The Fourth Schedule permits tracking and behavioural monitoring in the interests of safety of infants and children entrusted to the relevant care setting.

Potentially covered activities include:

  • check-in and checkout;

  • authorised pickup;

  • safety incidents;

  • emergency management;

  • monitoring movement within controlled areas.

The exemption does not authorise:

  • public streaming of children;

  • commercial facial analytics;

  • advertiser access;

  • permanent behavioural scoring;

  • use of footage to train unrelated models.

The Data Fiduciary should limit access to parents or staff with a genuine need and define a short retention period suited to the safety purpose.

66. Child-transport providers

A Data Fiduciary engaged by an educational institution, crèche or childcare centre may track the location of children:

  • for safety;

  • during travel to and from the institution.

The exemption is limited by:

  • the child’s travel;

  • the relevant institution;

  • the safety purpose.

Potentially covered processing includes:

  • live vehicle location;

  • boarding and drop-off status;

  • route alerts;

  • emergency notifications.

It does not automatically cover:

  • weekend tracking;

  • location after the child leaves the vehicle;

  • family movement profiles;

  • advertising;

  • indefinite route-history retention;

  • unrelated law-enforcement or commercial sharing.

A transport system should technically switch off, restrict or de-identify child-level tracking once the journey ends.

67. Statutory functions in the interests of a child

The Fourth Schedule provides relief where processing is necessary for exercising a power, performing a function or discharging a duty in the interests of a child under Indian law.

Potential contexts include:

  • child welfare;

  • protection;

  • missing-child functions;

  • statutory education;

  • judicial or administrative proceedings;

  • child-safety intervention.

The Data Fiduciary must identify:

  • the applicable law;

  • the relevant power or duty;

  • why the function is in the child’s interests;

  • the personal data necessary;

  • recipients;

  • retention.

The words “in the interests of a child” do not provide a general public-interest exemption for every government or police operation involving children.

68. Subsidies, benefits and public services

The exemption covers necessary processing to provide a subsidy, benefit, service, certificate, licence or permit under law, policy or public funding in the interests of a child and within Section 7(b).

Potential examples include:

  • educational scholarship;

  • health benefit;

  • child-welfare assistance;

  • public certificate;

  • food or nutrition benefit.

The exemption does not authorise:

  • political targeting;

  • public disclosure of beneficiaries;

  • commercial advertising;

  • unrelated interdepartmental profiling;

  • permanent data lakes without defined purposes.

69. Email-account creation

The Fourth Schedule permits processing necessary to create a user account used for communication by email.

The limitation is significant. The use of the account must remain confined to email communication for the exemption.

The provision does not automatically authorise:

  • scanning messages for advertising;

  • cross-service tracking;

  • commercial profiling;

  • training a general AI model on child emails;

  • location collection;

  • behavioural advertising.

If the service evolves into a broader social, advertising or content platform, the Data Fiduciary must reassess the exemption.

70. Preventing access to detrimental information

The Fourth Schedule permits processing necessary to ensure that information likely to harm the child’s well-being is not accessible to her.

Potentially covered activities include:

  • age assurance;

  • harmful-content classification;

  • child-safe search;

  • parental controls;

  • access restriction;

  • safety filtering.

The processing must remain necessary for the protective function.

A platform should not use safety-related information to:

  • build advertising segments;

  • identify emotional vulnerabilities for engagement;

  • retain permanent behavioural profiles;

  • sell parental-control insights;

  • train unrelated commercial models.

71. Confirmation that the user is not a child

The Fifth Part B entry permits processing necessary to:

  • confirm that the Data Principal is not a child; and

  • perform Rule 10 due diligence.

Age assurance should therefore be designed to answer the threshold question with the least intrusive data.

An age-estimation AI should be assessed for:

  • accuracy;

  • demographic bias;

  • false adult classifications;

  • false child classifications;

  • retention;

  • image security;

  • model training;

  • purpose creep;

  • human review.

A facial image collected only to estimate age should not automatically be retained for facial recognition or advertising.

72. CCTV processing involving children

CCTV requires a context-specific analysis.

73. Is every CCTV recording tracking?

The Act does not resolve whether every isolated camera recording constitutes tracking.

A distinction may be drawn between:

  • ordinary recording of a limited area for incident-based security;

  • systematic following of the child across locations or time;

  • facial recognition;

  • movement profiling;

  • watchlist matching.

The more persistent, linkable and person-specific the system, the stronger the case that it constitutes tracking or behavioural monitoring.

74. School CCTV

The educational-institution exemption may support necessary safety monitoring of enrolled children.

It does not permit:

  • cameras in washrooms or changing rooms;

  • public streaming;

  • advertising analytics;

  • commercial facial recognition;

  • indefinite retention;

  • unrelated productivity-style monitoring.

75. Crèche CCTV

Safety monitoring may fall within the prescribed exemption, but access and retention must remain limited.

A continuous public or parent-wide livestream can expose children beyond what is necessary for safety and create well-being risks.

76. State and police CCTV

Police or a State instrumentality may rely on Section 7(c) for an authorised legal function, but Section 7(c) does not automatically disapply Section 9.

The authority must examine:

  • whether a Fourth Schedule purpose exemption applies;

  • whether the operation is in the interests of a child;

  • whether Section 17 provides a relevant exemption;

  • whether the surveillance is authorised by other law;

  • whether the processing is necessary;

  • whether Section 9(2) is satisfied.

A general city-surveillance system does not become child-interest processing merely because children appear in its field of view.

77. Facial recognition

Facial recognition introduces distinct processing:

  • biometric template creation;

  • identity comparison;

  • watchlist matching;

  • retention of matches and non-matches;

  • decision-making.

The legal analysis must address each operation. Ordinary CCTV authority does not automatically authorise biometric identification.

78. Artificial intelligence

AI is a method of processing, not a lawful ground or exemption.

79. AI training

Parental consent to use a service does not automatically authorise general model training.

The Data Fiduciary must separately assess:

  • training purpose;

  • source data;

  • necessity;

  • notice;

  • consent;

  • behavioural monitoring;

  • processor or separate Data Fiduciary role;

  • retention;

  • memorisation;

  • well-being risks.

A school’s educational exemption does not automatically permit a vendor to train a commercial model for unrelated customers.

80. Educational AI

An educational institution may use AI to analyse progress where behavioural monitoring remains confined to its educational activities.

The school must still prevent:

  • permanent low-ability labels;

  • discriminatory pathways;

  • inaccurate interventions;

  • excessive surveillance;

  • public rankings;

  • denial of human review;

  • harmful self-fulfilling predictions.

Section 8(3) and Section 9(2) operate together.

81. Recommendation systems

A recommendation system using viewing or game history is likely to involve behavioural monitoring even if it does not display advertisements.

The educational exemption may apply in a genuine institutional-learning context. A general entertainment platform has no equivalent exemption merely because it claims recommendations improve experience.

82. Emotion recognition

Inferring emotional state from face, voice or text is behavioural monitoring and may create significant well-being risks.

It is particularly problematic where used for:

  • engagement optimisation;

  • advertising;

  • discipline;

  • purchase pressure;

  • vulnerability scoring.

83. Generative AI

A child-facing AI assistant may process highly personal conversations, images, voice and schoolwork.

The Data Fiduciary should address:

  • parent verification;

  • child-facing explanation;

  • prompt retention;

  • general model training;

  • unsafe outputs;

  • human escalation;

  • emotional dependency;

  • advertising;

  • behavioural monitoring;

  • security and breach response.

84. Marketing

Marketing involving children should be separated from service delivery.

Prohibited or high-risk practices include:

  • retargeting;

  • behavioural advertisements;

  • child-level interest segments;

  • precise-location targeting;

  • school-based commercial profiling;

  • emotion-based offers;

  • propensity-to-spend models;

  • advertisements selected from educational weakness;

  • lookalike child audiences.

A parent’s broad consent to “offers from us and our partners” does not overcome Section 9(3).

Where contextual advertising is used, the Data Fiduciary should ensure that:

  • no child profile is consulted;

  • no persistent identifier influences selection;

  • no cross-service history is used;

  • the advertisement is age-appropriate;

  • the advertisement is not likely to harm well-being;

  • no prohibited tracking supports measurement.

85. Scraping children’s personal data

Public visibility does not automatically permit unrestricted processing.

Section 3(c)(ii) must first be assessed. Even where particular information was made public:

  • information posted by a parent may not have been made public by the child;

  • information posted by a school may not have been made public by the child;

  • leaked information is not voluntarily made public;

  • restricted-profile information is not necessarily public;

  • inferred attributes are new personal data;

  • facial templates are not identical to public photographs;

  • combined profiles require separate analysis.

Scraping children’s photographs to train facial recognition or emotion-analysis models therefore requires much more than a claim that the images were visible online.

86. Children who are employees, applicants or interns

A person below eighteen remains a child even where she is:

  • employed;

  • applying for employment;

  • an apprentice;

  • a trainee;

  • an intern;

  • a gig worker.

Section 7(i) may support genuine employment processing, but Section 9 imposes additional obligations unless a valid exemption applies.

An employer engaging a child must consider:

  • parental consent;

  • legal restrictions on employment;

  • attendance monitoring;

  • CCTV;

  • location;

  • payroll;

  • health and safety;

  • biometric systems;

  • vendor disclosures;

  • disciplinary monitoring;

  • publication of photographs.

The employment relationship does not create a general Section 9 exemption.

87. Security and breach response

Children’s personal data may create increased consequences when compromised, particularly where it contains:

  • precise location;

  • school;

  • route;

  • photographs;

  • health information;

  • family details;

  • communications;

  • biometrics.

Reasonable safeguards should include:

  • restricted access;

  • encryption;

  • segregation from advertising systems;

  • export controls;

  • secure parent authentication;

  • monitoring of unauthorised parent-account access;

  • processor restrictions;

  • rapid incident escalation;

  • limited retention.

If child-location information is compromised, breach notification should include practical safety measures for the parent. Where appropriate, the child should also receive an age-suitable explanation.

88. Retention and transition to adulthood

Parental consent does not authorise retention until the child becomes an adult.

Section 8(7) requires erasure when:

  • consent is withdrawn; or

  • the specified purpose ends, unless retention is necessary under law.

A Data Fiduciary should identify separate retention periods for:

  • account data;

  • verification records;

  • learning data;

  • health records;

  • location;

  • safety incidents;

  • CCTV;

  • communications;

  • consent evidence.

When the child turns eighteen, the organisation should review:

  • whether the purpose continues;

  • whether the account should transfer to the adult;

  • whether parent access should cease;

  • whether fresh adult consent is needed;

  • whether historical child profiles remain necessary;

  • whether information should be erased;

  • whether new marketing consent is required.

The parent’s historical consent should not produce permanent control over the adult’s data.

89. Rule 11: Person with disability who has a lawful guardian

Section 9(1) also addresses a person with disability who has a lawful guardian.

The provision does not say that every person with disability requires guardian consent.

Rule 11 applies where the individual:

  • meets the specified disability and decision-making criteria; and

  • has a guardian appointed under the legally recognised mechanism.

90. Disability is not incapacity

The Data Fiduciary must not infer inability to consent from:

  • physical disability;

  • visual or hearing impairment;

  • speech difference;

  • autism;

  • a mental-health diagnosis;

  • need for assistance;

  • limited literacy.

The Rule refers to individuals who, despite adequate and appropriate support, are unable to take legally binding decisions.

The organisation should first consider accessible and supported decision-making, including:

  • screen-reader-compatible notices;

  • sign-language interpretation;

  • simplified language;

  • assisted communication;

  • additional time;

  • accessible consent controls.

91. Verification of guardian appointment

The Data Fiduciary must verify that the guardian was appointed by:

  • a court of law;

  • a designated authority;

  • a local-level committee, under the applicable guardianship law.

A family member does not become a lawful guardian merely by providing daily assistance.

The Data Fiduciary should check:

  • appointing authority;

  • validity;

  • scope;

  • identity of guardian;

  • whether the appointment covers the relevant decision;

  • any expiry or limitation.

92. Applicable guardianship laws

Rule 11 refers to:

  • the Rights of Persons with Disabilities Act, 2016;

  • the National Trust Act, 1999;

  • designated authorities;

  • local-level committees.

A designated authority is one designated under Section 15 of the Rights of Persons with Disabilities Act to support legal capacity. A local-level committee is one constituted under Section 13 of the National Trust Act.

93. Child provisions are not automatically extended to every adult with disability

Sections 9(2) to 9(5) are framed specifically around children. The guardian-consent requirement for persons with disabilities appears in Section 9(1).

It would therefore be incorrect to state that every adult person with disability is automatically subject to the child-specific tracking and advertising prohibition.

Other DPDPA rules, disability law, consumer law and equality principles remain applicable.

94. Section 9(5): Verifiably safe processing

Section 9(5) empowers the Central Government to notify an age above which a particular Data Fiduciary may receive relief from specified obligations under Sections 9(1) and 9(3) for specified processing.

It does not generally amend the definition of child.

A valid notification should be examined for:

  • identity or class of Data Fiduciary;

  • processing operation;

  • service;

  • revised age;

  • obligations disapplied;

  • conditions;

  • duration;

  • review provisions.

The Act does not itself establish a formal company-application process or guarantee that a Data Fiduciary may demand notification.

95. Verifiably safe

The Act does not define the test. Relevant indicators may include:

  • high privacy defaults;

  • strong age assurance;

  • no harmful profiling;

  • child-appropriate transparency;

  • restricted collection;

  • robust moderation;

  • effective parent and child controls;

  • security;

  • low incident history;

  • independent testing;

  • auditability;

  • effective grievances.

These are analytical factors, not an enacted statutory checklist.

96. Section 9(2) remains applicable

Section 9(5) permits relief only from all or specified obligations under Sections 9(1) and 9(3).

It does not authorise relief from Section 9(2). Processing likely to harm a child’s well-being remains prohibited.

97. Penalty position

Breaches of the statutory obligations concerning children may attract monetary penalties under the DPDPA framework, with the Schedule providing a maximum that may extend to ₹200 crore for the relevant category.

The amount is a maximum, not an automatic fixed penalty for every violation. It is a civil monetary-penalty framework, not a criminal sentence.

A service should therefore not state that every failed age gate automatically results in a ₹200 crore fine or criminal liability. The actual enforcement outcome would depend on the legal proceeding, facts and statutory penalty factors.

98. Final interpretation

Section 9 creates a layered and operation-specific framework.

Section 9(1) requires a real verification and consent architecture. Rule 10 does not prescribe a universal identity document or a closed list of Aadhaar, card, video-KYC or banking methods. It requires due diligence to check that the person identifying herself as the parent is an identifiable adult, using reliable details or authorised identity and age information, including virtual tokens and Digital Locker-supported information where applicable.

Verification is not consent. The verified parent must still receive the Section 5 notice and give consent satisfying Section 6. That consent cannot authorise unnecessary collection, detrimental processing, prohibited tracking or targeted advertising.

Section 9(2) is a non-waivable substantive limit. The Data Fiduciary must assess reasonably foreseeable effects on physical, emotional, social, educational and economic well-being before deployment and throughout the processing lifecycle.

Section 9(3) prohibits tracking, behavioural monitoring and targeted advertising. Internal analytics may amount to behavioural monitoring. Contextual advertising may fall outside targeted advertising only where it genuinely avoids child-level personal data and persistent profiling.

Section 9(4), Rule 12 and the Fourth Schedule provide narrow exemptions for defined healthcare, education, childcare, transport, statutory, public-benefit, email, safety-filtering and age-assurance purposes. Each exemption is confined to its exact conditions. None removes Section 9(2) or the general duties in Section 8.

Rule 11 establishes a separate guardian-verification framework for persons with disabilities who satisfy the applicable decision-making criteria and have a guardian appointed through the authorised legal process. Disability alone is not incapacity, and supported decision-making must not be ignored.

AI, CCTV, advertising, recruitment, employment, healthcare and education must each be analysed operation by operation. A beneficial label does not create an exemption. A school’s educational exemption does not travel into a vendor’s independent model-training business. A hospital’s treatment exemption does not cover commercial advertising. A child-transport exemption does not authorise location tracking outside the journey.

The controlling principle is:

Key point

Before processing a child’s personal data, the Data Fiduciary must establish who may lawfully authorise the processing, verify that person through a proportionate and reliable process, obtain valid purpose-specific consent where required, prevent foreseeable harm, disable prohibited monitoring and advertising, and rely on a Fourth Schedule exemption only within its exact institutional, purposive, temporal and necessity limits.

You are right. The commentary must remain anchored to the enacted words of Section 10 and the prescribed content of Rule 13, without importing GDPR concepts, speculative designation thresholds, unprescribed DPO safeguards, invented audit procedures, or broader AI-governance requirements. The following version therefore distinguishes strictly between what the Act and Rules require, what they necessarily imply, and what they leave unresolved.

Reproduced from official sources for reference. Not legal advice. In case of any discrepancy, the text published in the Gazette of India prevails.