#MeitY Tells Parliament: 5.8 Lakh Common Service Centre Operators Are Not Data Fiduciaries Under the DPDP Act

The Ministry of Electronics and Information Technology has told Parliament that the Village Level Entrepreneurs who run India's 5.8 lakh Common Service Centres are not data fiduciaries under the DPDP Act, because they are not authorised to collect or store citizen data in the first place. On the same day, the Cabinet Secretary reportedly instructed every central ministry and state government that they are data fiduciaries and must comply in full.

Read those two positions together and you get the sharpest picture yet of how the Indian state is drawing its own accountability perimeter under the Digital Personal Data Protection Act, 2023 — and where that perimeter has a 5.8-lakh-node hole in it.

#What MeitY actually told Parliament

The question came from Karan Bhushan Singh, the BJP MP for Kaiserganj. He asked whether the Village Level Entrepreneurs (VLEs) operating more than 5.8 lakh Common Service Centres qualify as data fiduciaries under the DPDP Act. It is a good question, because a VLE is the person who physically sits across the desk from a citizen in rural India and helps them through an Aadhaar-linked transaction, a pension application, a bank account opening, or a health record lookup.

The government's answer, as reported by Tech Observer, was no. MeitY's position is that CSC e-Governance Services India Limited — the MeitY special purpose vehicle that runs the network — provides assisted access to digital services through VLEs, and that a VLE "is not authorised to collect or store citizens' data while providing such services." VLEs help citizens understand and reach government services. They do not, on the government's telling, retain Aadhaar numbers, banking credentials, or health records.

MeitY also pointed to the grievance channels available to citizens who believe something went wrong at a CSC counter: the CSC helpdesk on 14599, the Digital Seva Portal, and state or district CSC networks. And it reiterated the statutory backdrop — that under the DPDP Rules, 2025, notices to data principals must be available in all 22 scheduled Indian languages.

The same set of replies reaffirmed the compliance runway: core DPDP obligations bite on 13 May 2027, eighteen months from the notification of the Rules, with the consent manager registration window opening on 13 November 2026.

#The other half of the story: the state declares itself in scope

The reason this parliamentary answer matters more than a routine clarification is what landed alongside it. On 27 August, the Cabinet Secretary issued instructions to all central ministries and state governments requiring full adherence to the DPDP Act, on the explicit basis that government entities are data fiduciaries under Section 8 and carry the same obligations as any private company.

That is a genuinely significant signal. A recurring criticism of the DPDP Act — from the Internet Freedom Foundation and others — has been that the state gave itself broad exemptions under Section 17 while imposing hard obligations on everyone else. A directive routed through the Cabinet Secretariat, which is the one office that can actually move Chief Secretaries, says the opposite at the operational level: departments must build notice, consent, security, breach reporting and grievance machinery like everybody else.

So the state has, in a single news cycle, said two things. Ministries and states: in scope, no argument. The 5.8 lakh humans staffing the last mile of digital India: not data fiduciaries, because they were never supposed to be holding the data.

#Why "not a data fiduciary" is not the same as "not exposed"

Here is where businesses running any kind of assisted-access model need to pay attention, because MeitY's answer is legally coherent and operationally incomplete at the same time.

Under the DPDP Act, a data fiduciary is whoever determines the purpose and means of processing — the rough equivalent of a controller under the GDPR. A data processor processes on the fiduciary's behalf. The critical structural choice India made is that the DPDP Act imposes no direct statutory obligations on processors. Under the GDPR, a processor has its own duties and can be fined directly by a supervisory authority. Under the DPDP Act, it cannot. All statutory liability sits with the fiduciary.

Section 8(1) is unusually blunt about this. The data fiduciary is responsible for compliance "irrespective of any agreement to the contrary." You can outsource the work; you cannot outsource the liability. If a processor or an agent in your delivery chain mishandles personal data, the penalty — up to ₹250 crore — lands on you.

Apply that to the CSC network and the logic runs cleanly. If VLEs are not fiduciaries, and are not authorised to hold data, then accountability for what happens at that counter flows upward: to CSC e-Governance Services India Limited, and to the department or bank or insurer whose service is being delivered. The citizen is not left without a duty-holder. That is the answer MeitY gave, and on the statute it holds up.

The problem is that "not authorised to store data" is a description of a rule, not a description of a system.

#The gap between the authorisation and the counter

The CSC network is not a hypothetical. It has a documented history of exactly the failure mode this classification assumes away.

In 2018, UIDAI documented what it called an enormous volume of complaints about corruption and procedural violations across 11,280 CSC Aadhaar enrolment centres — and responded by refusing to renew its agreement and ordering a phased shutdown, restricting future enrolment to government premises, banks and post offices. In 2022, a Uttar Pradesh investigation found a customer service agent cloning Aadhaar fingerprints with butter paper and rubber to defeat biometric authentication. Cyble has documented fraud rings impersonating VLEs to dupe rural subscribers signing up for Bank Mitra services. And in April 2026, an Ahmedabad cyber-fraud case that led to four arrests reportedly involved a CSC operator, coordinated access to enrolment and verification systems to swap Aadhaar-linked mobile numbers, and AI-generated synthetic media used to clear verification — ending in an e-KYC bank account and a loan drawn in the victim's name.

None of that requires a VLE to be a data fiduciary. It requires a VLE to have transient access to a citizen's most sensitive identifiers at the moment of a transaction — which is the entire premise of assisted access.

So the honest reading of MeitY's answer is this: the classification is correct, and it does nothing to reduce the risk. It relocates the risk. The exposure now sits with the fiduciaries in the chain — CSC SPV, the banks running Aadhaar-enabled Payment System touchpoints, the insurers, the state departments — and every one of them is on the hook under Section 8(1) for the conduct of an agent they do not employ, do not directly supervise, and in many cases cannot technically monitor at the point of interaction.

That is a substantially harder compliance problem than "make sure your VLEs aren't storing anything."

#What this means for Indian businesses

If your business model touches a human intermediary who handles someone else's personal data on your behalf, this parliamentary answer is a preview of how the regulator is likely to think.

Assume you are the fiduciary, and act like it. Banking correspondents, insurance agents, kiosk operators, field agents, franchise onboarding staff, third-party KYC vendors, telecom retailers doing SIM activation — the same reasoning applies. They are not fiduciaries. You are. Section 8(1) means a contractual clause pushing responsibility down the chain protects your commercial position and nothing else.

Make "no retention" a technical property, not a policy line. The distance between a policy that says a VLE may not store data and an architecture that makes storage impossible is where the ₹250 crore lives. Practical controls: no local caching of identifiers, no writable client-side storage on the operator's terminal, tokenised or virtual identifiers instead of raw Aadhaar numbers, screen-level masking, session-scoped credentials, and audit logging that ties every access to a specific operator and transaction.

Instrument the last mile. If you cannot answer "which operator accessed which data principal's record, when, and under what purpose," you cannot meet a breach-notification obligation on the 72-hour clock the DPDP Rules set, and you cannot service a data principal's access or erasure request that touches an assisted transaction.

Do not read soft enforcement as no enforcement. 2026 is widely described as the build-and-test year, with the Data Protection Board still standing itself up and full enforcement powers arriving in May 2027. But the consent manager registration window opens on 13 November 2026, and Significant Data Fiduciaries need audit cycles, independent data auditors and Data Protection Impact Assessments operating by early 2027. Systems that touch millions of rural transactions are not rebuilt in a quarter.

#The comparison worth making

Under the GDPR, a processor mishandling data faces its own regulator and its own fine. That creates a second, independent line of defence: the processor has a direct incentive to refuse an unlawful instruction, because it bears its own risk.

India deliberately chose not to build that second line. The DPDP Act concentrates everything on the fiduciary. In a network of a handful of large, well-capitalised processors, that is a defensible simplification — it gives the Data Protection Board one clear defendant. In a network of 5.8 lakh individually operated village kiosks, it means the entity holding the liability is the furthest removed from the risk, and the person closest to the risk holds none of it.

That is not an argument that MeitY answered the question wrongly. It is an argument that the answer exposes a design tension the DPDP Act has not yet had to resolve — and that when the first serious enforcement action involving an assisted-access channel reaches the Board, the reasoning in this parliamentary reply will be the first thing everybody reads.

#What to do this quarter

Map every point in your data flows where a human intermediary you do not directly employ touches personal data. For each one, write down who the fiduciary is, what that intermediary is technically capable of retaining (not what your contract says they may retain), and how you would evidence the difference to a regulator. If the technical answer and the contractual answer diverge anywhere, that gap is your DPDP exposure, and it is measured in crores.

Our resources library has the working checklists for Section 8 obligations, processor oversight and breach readiness. If you are scoping how consent will actually be captured, stored and withdrawn across assisted and digital channels before the November registration window, start with the consent manager guidance — the architecture decisions you make there are the ones that determine whether your last mile is defensible in May 2027.

---

Sources: Tech Observer — CSC operators cannot store Aadhaar data under DPDP Act: MeitY · Tech Observer — DPDP compliance deadline set for May 2027 · DPDP News daily brief, 27 August 2026 · Consent.in — Data Processors Under the DPDP Act · Cyble — Fraudsters posing as VLEs · India Briefing — DPDP compliance timeline 2026–27 · MeitY