Data Fiduciary vs. Data Processor Under DPDPA: Roles, Obligations and Contract Templates

I have reviewed a lot of vendor contracts in my time, first as an internal auditor checking third-party risk, later as a virtual CFO negotiating them on a founder's behalf. The DPDPA definitions are actually fairly close to plain English once you strip the legal phrasing out. The Data Fiduciary is the decision-maker, the company that says "we are collecting this data because we want to do X with it." The Data Processor is the pair of hands, the payroll vendor, the cloud hosting provider, the customer support platform, that handles the data because the Fiduciary told it to, on the Fiduciary's terms, for the Fiduciary's purpose.

Where this gets interesting, and where I have seen genuine disputes, is when a vendor's product quietly starts making its own decisions about the data it touches. An analytics tool that was hired purely to process event data on your behalf, but then trains its own models on aggregated customer data across all its clients for its own product improvement, has stepped out of the processor role for at least that slice of processing. At that point it is arguably acting as a joint or independent Data Fiduciary for that specific purpose, whatever the contract calls it, because DPDPA cares about who actually determines the purpose, not what label sits at the top of the master services agreement.

This is the point that surprises people who have worked with GDPR, which imposes meaningful direct obligations on processors too. DPDPA is built differently. Section 8 loads the operational obligations, reasonable security safeguards, breach notification, grievance redressal, onto the Data Fiduciary. A Data Processor's obligations largely exist by contract, flowed down from the Fiduciary, rather than as a direct statutory duty enforceable by the Board against the processor itself.

So if your payroll vendor gets breached and your employees' salary data leaks, it is your company, the Fiduciary, that the Data Protection Board comes to first, not the vendor. That reality should change how you negotiate every vendor contract you sign from here. I think the biggest mistake founders make is treating "we outsourced it" as risk transfer. Under DPDPA it is closer to risk delegation with a very thin contractual net underneath it, and that net is only as strong as the clauses you actually put in the agreement.

Here is the checklist I run through with clients when a vendor contract crosses my desk, since I would rather have this conversation before signature than after an incident.

Core clauses: • processing scope limited explicitly to the Fiduciary's stated purpose, with no silent secondary use • confidentiality obligations extending to all vendor personnel and sub-processors • security safeguards matched to the sensitivity of the data, encryption, access controls, logging • a breach-notification clock that runs to the Fiduciary in hours, not days, since the Fiduciary's own 72-hour clock to the Data Protection Board starts running regardless of when the vendor tells them • audit and inspection rights, even if exercised rarely, because the right to ask matters more than how often you use it • explicit sub-processor consent and flow-down of the same obligations to any fourth party the vendor brings in • data return or certified deletion within a defined window on contract termination, with no "we'll get to it" language.

I would also flag one clause people forget: an indemnity that reflects the reality above, that regulatory penalties will likely land on the Fiduciary first. A processor that will not accept meaningful liability exposure for its own security failures is, in effect, asking you to insure their risk for free.

I think the practical fix here is boring but effective, and boring is usually what saves you in this line of work. Map processing activity by activity, not vendor by vendor. Ask, for each thing a vendor does with your data, who decided that this particular use should happen and why. If the answer is "we told them to," it is processing on your behalf. If the answer drifts toward "their product does this by default for all customers," you may be looking at a purpose the vendor itself determined, which changes the classification and the liability conversation for that slice of data, however the master agreement is titled.