Branches, agents and field staff enter personal data on someone else's behalf every day in India. A signed paper form does not satisfy the DPDPA — here is what does.
June 2026 · 6 min read
Most consent infrastructure is built for a self-service world: a person visits a website, sees a notice, and clicks agree themselves. That model covers digital-native interactions reasonably well. It does not cover how a large share of personal data actually enters enterprise systems across India.
Bank branches. Insurance agents. Telecom retailers. Healthcare intermediaries. Distribution networks. Across every one of these channels, a human agent collects personal data on someone else's behalf, entering it into a system that the person it belongs to may never directly interact with at all.
Section 6 requires that consent come from the Data Principal — freely, specifically, with full information, and through an unambiguous affirmative action. Section 5 requires that notice be delivered before or at the moment of collection.
In an agent-mediated scenario, "at the moment of collection" is the moment the agent fills in the form. The Data Principal, in that moment, may never have seen a proper digital notice, never have given digital consent, and never have interacted with the fiduciary's consent systems at all. A signed paper form does not satisfy the DPDPA's requirement for a verifiable, digital consent record — signing a form is not the same as consenting through an unambiguous affirmative action captured against that specific person.
Which leaves the Data Fiduciary holding personal data, carrying an obligation to demonstrate valid consent for it, and having no digital consent record for a meaningful share of its user base.
The scale of this in India is not small. Financial services, insurance and telecom process enormous volumes of data through exactly these agent networks, and for many large enterprises, a majority of customer data originally entered the system through an intermediary rather than directly. Without a way to capture verifiable digital consent for these records, the entire legacy consent posture is sitting on shaky ground.
The fix that holds up under scrutiny is a consent-link mechanism, and it works in four steps.
Step 1 — the agent enters the data, and a link gets generated. Instead of the agent recording blanket consent on the Data Principal's behalf, the system generates a unique, OTP-protected link tied specifically to that person and that data record.
Step 2 — the link goes to the Data Principal, not the agent. It is sent by SMS or email, is time-limited — no more than 24 hours — and is single-use. It cannot be forwarded on or used by anyone other than the intended recipient.
Step 3 — the Data Principal reviews and consents on their own, without the agent present. They open the link on their own device and see the same notice they would have seen through a normal digital interaction — purpose-specific, in their preferred language, with a clear option to decline anything not strictly necessary. The decision is theirs alone.
Step 4 — a genuine consent record gets created, attributed to the Data Principal. With OTP verification and a timestamp, this is a verifiable digital consent record that actually satisfies the DPDPA — even though the original data entry itself was mediated by someone else.
The same mechanism works retroactively. If you have existing records predating the DPDPA compliance deadline — customer data originally captured through agents or paper forms — you can generate consent links for those individuals and run a systematic refresh campaign against your entire legacy base.
The alternative — simply asserting that legacy records are validly consented, with no verifiable digital record behind them — is not a position that will survive scrutiny from the Data Protection Board once enforcement begins.
The principle underneath all of this is straightforward: consent has to come from the Data Principal, not on their behalf. An agent can trigger the process, but they cannot complete it for someone else. The Data Principal is the one who acts, in the final step, always.
This shows up constantly in BFSI, where branch and field-agent-assisted data entry is routine — our consent architecture design service covers assisted-consent scenarios like this directly.
30 minutes to talk through your specific data footprint — no obligation.
Book a Consultation