Consent & Data Retention Under DPDP: A Practical Checklist

Disclaimer: This article is educational and does not constitute legal advice. Consult a qualified legal professional for advice specific to your organisation.

Our earlier post, DPDP Act 2023 for Field Researchers, covers the Act end to end — Data Fiduciary obligations, Data Principal rights, penalty tiers, and a 30-day compliance checklist. If you haven't read it, start there; it's the foundation this post builds on.

This post goes deeper on two mechanics that post only summarised, because they are where most organisations actually get stuck: designing a consent screen that holds up to scrutiny, and building a retention schedule that survives both a DPDP audit and a funder's grant closeout review. Both sound simple in principle and turn out to be full of operational detail once you try to implement them across a real field team.

Designing a Consent Screen That Actually Holds Up

A consent checkbox is not consent under DPDP. The Act defines valid consent as free, specific, informed, unconditional, and unambiguous — with a clear affirmative action attached to each purpose. In practice, that means four design decisions, each of which has real operational consequences for a field team.

1. Language and localisation

Consent captured in a language the respondent doesn't read fluently is not informed consent — full stop. If your enumeration is happening in rural Bihar, a consent screen in English satisfies nobody except a lawyer reviewing the form afterward. Build the consent screen in every language your field team enumerates in, not just the languages your head office uses for reporting.

Two practical notes from real deployments: first, back-translate your consent text (translate to the local language, then have a different person translate it back to English) before you go to field — direct machine translation of legal-sounding phrases like "processing" or "data fiduciary" often produces nonsense in regional languages. Second, for respondents who are not literate, the enumerator must read the consent notice aloud and record an audio or verbal-consent marker rather than relying on a screen the respondent cannot read themselves. FieldGovern's Form Builder supports AI-assisted translation into Hindi, Kannada, Telugu, and other Indian languages specifically so consent text doesn't get left in English by default.

2. Granularity per purpose

"I consent to this study" is a single blanket permission and, per the Act's specificity requirement, is too broad the moment your study does more than one thing with the data. A baseline-endline evaluation that also shares anonymised data with a funder for their own reporting is two purposes, not one. A health survey that also flags severe cases for referral to a partner clinic is two purposes.

The fix is to break consent into distinct, separately affirmed questions — one per purpose — rather than one omnibus checkbox:

• Consent to participate and answer survey questions
• Consent to share de-identified responses with the funder/donor for reporting
• Consent to be re-contacted for a future follow-up wave
• Consent to referral (where the survey identifies a need — e.g., a malnourished child, a case of gender-based violence) to a named third-party service

A respondent may say yes to the first and no to the third. Your form logic needs to handle that gracefully — recording the response but suppressing the recontact-eligible flag rather than treating a partial "no" as a reason to discard the whole record.

3. Timestamp and consent ID capture

Consent that isn't independently verifiable is difficult to defend in a Data Protection Board inquiry. Two fields should be captured automatically — never entered manually by the enumerator, since manual entry is trivially falsifiable:

• Consent timestamp — the exact device time the consent question was answered, captured by the app, not typed in.
• Consent ID — a unique identifier generated at the moment of consent, stored in a record that is separate from (but linkable to) the respondent's substantive answers. This is what lets you prove, later, that a specific person consented to a specific version of a specific purpose statement on a specific date — which matters enormously if your consent language changes mid-study.

If your survey tool doesn't generate these automatically, you are relying on enumerators to remember to fill in a timestamp field by hand in the field — which does not happen reliably at scale, and which an auditor will notice immediately.

4. A clear withdrawal mechanism — and what happens operationally when someone withdraws

The Act requires that withdrawing consent be as easy as giving it. In practice this means publishing a specific, low-friction channel: a phone number or SMS shortcode the respondent can use, printed on a leave-behind card, or a request routed through the field supervisor. "Contact our office" is not specific enough to count as easy.

The part most study designs skip is what happens operationally once a withdrawal request actually arrives mid-study. This needs to be a documented procedure, not an improvised decision made by whoever answers the phone:

1. Log the request — date, respondent (via consent ID, not name, where possible), and channel it came through.
2. Stop active processing — flag the respondent's record so it is excluded from any in-progress analysis, dashboard, or export going forward.
3. Decide what "withdrawal" means for existing data. Under DPDP, withdrawal is prospective — it doesn't automatically erase data already lawfully processed, but the respondent can separately request erasure, and many organisations choose to treat the two requests as bundled by default for a cleaner respondent experience.
4. Erase or de-identify the record within your committed response window (document this window in your Privacy Notice — 30 days is a common, defensible choice).
5. Document the closure — confirm to the respondent (where contact is possible) that the request was actioned, and log the closure date for audit purposes.
6. Account for it in analysis. If the study is mid-fieldwork, note the attrition in your data quality log so a withdrawn respondent doesn't silently show up as a "non-response" with an unclear cause when someone reviews the dataset six months later.

This is exactly the kind of scenario that panel studies need to plan for at design stage, not discover mid-fieldwork — see our panel study guide for how attrition and re-contact interact with consent withdrawal across multiple waves.

Building a Real Data Retention Schedule

Data minimisation under DPDP doesn't only govern what you collect — it also governs how long you keep it. "We'll just keep everything forever, it might be useful" is no longer a neutral default; it is itself a compliance risk, because retaining personal data beyond the purpose for which it was collected is a violation even if nothing is ever misused.

Raw PII vs. anonymised aggregate data

The single most useful design decision most field research teams can make is to separate, structurally, two categories of data that are often stored together in one flat spreadsheet:

• Raw personal data — respondent name, phone number, exact GPS coordinates, photographs, household ID linked to identity. This is what DPDP regulates directly, and what carries retention risk.
• Anonymised or aggregated data — response values with all direct and indirect identifiers stripped or generalised (e.g., GPS rounded to block/village level, age bucketed into ranges), such that re-identification is not reasonably possible. Once genuinely anonymised, this data falls outside DPDP's scope.

The practical implication: retain raw PII for the shortest period that is operationally necessary, then either delete it or irreversibly anonymise it — while the anonymised aggregate can be retained far longer for research, audit, and donor reporting purposes without the same regulatory exposure. Treating these as one undifferentiated dataset with one retention rule is how organisations end up either deleting data a funder needs, or keeping PII years longer than the Act allows.

The tension: DPDP minimisation vs. funder audit retention

This is the part that catches most NGOs and research units off guard: DPDP pushes you toward deletion, but your grant agreement may require retention. Many donor and government grant agreements specify a minimum audit-retention period — commonly 3 to 7 years after project closure — during which records, including underlying data, must be available for audit. CSR-funded programmes in particular often carry contractual retention clauses that predate DPDP and were never written with a data-minimisation law in mind.

Resolving this tension is not a matter of picking one rule over the other — it's a matter of applying the right rule to the right layer of data:

• The funder's audit retention clause almost always concerns evidence that the work was done and the numbers are real — it is satisfied by anonymised aggregate data, response counts, and audit trails, not by keeping respondents' names and phone numbers on file for seven years.
• The DPDP minimisation obligation applies specifically to personal data — so raw PII gets the short retention window, anonymised data gets the long one.

State this split explicitly in your data management plan and, ideally, in your funder agreement itself, so there's no ambiguity six years later about whether "keep the data" meant the spreadsheet with names in it or the anonymised dataset.

Step-by-Step: Building a Retention Policy

None of this needs to be manual busywork forever. A survey platform that separates raw response storage from your reporting layer, timestamps consent automatically, and keeps a structured audit trail of who accessed or changed what makes both halves of this — the consent design and the retention schedule — dramatically easier to actually operate day to day, rather than just document on paper. See our companion post on why your M&E tool needs an audit trail for how the audit-log layer of this fits together with donor compliance specifically.