DPDPA Compliance for Social Media Platforms: The Complete Guide to Parental Consent and Age Verification in India (2025–2027). Why Every Social Media Platform in India Must Act Now.
If you run a social media platform in India, verifiable parental consent and age verification are no longer optional – they are hard legal obligations with a hard deadline. The Digital Personal Data Protection Act, 2023, and the DPDP Rules, 2025, require every platform to obtain verifiable parental consent before processing any personal data of a user under 18. The compliance deadline is May 2027. This guide walks you through exactly what the law demands and how to implement a complete, audit-ready verification flow.
That’s when the full compliance machinery of India’s Digital Personal Data Protection Act, 2023 (DPDPA) and the Digital Personal Data Protection Rules, 2025 (DPDP Rules) comes into force. Among its most demanding requirements are the rules around children’s data, specifically, the mandate that social media platforms must obtain verifiable parental consent before a child can create an account, and that the child’s age must be independently verified, not self-declared.
This is not a checkbox exercise. The law is explicit, the penalties are steep (up to ₹250 crore for violations involving children’s data), and the Government of India has made child safety online a national priority. A “simple I am above 18” checkbox, as one legal analysis succinctly put it, is “no longer sufficient.”
This guide is for product heads, compliance officers, CTOs, and founders at social media companies who are searching for a practical, end-to-end solution. We’ll walk you through exactly what the law says, what it demands of you technically, and a proven implementation flow you can start building today. Please also request for our full white paper with FAQs and integration details.
***
What the law says about DPDPA Parental Consent and Age Verification – Section 9 of the DPDPA 2023 decoded
Who Is a “Child” Under the DPDPA?
Under Section 2(f) of the DPDPA 2023, a “child” means any individual who has not completed eighteen years of age. This is a notably stricter definition than most global frameworks: GDPR sets the threshold at 16 (with Member States allowed to lower it to 13), and the US COPPA law applies only to children under 13. India’s uniform age of 18 is one of the most conservative in the world, and it means your obligation covers a much larger portion of your user base than you might expect. If a teenager of 16 signs up for your platform, they are legally a child under Indian law. Full stop.
The Core Obligation: Section 9(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.” Section 9(1), Digital Personal Data Protection Act, 2023. This provision creates three non-negotiable requirements: Before any personal data is processed — which includes collecting a name, email, date of birth, or any other identifier — you must have parental consent; That consent must be verifiable, not merely asserted; The manner of verification must follow the prescribed rules (i.e., the DPDP Rules, 2025).
The Prohibitions: Section 9(3)
Beyond consent, Section 9(3) of the DPDPA goes further and categorically prohibits certain types of data processing for children, even if parental consent has been obtained. These include: Behavioural monitoring of children; Targeted advertising directed at children; Any processing likely to cause a detrimental effect on the well-being of a child.
The law’s harm-based prohibition is absolute. A gaming platform’s loot box mechanics, an algorithm that amplifies unrealistic beauty standards, or any data-driven system designed to manipulate children’s attention — all of these are categorically forbidden. Parental consent does not override this provision.
The Penalty Reality
Violations involving children’s data are among the most heavily penalised under the Act. The Data Protection Board of India can levy penalties of up to ₹250 crore for failure to observe obligations relating to children’s personal data. In extreme cases, under Section 37 of the Act, the Government may order the blocking of non-compliant platforms entirely. Repeat violations significantly amplify the risk. This is not regulatory risk to be managed quietly. This is existential risk for a platform that gets it wrong.
***
What “Verifiable” Actually Means – And Why Self-Declaration Fails
The word “verifiable” in Section 9(1) is doing a tremendous amount of legal work. It means that a parent simply clicking “I consent” on behalf of their child is insufficient. The law, as elaborated in Rule 10 of the DPDP Rules 2025, requires that the platform take active steps to confirm:
- That the person claiming to be the parent is actually an adult
- That the person claiming to be the child is actually a minor (below 18)
- That there is a genuine parent-child relationship between the two
This is a fundamentally different requirement from anything Indian platforms have had to implement before. It eliminates the “honour system” entirely. You cannot simply ask users to declare their age. You cannot rely on a credit card check. You need a structured, identity-anchored verification flow that creates a defensible audit trail.
The DPDP Rules specifically name virtual identity tokens as a compliant method of verification. In the Indian context, this points squarely to the Aadhaar and DigiLocker ecosystem – the only identity infrastructure in India capable of providing irrepudiable, immutable and verifiable age proof at scale, with face verification (without the need for OTPs or other complex biometric checks), while respecting data minimisation principles.
***
How to Implement DPDPA Parental Consent and Age Verification
A summary of the steps are given below. Please request for our full Whiate Paper to read the full integration details along with the edge cases and FAQs.
Step 1: Age Detection at Sign-Up (The App’s Responsibility)
The journey begins at account creation, before any personal data is processed.
What to build: Your sign-up form must include a Date of Birth (DOB) field as a required input. The moment a user submits their DOB, your backend performs a silent age calculation and invoke the Atlas Privacy Manager Parental Consent and Age Verification SDK (available on Android, iOS and Web):
- If the user is 18 or older: Invoke the Adult Verification Flow SDK (Aadhaar-based age verification for the user themselves)
- If the user is under 18: Invoke the Child Verification Flow SDK – a more complex, multi-party process that requires parental involvement – Note that two devices are usually involved in this process.
This calculation happens as an internal processing step within your app before any account is created. The user’s data must not be stored or processed for any purpose at this stage – the DOB is used only to determine which verification path to invoke.
Why this matters legally: Section 9(1) says consent must be obtained before processing. That means the verification architecture must precede data collection, not follow it. Your system must be designed so that no personal data is retained unless and until the appropriate verification and consent flow is completed successfully.
Step 2a: Adult Flow – Parental Consent and Age Verification using Aadhaar
For users who declare themselves 18 or older:
The user is redirected to the Aadhaar App on their mobile device. The Aadhaar App performs face verification and returns a Proof of Age token – a cryptographically verifiable assertion that the person is of a certain age range, without sharing the full Aadhaar number, DOB or any other personal data.
The Atlas Age Verification SDK shares this token with the calling App which receives this token, validates it, logs it and completes account creation. The user is onboarded. Please talk to us or refer to our SDK documentation to see how this step can be handled seamlessly between our SDK that verifies the user and your App that receives the verification token.
Data minimisation note: The DPDP Rules limit how much Aadhaar data you can store. As a Technology Service Provider (TSP) registered under the UIDAI’s OVSE (Online Virtual Identity Service for Entities) licensing framework, your platform should store only the verification result (age confirmed above 18: yes/no) and a hashed log of the transaction – not the full Aadhaar details.
Step 2b: Child Flow – The Multi-Party Verification Architecture
This is the technically complex path, and where most platforms will need to invest significant engineering effort. The child flow requires three parallel verifications:
- Parental Consent – legally obtained and logged
- Parent’s Age – the parent must themselves be verified as an adult
- Child’s Age – the child’s age must be verified as being under 18
- Relationship Verification – a defensible check that the consenting adult is actually the child’s parent or guardian
Here is the step-by-step flow using the Atlas Privacy Manager SDK:
Stage 1: Child’s Device – Age Verification Needed Screen
The Atlas SDK Architecture – What You’re Actually Integrating into your App for obtaining DPDPA Parental Consent and Age Verification
For most social media platforms, this verification flow will be implemented by integrating our Atlas Age Verification SDK. The SDK, integrated into your app’s sign-up flow, handles:
- Age gate logic – determining child vs. adult flow based on DOB
- QR code generation – unique, time-stamped, session-bound QR code for parental consent
- Privacy consent presentation – rendering the layered consent notice in compliance with DPDP Rules
- Consent logging – recording the consent decision as a structured, tamper-evident JSON/hashed log
- Aadhaar App deep linking – directing users to the correct Aadhaar verification screen
- Token validation – cryptographically verifying the Proof of Age tokens returned by the Aadhaar App
- Webhook dispatch – notifying your backend when verification is complete
- Anomaly flagging – detecting age inconsistencies, imposter attempts, and relationship mismatches
Your platform’s role is to integrate this SDK at the account creation step, configure it with your app’s branding and data disclosure requirements, and maintain the audit logs it generates.
The critical architecture principle: The SDK is designed in such a way that no personal data is persisted anywhere physically for the endure duration of the verification. The Name and DOB entered at sign-up is held in ephemeral memory, used only to determine which flow to invoke, and discarded if verification fails. Only upon successful verification does your backend receive the all-clear to create the account and store the user’s data along with the verification audit record.
***
Cricial Points to consider for DPDPA Parental Consent and Age Verification
You Cannot Rely on Retrospective Verification
Some platforms have considered a “trust first, verify later” approach — let children sign up and then verify retroactively. The DPDPA does not permit this. Section 9(1) requires consent to be obtained before personal data is processed. If you collect any data before verification is complete, you are already in violation. The architecture must enforce a hard gate: no data, no account, until verification is done.
Data Minimisation Is Non-Negotiable
Your SDK and backend should be designed to collect and retain only what is strictly necessary. For children’s accounts, the permitted data elements are those for which the parent has given specific consent. Any data element not explicitly consented to cannot be collected. And when the purpose for which data was collected is fulfilled, it must be erased — children have a “right to an open future,” as legal scholars note, meaning their digital footprint should not outlast their childhood.
Targeted Advertising and Behavioural Profiling Are Off the Table
If any part of your revenue model involves targeted advertising or behavioural profiling of users, you must ensure that these mechanisms are completely disabled for accounts identified as children. This requires a technical separation of child accounts in your ad targeting infrastructure — not merely a policy statement, but an enforced architectural boundary.
***
The Compliance Timeline – What to Do Between Now and May 2027
Q1 2026 (April – June 2026)
- Begin integration of the Atlas age verification SDK into your sign-up flow in a staging environment
- Draft your children’s privacy notice in the Atlas Privacy Manager Dashboard
- Build the backend logic for child account flagging, restricted mode, and ad targeting exclusion
Q2 2026 – Q4 2026 (July – December 2026)
- Begin phased rollout to production, starting with new user registrations
- Implement audit logging and verification record retention
- Train customer service teams to handle edge cases (children of guardians, children with disabilities, verification failures)
- Complete final compliance review with your audit team before the May 2027 deadline
***
Conclusion: Get full compliance ahead of the deadline
The DPDPA’s requirements for children’s data are among the most demanding data protection obligations India has ever imposed on digital businesses. They require genuine architectural changes, not surface-level policy updates. They require real identity verification, not self-declaration. They require enforceable parental consent, not a checkbox on a terms-of-service page.
But here’s the other side of that coin: platforms that get this right will be building something genuinely valuable – a trustworthy environment that parents can feel confident about, and that children can use safely. In a market where digital trust is increasingly scarce and regulatorily mandated, DPDPA compliance for children’s data is not just a legal obligation. It is a product differentiator.
The verification flow described in this guide – age detection, QR-based parental handoff, privacy consent, Aadhaar-based identity verification for both parent and child, relationship confirmation, and webhook-driven account activation – can all be implemneted today. The Aadhaar ecosystem, the UIDAI’s OVSE framework, and our Atlas Privacy Manager SDK all exist and are mature enough for production deployment.
13 May 2027 is not a suggestion. Start the integration today. Talk to us to get ahead.
This article is intended to provide general guidance on DPDPA compliance for digital platforms. Please request for a copy of our White Paper on DPDPA Parental Consent and Age Verification for full details on our SDK, Edge Cases, FAQs and more. Also book a demo to see the whole flow in action.
***
