Every NGO that touches a child's data, from an enrolment form for a nutrition programme, a health record at a mobile clinic, a beneficiary ID for a scholarship, a case file at a child protection shelter, has to answer a question the Digital Personal Data Protection Act, 2023 treats as non-negotiable: is the consent from a parent or a "legal" guardian and is that consent verifiable?
Section 9(1) of the DPDP Act says that before processing any personal data of a child, a data fiduciary must obtain the verifiable consent of the parent or lawful guardian. Rule 10 of the DPDP Rules, 2025 adds the operational detail: the fiduciary must adopt "appropriate technical and organisational measures" and exercise "due diligence" to confirm that the person identifying themselves as the parent is in fact an adult, identifiable if required by law. A child is anyone under 18 — a uniform, bright-line threshold, stricter than GDPR's 16 or COPPA's 13. Self-declaration ("I confirm I am the parent") does not meet the bar. Penalties for getting Section 9 wrong run up to ₹200 crore.
For a fintech or an e-commerce platform, this is a hard compliance problem. For an NGO, it's a hard compliance problem sitting directly on top of the population least equipped to clear the bar the law has set — and that combination is worth examining honestly, not just checking off.
The verification problem: proving the 'who'
Rule 10 gives data fiduciaries three routes to verify a parent: identity details the fiduciary already holds, identity details the parent voluntarily provides, or a "virtual token" issued by a regulated entity — in practice, this has coalesced around mobile OTP, Aadhaar-linked-mobile OTP, and DigiLocker-based identity checks. Each of these proves that someone controls a specific credential. None of them independently proves that this someone is the specific child's parent or legal guardian — there is no real-time government API a private data fiduciary can call to confirm a family relationship. What the law actually asks for is a defensible, traceable process — not courtroom-grade proof of parentage.
That gap matters more for NGO beneficiary populations than it does for a typical app's user base:
- Mobile ownership isn't universal, and it's sharply gendered. The National Statistical Office's 2025 Comprehensive Modular Survey on Telecom found that just over half of rural women aged 15+ don't own a mobile phone at all, against roughly one in five rural men. Many women who do have access use a phone registered to a male relative. In a health or nutrition programme where the mother is the primary point of contact, an OTP sent to "the parent's mobile" may in practice reach a husband, father-in-law, or brother and enot the person actually raising the child and best placed to weigh the consent decision.
- Aadhaar-mobile linkage decays. Aadhaar OTP verification depends on the mobile number on record with UIDAI still being active and in the parent's possession. Numbers get lost, SIMs get replaced, phones get shared or handed down — and in lower-income households this churn is higher, not lower. When Aadhaar OTP fails, fiduciaries fall back to weaker methods, which is exactly the outcome Section 9 is trying to avoid.
- "Parent or lawful guardian" is doing more work than it looks. NGOs routinely work with children who aren't living with a biological parent — kinship or foster care, children of migrant labourers left with grandparents, shelter-home residents, orphaned or abandoned children under an institutional guardian. Establishing lawful guardianship digitally is a materially harder problem than confirming a parent-child pair, and there's no consumer-facing verification rail built for it yet.
None of this is a reason to default to the weakest option. It's the reason "verifiable" has to be engineered as a layered, evidenced process rather than a single checkbox — and why NGOs, of all data fiduciaries, need to be honest about where their verification is strong and where it's a best-effort proxy.
The literacy and language problem: informed consent isn't solved once you've verified identity
DPDP consent has to be "free, specific, informed, unconditional, unambiguous, with a clear affirmative action." Verifying who clicked "agree" says nothing about whether they understood what they agreed to — and this is where the law itself acknowledges the gap. Guidance on the "best interests of the child" standard that data fiduciaries must apply explicitly lists inequalities in literacy of the parents as a factor to weigh, alongside age, disability, and social environment. That's a rare instance of a privacy law naming literacy as a legal design constraint, not just a UX nicety.
The scale of the gap is worth sitting with. Independent estimates put digitally literate households in rural India as low as a quarter to a third of the population; roughly two-thirds of women nationally are unable to send or receive an email. India also has 22 scheduled languages and hundreds of spoken dialects — a consent notice available only in English, or only in English and Hindi, is not meaningfully "clear and simple" to a parent in rural Odisha, a tribal belt in Chhattisgarh, or a migrant labour settlement, even if that parent is perfectly literate in their own language.
Put together, this means two separate failure modes can happen independently:
- Verification succeeds, comprehension fails. The right adult enters the right OTP, but never actually understood what "Health Records Processing" or "Customer Research & Surveys" meant, because the notice was in verbiage beyond the understanding of the data principal and also the concept of a "data processor" is not part of their frame of reference.
- Comprehension succeeds, verification fails. A field worker carefully explains the programme's data use in the parent's own language, the parent genuinely understands and agrees — but there's no auditable, traceable artefact proving that consent was captured from a verified adult, which is what Section 9 actually requires as evidence.
An NGO's consent architecture has to solve for both at once. Solving only the verification half produces technically compliant, ethically hollow consent. Solving only the comprehension half produces ethically sound, legally unverifiable consent. Either one, alone, leaves an NGO exposed.
Why this lands harder on NGOs than on most data fiduciaries
Four things compound here. First, NGO beneficiary bases overlap heavily with exactly the populations the digital-divide data describes — lower income, rural, lower female literacy, single or absent-parent households — which means the verification and comprehension gaps aren't edge cases for an NGO, they're closer to the median case. Second, the data categories NGOs typically process for children — health, nutrition, protection case history, disability status — sit in the same sensitive territory Section 9 was written to guard most tightly, so the cost of a consent failure isn't abstract; it's a vulnerable child's data moving without a defensible legal basis. Third, NGOs are usually the least resourced to build in-house identity verification infrastructure, which makes the self-declaration shortcut tempting precisely where the law is least forgiving of it. And finally, NGOs rely on donor funds for which they have to provide PII information in order to satisfy donor compliance. For this, consent verification is paramount.
There is no perfect solution — and the law doesn't pretend there is
It's worth saying plainly: no verification mechanism available today — to an NGO, a startup, or a large enterprise — proves parentage or guardianship with certainty. Aadhaar OTP proves control of a mobile number tied to an Aadhaar record. DigiLocker proves control of a government-issued digital identity. Neither cross-checks a family relationship against a civil registry, because that registry, in a form usable for real-time consent, doesn't exist for private data fiduciaries to query. What Rule 10 asks for is "appropriate technical and organisational measures" and "due diligence" — a defensible standard of care, evidenced and repeatable, not an unattainable guarantee.
That's the right way to frame any consent product in this space, including Flip's own: it demonstrates intent and due diligence, not infallibility.
What a good-faith, defensible consent flow looks like in practice
Bolt, the parental-consent module inside Flip, is a useful worked example of what "due diligence" can look like operationally, precisely because it doesn't try to claim more certainty than the underlying rails can support.
A few design choices worth calling out:
- Two verification paths, not one. The parent chooses between Mobile OTP and Aadhaar OTP based on what they actually have reliable access to — reflecting Rule 10's own menu of "identity details voluntarily provided" versus a "virtual token issued by a regulated entity," rather than forcing every household through a single rail that assumes universal Aadhaar-mobile linkage.
- A structured guardian record, not a free-text field. Full name, stated relationship (father, mother, legal guardian), mobile number, and last-four Aadhaar digits are captured as discrete fields before verification starts — creating the kind of traceable record regulators and auditors expect to see, rather than a single "I agree" event with no context behind it.
- Purpose-level granularity, split by necessity. The flow separates mandatory processing (order and account servicing, health records processing) from optional processing (research, service alerts) with independent toggles — so a parent isn't forced into an all-or-nothing decision, and the record shows exactly what was and wasn't consented to.
- A minor-specific carve-out, enforced by the product, not just the policy. The interface explicitly withholds optional tracking-adjacent purposes from minor accounts, with an inline note tying that restriction directly to Section 9(3)'s ban on behavioural monitoring and targeted advertising to children. That's the prohibition built into the consent surface itself, rather than left to a clause in a document nobody reads.
- The OTP as the binding act, tied explicitly to the listed purposes. The final consent step restates exactly which purposes the OTP entry authorises, so the "clear affirmative action" the law requires is anchored to specific, visible purposes at the moment of consent — not inferred from an earlier checkbox ticked several screens back.
This is a defensible architecture for the identity-and-audit-trail half of the problem. It is explicitly not a claim that Aadhaar OTP proves guardianship, and it's not a solution to the comprehension half on its own.
What technology alone doesn't solve — and what NGOs still have to build around it
Two gaps remain even with a well-built verification flow, and NGOs should plan for both rather than treat the technology as the whole answer:
- Assisted consent for beneficiaries without personal device access. Field staff and community health workers are often the practical bridge for a parent who doesn't have — or doesn't control — a personal mobile number. That means designing a workflow where a trained worker facilitates the OTP or Aadhaar verification step on a shared or programme-issued device, with the same purpose-level record and the same audit trail, rather than quietly reverting to a paper form with no traceable link back to the digital consent standard.
- Consent notices built for the literacy the law actually names as a factor. Plain-language text is a floor, not a ceiling. Read-aloud or voice-guided explanations in the parent's own language, delivered by a field worker or an in-app audio option, do more to satisfy "informed" consent for a low-literacy household than any amount of legal drafting simplification alone.
The honest takeaway
Section 9 sets one of the strictest bars in the DPDP Act deliberately — a ₹200-crore penalty ceiling, a bright-line 18-year threshold, no self-declaration, and prohibitions that apply even where consent exists. That severity is calibrated to who's exposed if it goes wrong. For NGOs, the populations most likely to trigger a genuine verification gap and the populations the law is built to protect are frequently the same people — which is exactly why "verifiable consent" can't be treated as a form field to fill in once and forget.
Getting this right doesn't mean waiting for a perfect verification technology that doesn't exist yet. It means building a layered, evidenced, purpose-specific process now — one that's honest about what it proves and what it doesn't — before a beneficiary programme scales to the point where retrofitting consent becomes far more expensive than designing for it from day one.