The DPDP Act for the Social Sector: A Plain-English Guide to Beneficiary Data, Consent, and Donor Reporting

The Digital Personal Data Protection Act, 2023 (the DPDP Act) applies squarely to the social sector. The moment an NGO or a CSR funder collects a beneficiary's Aadhaar number, PAN, or phone number in digital form, it becomes a "Data Fiduciary" carrying enforceable legal obligations, and the beneficiary becomes a "Data Principal" with rights that can be exercised against it. Understanding the DPDP Act for the social sector starts with that single shift in status.

This is not a distant compliance problem. The Act was passed in 2023, and the Digital Personal Data Protection Rules, 2025 were notified on 14 November 2025, with substantive obligations phased in over an approximately 18-month runway that runs to around mid-May 2027. The Consent Manager registration route opens earlier, around November 2026. In our work across the social sector, we consistently find that understanding of what the Act actually requires remains shallow on both sides of the funding relationship, among corporate donors and among the NGOs that implement on the ground. The Act is not especially complicated. It simply has not yet been read carefully by the people it now governs.

This guide sets out what the DPDP Act means for the social sector in practice: how it treats beneficiary data, what corporates doing CSR need to know, what NGOs must change about how they collect and store data, how the new "Consent Manager" role is meant to work, and the questions the Act has not yet answered.

What is the DPDP Act, and why does it reach the social sector?

The DPDP Act governs the processing of digital personal data, meaning personal data about an identifiable individual that is collected in digital form, or collected offline and later digitised. A beneficiary's name, Aadhaar number, PAN, and phone number all qualify. Five features define the Act in plain terms:

• It covers digital data only. Data collected digitally, or collected on paper and then digitised, is in scope; purely physical records that are never digitised sit outside it.
• It reaches beyond India's borders. Under Section 3 of the DPDP Act, 2023, it applies to processing within India and, extraterritorially, to processing abroad that connects to offering goods or services to individuals in India. It excludes purely personal or domestic processing, and data an individual has made public themselves.
• It has no sensitive data category. Unlike some regimes, the Act gives Aadhaar and PAN the same statutory treatment as any other personal data. Their extra protections come from other laws, not this one.
• It balances two objectives. The Act recognises an individual's right to protect their personal data while acknowledging the need to process data for lawful purposes.
• It is enforced by a Board, with financial penalties. The Data Protection Board of India investigates breaches and imposes penalties that are financial only, with no criminal liability. The ceiling for failing to take reasonable security safeguards is ₹250 crore under the Schedule to the Act.

Who are the five parties under the DPDP Act, and which one are you?

The Act defines five roles. Knowing which one you occupy is the single most useful thing a social-sector organisation can do, because your obligations follow directly from your role.

The Data Fiduciary is the primary duty-bearer under the Act, and it is where almost the entire compliance load sits. The beneficiary, as Data Principal, holds rights under Sections 11 to 14: to access information about how their data has been processed, to have it corrected or erased, to grievance redressal, and to nominate someone to act for them.

A beneficiary group is not a legal unit under the Act. The DPDP Act operates individual by individual, so notice and consent attach to each person, not to a village, a cohort, or a self-help group collectively.

What does the DPDP Act mean for corporates doing CSR and philanthropy?

For corporates, the exposure is easy to miss, because most CSR teams do not think of themselves as handling beneficiary data at all. They fund; the NGO collects. But the CSR compliance framework itself pushes beneficiary data toward the funder.

Under Section 135 of the Companies Act, 2013, CSR obligations are triggered for a company with net worth of ₹500 crore or more, turnover of ₹1,000 crore or more, or net profit of ₹5 crore or more in the preceding financial year, and the company must spend at least 2% of its average net profits of the three preceding financial years. Where a company's average CSR obligation is ₹10 crore or more, Rule 8(3) of the Companies (CSR Policy) Amendment Rules, 2021 mandates an independent impact assessment for projects with outlays of ₹1 crore or more. Impact assessment means field research, and field research means collecting outcome data about identifiable beneficiaries.

So the question for a CSR funder is not whether beneficiary data exists, but whether it flows to the company, and on what basis. Here the crucial point is one that most funders miss: when a donor receives beneficiary data and uses it for its own purposes, the donor becomes its own Data Fiduciary, not a mere processor of the NGO's data. It then carries its own obligations under the Act, and the NGO's act of disclosing the data needs its own lawful basis.

In practice we see two opposite funder behaviours:

• Identity-blind funders. Some corporates, better read on the Act, instruct explicitly that no beneficiary identity is to be revealed in any report.
• Beneficiary-level funders. Others ask for individual-level data for genuine analytical reasons, such as tracking whether a specific child's learning level improved across an education programme, or whether awareness and treatment changed a particular person's non-communicable-disease outcome in a health programme.

Both instincts are legitimate. The Act does not forbid the second; it constrains how it is done.

Three disciplines keep a funder on the right side of the Act:

1. Default to aggregated or de-identified reporting. Section 6 of the DPDP Act limits consent to only the personal data necessary for the stated purpose. Data that no longer identifies an individual falls outside the Act's scope entirely, so reporting aggregated outcomes carries no exposure. For most impact and financial reporting, this is all a funder needs.
2. Where identified data must flow, name it in the consent. If beneficiary-level tracking is genuinely required, the beneficiary's notice and consent must have named donor-sharing as a purpose from the outset. Consent taken for programme delivery cannot be silently stretched to cover funder reporting.
3. Mind the border for foreign and holding-company funders. Cross-border transfer is permitted by default under Section 16 of the Act, but the Central Government may restrict transfers to specified countries through notification. It is the one provision an overseas funder should keep under watch.

The same logic applies to UHNI and foundation philanthropy. The moment a philanthropic vehicle collects or holds identifiable beneficiary data to make its own decisions, it is a Data Fiduciary, with the full set of obligations that follow.

What must an NGO do when it collects beneficiary data?

The implementing NGO is almost always the primary Data Fiduciary. It decides why the data is collected and how, so it carries the notice, consent, security, and erasure duties in full. This is where the largest gap between law and practice currently sits.

Five obligations sit on the NGO as Data Fiduciary:

• Give a proper notice. Rule 3 of the DPDP Rules, 2025 requires the notice to be standalone and in clear, plain language. It must itemise the data collected, state the specific purpose, and give a means to withdraw consent, exercise rights, and complain to the Board. Under Section 5 of the Act, the beneficiary may receive it in English or any Eighth Schedule language, which for most rural contexts means the local language.
• Meet the consent standard. Section 6 requires consent to be free, specific, informed, unconditional, unambiguous, and given by clear affirmative action, limited to the data necessary, and as easy to withdraw as to give. That rules out pre-ticked boxes, bundled agree-to-everything forms, and collecting Aadhaar without a stated purpose.
• Limit the purpose and delete when done. Under Section 8, data cannot be repurposed beyond the consented purpose, and must be erased once the purpose is served or consent is withdrawn, unless a law requires retention.
• Handle children with a higher bar. Section 9 requires verifiable parental or guardian consent before processing the data of anyone under 18, and prohibits tracking, behavioural monitoring, or targeted advertising directed at children. For programmes with minors, the collection flow itself must capture this.
• Remember that vendors do not absorb your liability. A cloud CRM, survey platform, or verification agency is a Data Processor acting on your instruction under a valid contract. Under Section 8, accountability stays with you as Fiduciary, so beneficiaries' Aadhaar numbers in a third-party database remain your legal responsibility.

Against this standard, the common field reality is thin. In our assessment and monitoring work, we consistently observe NGOs collecting identifiers and obtaining consent either verbally or through a one-way printed sheet that the beneficiary signs. That sheet records that consent happened. It rarely reflects the parts of the law that actually protect the beneficiary. Two gaps recur almost everywhere: hardly any implementing organisation tells beneficiaries how to withdraw consent later, and almost none build a mechanism to delete beneficiary data once a project closes. Both are explicit requirements of the Act, and both are routinely absent.

For an NGO starting from where most are today, a practical near-term checklist looks like this:

• Rewrite the consent notice to meet Rule 3: standalone, plain-language, itemised data fields, specific purpose, in the beneficiary's language.
• Make consent purpose-specific and unbundled, and stop collecting identifiers you cannot tie to a stated purpose.
• Build and communicate a withdrawal channel, so a beneficiary can withdraw as easily as they consented.
• Set a retention-and-deletion schedule, and assign someone to delete data when a project closes.
• Capture separate verifiable parental consent wherever beneficiaries are under 18.
• Put a written data-processing contract in place with every vendor that touches the data.
• Keep a timestamped, versioned consent log you could produce if the Board ever asks.

Does the DPDP Act apply to data collected on paper?

This is the question practitioners ask most, and the answer has a catch. The Act governs digital personal data, defined as data collected in digital form or collected offline and later digitised. A paper form that is filled in, filed in a cabinet, and never entered into any system sits outside the Act's scope.

The catch is that this exemption is far narrower than it first appears. The moment a paper form is keyed into an Excel sheet, an MIS, a CRM, or a survey app, which is what happens to almost all beneficiary data in a modern programme, it has been digitised, and the Act applies in full. Treating "we collect on paper" as a compliance shield is therefore unsafe. In any programme with digital monitoring or reporting, the beneficiary data is digital data.

Do beneficiary photographs and videos count as personal data?

Yes. The Act defines personal data as any data about an identifiable individual, and a photograph or video that identifies a beneficiary is exactly that. This matters because images are the most common form of beneficiary data in the social sector, appearing in impact reports, annual reports, donor decks, and social media, often with no consent trail at all.

The practical implications are the same as for any other personal data:

• Consent must name the use. If a beneficiary's photograph will appear in a report or on social media, the consent and notice should say so specifically, including the channels where it may be published.
• Minimise and prefer non-identifying imagery. Where the story does not require an identifiable face, non-identifying or aggregate imagery avoids the exposure entirely.
• Children need the higher bar. Under Section 9, images of beneficiaries under 18 require verifiable parental or guardian consent, and the prohibition on tracking and targeting applies.

What is a Consent Manager, and how does it actually work?

A Consent Manager is a Board-registered intermediary through which a beneficiary can give, review, manage, and withdraw consent across multiple Data Fiduciaries from a single account. Three features define it:

• A single point of control. The beneficiary manages consent for many organisations from one accessible account, instead of dealing with each separately.
• Consent-driven, not data-holding. It moves nothing without the individual's explicit, revocable instruction.
• Accountable to the individual. Its duty runs to the Data Principal, not to the Fiduciary.

Under Rule 4 of the DPDP Rules, 2025, a person becomes a Consent Manager only by applying to and being registered by the Data Protection Board, after satisfying the conditions in Part A of the First Schedule. Registration by the Board is the gate; an organisation cannot simply declare itself a Consent Manager.

Here is the reality that matters for planning today: the Rules' own commencement schedule brings Rule 4 into force one year after publication, around 13 November 2026. As of now, no Consent Managers are registered, and no official list has been published. The role has been created in law but the registration window has not yet opened.

What consent tooling can social-sector organisations use today?

Because the word "consent manager" is used loosely in the market, it helps to separate three quite different things.

The practical takeaway is that there is no statutory Consent Manager an organisation can plug into today. An NGO or funder that wants tooling now would adopt a CMP and run its own consent-and-record process as a Data Fiduciary.

Rather than endorse specific vendors, we suggest evaluating any consent tool against criteria drawn directly from the Act's requirements for beneficiary data.

The gray areas the DPDP Act has not settled yet

An honest reading of the Act has to acknowledge where it is silent or untested. These are not settled positions; they are questions we expect to gain clarity on as the Board begins to function and practice develops. We flag them because social-sector organisations are already running into them.

• State-linked delivery versus consent. Section 7 permits processing for certain legitimate uses, including the State's provision of benefits, subsidies, or services. Whether a privately funded NGO delivering a State-linked scheme can rely on this ground, or must default to consent, is not yet clearly drawn. The safer course today is to default to consent.
• Verifiable parental consent in the field. Section 9 requires verifiable guardian consent for minors, but in low-literacy or no-document contexts, what counts as verifiable is unresolved, and will likely be shaped by Board practice over time.
• Erasure versus longitudinal impact measurement. Section 8(7) requires erasure once the purpose is served, yet credible impact assessment often depends on tracking the same beneficiary across years. How long identified data may be retained for legitimate longitudinal measurement is a live tension for anyone doing serious evaluation.
• The anonymisation threshold. The Act stops applying once data no longer relates to an identifiable individual, but there is no bright-line test for how thoroughly data must be de-identified to cross that line. In small samples, aggregation alone may not be enough.
• Account Aggregators and Consent Managers. How the RBI's operational Account Aggregator framework will reconcile with the DPDP Consent Manager regime, once Rule 4 is live, is under active discussion, with some overlap and some tension.

None of these unknowns is a reason to wait. The core obligations, proper notice, specific consent, minimisation, security, and deletion, are clear enough to act on now.

FAQs