Indian industry runs on a contingent workforce, security guards on month-on-month manpower contracts, housekeeping staff rotated across sites, IT consultants embedded on client premises, and factory floors staffed predominantly by contract labour. That contingent-labour framework itself changed shape on November 21, 2025, when the four Labour Codes came into force and the erstwhile Contract Labour (Regulation and Abolition) Act, 1970 was repealed and subsumed into the Occupational Safety, Health and Working Conditions Code, 2020 (“OSH Code”). The Digital Personal Data Protection Act, 2023 (“DPDPA” or “Act”), does not contain a single provision addressing this triangular relationship. That silence is the problem this article hopes to address.
Section 2(i) DPDPA defines a Data Fiduciary as any person who, “alone or in conjunction with other persons, determines the purpose and means of processing.” This is structurally close to Article 4(7) GDPR’s “controller” test, but the DPDPA deliberately drops GDPR’s separately codified “joint controller” regime (Article 26). That omission is significant and frequently misread by Indian compliance teams importing GDPR vocabulary wholesale.
To take this analysis forward, let us evaluate who really is “determining the purpose and means of processing”. The manpower agency/contractor determines purpose and means for payroll, statutory compliance (PF/ESI), and deployment records. On these processing activities, it is unambiguously the Data Fiduciary. The principal employer (i.e. factory/client) independently determines purpose and means for site access control, CCTV surveillance, biometric attendance at its own turnstiles, safety training records, and incident investigations. On these activities, the principal employer is a Data Fiduciary in its own right as it is genuinely deciding why and how that data is processed, for its own regulatory and safety obligations.
The DPDPA’s “in conjunction with” language permits an inference of joint-fiduciary-like status without adopting GDPR’s formal apportionment jurisprudence. Where both entities co-decide, for instance, a jointly configured biometric attendance system feeding both the contractor’s payroll and the factory’s safety compliance, each is independently accountable for the purposes it controls, and neither can point to the other to escape liability under Section 8. There is no equivalent in the DPDPA to GDPR’s requirement of an “arrangement” allocating joint-controller responsibilities transparently to the data subject, but adopting that discipline voluntarily is the more defensible course, given the Data Protection Board’s evident enforcement orientation toward accountability documentation.
It is also equally critical to note that a “Data Fiduciary–Data Processor” relationship arises only where one entity processes “on behalf of” the other, with no independent purpose of its own. For example, where the contractor merely administers the principal employer’s visitor-management system using parameters, retention periods and access controls entirely determined by the principal employer, the contractor is more likely to be acting as a Data Processor. However, this is an exception for labour-supply arrangements. Most manpower contracts involve genuine dual decision-making, not pure processor status.
A question that often comes up is whether such processing can somehow fall under Section 7(i), i.e. DPDPA’s “employment” legitimate use. This section permits processing “necessary for” purposes relating to employment, without consent, including safeguarding the employer from loss or liability, provisioning of benefits, and recruitment. A textual reading limits this to the employer, i.e. the contractor, who is the worker’s actual employer of record. Whether the principal employer/factory can invoke Section 7(i) for its own attendance, safety and CCTV processing is not expressly settled by the Act.
While the DPDPA has no GDPR Article 6(1)(c)-style general “compliance with legal obligation” ground, a more defensible approach may be for the factory or client to rely on Section 7(e) (legitimate use for compliance with law/court order like OSH Code safety registers) or a residual (and perhaps farfetched) reading of “employment” purpose extended functionally to workers under its operational control, rather than stretching Section 7(i) to non-employees. Where neither legitimate use fits cleanly (like discretionary CCTV retention beyond safety necessity), consent should be sought. The practical alternative, consistent with European Data Protection Board’s guidance on employment contexts, is to minimise reliance on consent for anything the worker cannot realistically refuse, and to anchor collection instead in the narrowest applicable legitimate use or statutory obligation.
But then, what about Data Principal Rights? This is, perhaps, the trickiest aspect of this arrangement. A worker exercising the right to correction, completion, updating or erasure should ordinarily be able to approach the entity that independently controls the relevant personal data. There is no statutory basis for a factory or client to redirect a request concerning its own CCTV footage to the contractor merely because the worker is employed by the contractor.
Until the Data Protection Board or the Central Government provides interpretative guidance, organisations engaging contract labour should resist the temptation to mechanically characterise one party as the Data Processor of the other. The more legally sustainable approach is to identify each processing activity separately, determine who decides the purpose and means of that activity, and allocate responsibilities contractually in a manner that reflects the practical realities of the relationship rather than labels adopted in the agreement. For this, a standard manpower supply agreement will be insufficient. Where genuine processor status exists, or even where dual-fiduciary status exists and data flows between the parties, the contract should separately address: (i) Section 8(2) sub-processor engagement and audit rights; (ii) breach notification timelines tighter than the 6-hour CERT-In window to allow onward reporting; (iii) mutual DSR assistance with defined turnaround (recommend 5 business days internal, against the Rules’ 90-day external ceiling); (iv) retention and certified-deletion obligations on contract exit; and (v) a clear purpose-and-basis schedule mapped to the personal data collected, to survive Data Protection Board scrutiny.
Author