DPDPA Section 9: The Operational Reality of Processing Children’s Data

It does not matter if your application was built for children. It only matters if they are using it.

Under DPDPA Section 9, Data Fiduciaries are expected to implement reasonable measures to identify child users where their services are likely to be accessed by children. If your service can be accessed by users under 18, the law applies. When it comes to DPDP children’s data processing,and handling the data of persons with disability who have a lawful guardian, the rules are absolute. A child is anyone under 18 years of age. There is no mature minor exception.

What Section 9 Requires

Section 9 establishes five pillars:

• Parental or guardian consent must be verifiable before processing begins.
• Processing that is likely to harm a child’s well-being is prohibited.
• Tracking, behavioral monitoring, and targeted advertising directed at children are forbidden.
• Limited exemptions may be prescribed for specific classes or purposes, subject to conditions.
• The government can grant age flexibility to specific Data Fiduciaries with verifiably safe processing.

These duties attach to the Data Fiduciary, not to vendors or partners. You are accountable for design, implementation, and outcomes.

Verifiable Consent under Section 9(1) and Rule 10

A checkbox that says “I am the parent” is not compliance. It is a well-written lie.

Before processing a child’s data, you must obtain verifiable consent from the parent. For a person with disability who has a lawful guardian, consent must come from that guardian. Consent from thechild is not sufficient.

Rule 10 requires Data Fiduciaries to implement appropriate technical and organisational measures to obtain verifiable parental consent. Depending on the context, organisations may choose mechanisms such as Aadhaar-linked verification, Digital Locker-based identity verification, Video KYC, or other reliable identity-verification processes that satisfy the Rule’s due-diligence requirements.

Non compliant or weak approaches include:

• Checkbox claims such as I am the parent.
• Email only consent without identity verification.
• Simple age gates asking for date of birth or Yes or No.
• OTP to a phone number without identity linkage.

A practical flow:

• Detect age and classify under 18.
• Notify that parental consent is required with clear purpose and data details.
• Collect parent contact, initiate a verified identity check using an accepted method.
• Present an informed consent notice post verification.
• Record the decision. Deny access if consent is refused or cannot be verified.

For persons with disability who have a lawful guardian, verify the lawfulness of guardianship and the guardian’s identity using equivalent methods.

No Harm to Well Being under Section 9(2)

Parental consent is not a liability shield. Processing that is likely to cause a detrimental effect on a child’s well-being is not allowed, even if the parent has consented.

The standard is precautionary. You do not wait for harm to occur. If a practice is reasonably likely to harm, you must not do it. Common risk areas include:

• Addictive design that exploits variable rewards or nudges to keep children engaged.
• Features that undermine mental health or self esteem, including body image manipulation.
• Aggressive notifications and FOMO tactics that cause anxiety or impair education.
• Public exposure of personal data that enables bullying or harassment.
• Age inappropriate content surfaced by algorithms.
• Security failures that expose children to identity theft or safety risks.

Document a harm assessment for child data processing, set clear boundaries, and remove designs that increase risk.

Absolute Prohibitions under Section 9(3)

Three activities are banned for children’s data. Parental consent does not override these bans:

• Tracking children. Cross site or cross app tracking, persistent location tracking, search history tracking, and social graph tracking are prohibited. Functional session cookies and within app analytics that do not create cross service profiles can be acceptable if strictly limited.
• Behavioral monitoring. Profiling to predict or influence behavior, sentiment analysis, psychological profiling, engagement A or B testing on children, or habit formation monitoring is not allowed.
• Targeted advertising directed at children. Behavioral ads, retargeting, lookalike targeting, or ads personalized using a child’s personal data or behavior are prohibited. Contextual ads and generic ads that are the same for everyone can be acceptable.

Do not build or buy SDKs, pixels, or analytics that create behavior profiles of children. Segregate telemetry for users identified as under 18 and remove cross app and cross site identifiers.

Exemptions under Section 9(4) and Rule 11

Section 9(4) allows the government to prescribe classes of Data Fiduciaries or purposes that are exempt from the obligations in Section 9(1) or 9(3), subject to conditions. Rule 11 identifies examples:

• Educational institutions for necessary educational purposes with safeguards and parental notice.
• Medical emergencies where delay would cause harm and the parent is unavailable.
• Government services required for child welfare under law with oversight.

Important boundary. Any exemption from Section 9(3) must arise from the specific classes, purposes, and conditions prescribed under the Rules. Organisations should not assume an exemption exists unless they clearly fall within a notified category.

Age Flexibility under Section 9(5)

The government may notify a higher age above which a specific Data Fiduciary is exempt from some or all obligations under Section 9(1) and 9(3). This is granted only if the processing is verifiably safe and is service specific and entity specific.

What to expect if you seek flexibility:

• Demonstrate strong technical and organizational safeguards, clean compliance history, and independent audits.
• Show age appropriate design in practice.
• Expect conditions and revocation if standards slip.

If granted, users above the notified age can self consent and the prohibitions specified in the notification may not apply for that service.

Operational Implications and How to Execute

Certain violations under the DPDPA can attract penalties of up to ₹200 crore, depending on the applicable provision and penalty schedule. Treat Section 9 as a design level control, not a consent banner problem.

Key steps to become compliant:

• Build real age detection. Collect birthdate, flag under 18 at registration and login, and implement session handling that blocks processing until parental or guardian consent is verified.
• Implement at least one strong Rule 10 verification method and offer alternatives. Store verification evidence, timestamps, and the consent record tied to a stable parent identifier.
• Segregate child data. Apply privacy by default. Disable cross site and cross app identifiers, inference pipelines, and behavior based personalization for flagged child accounts.
• Remove targeted ads for children. Restrict ad tech to contextual or generic ads. Contractually require ad partners and SDK providers to disable tracking and profiling for child traffic.
• Run a Section 9(2) harm assessment. Identify features that create likely harm for children. Modify or remove high risk mechanics such as variable rewards, dark patterns, and late night notifications.
• Provide parental controls. Enable withdrawal of consent, access, and deletion. Stop processing promptly when consent is withdrawn and document the action.
• Train teams. Product, engineering, data science, growth, marketing, and customer support must understand Section 9 obligations.
• Govern vendors. Inventory SDKs, pixels, analytics, and ad networks. Obtain written assurances that child data is not tracked, profiled, or used for targeted ads. Audit regularly.
• Prepare for exceptions. Support offline consent where needed. Build processes for lawful guardians. Address international user scenarios with acceptable verification.
• Audit and monitor. Review telemetry for violations, test that prohibitions remain enforced, and maintain incident response for child data breaches.

Closing

Section 9 is practical if you handle it like an operator. Make age a gating criterion, secure a verifiable parent or guardian consent path, cut off tracking and targeted ads for children, and redesign high risk engagement features. The model is simple. The hard part is consistent execution across code, vendors, and teams.

Regodit can help you translate these duties into an operating system for compliance. Map obligations, design verifiable consent, enforce technical controls, manage vendors, and keep evidence aligned with Section 9.

Explore how Regodit can help you operationalize DPDPA Section 9 with clear controls and auditable records. If this is on your roadmap or already on your desk, schedule a discussion to go deeper on your specific stack and constraints.