When a business shares personal data with a third party — a cloud vendor, a payroll provider, a marketing platform, a logistics partner — there is a natural instinct to treat the handoff as a transfer of responsibility. The data is no longer in your systems. The vendor has agreed to your terms. You have done what you can. What happens next is their problem.
Under the Digital Personal Data Protection Act, 2023, this instinct is wrong — and acting on it is one of the most common ways businesses inadvertently create serious compliance exposure.
Fiduciary and Processor: The Distinction That Matters
The DPDP Act draws a clear line between two categories of entities. A Data Fiduciary determines the purpose and means of processing personal data — it decides why data is collected and what is done with it. A Data Processor processes data on behalf of the Fiduciary, acting on its instructions, without independently determining the purpose.
Your cloud storage provider is a Processor. Your HR software vendor is a Processor. Your email marketing platform is a Processor. Your analytics provider, your customer support tool, your payroll bureau — all Processors. They handle personal data, but the decision about why that data exists and what it is used for remains yours.
The consequence is direct: the Data Fiduciary's obligations under the Act do not diminish because a Processor is involved. The Fiduciary remains responsible for ensuring that personal data is processed lawfully, securely, and in accordance with the Act — regardless of which system the data currently sits in or which entity is handling it.
"Engaging a Data Processor does not reduce the Data Fiduciary's liability. It extends it — into every system the Processor operates on your behalf." — Shashank Sharma
What a Data Processing Agreement Must Actually Do
The DPDP Act requires that Data Processors be engaged by contract. But the standard boilerplate that appears in most vendor agreements — a brief data protection clause, a reference to applicable law, a liability cap — does not constitute a compliant data processing agreement. The contract needs to do specific work.
A valid data processing agreement under the DPDP Act framework must, at minimum, require the Processor to: process data only on the Fiduciary's documented instructions; implement and maintain security safeguards that meet the Act's standard; notify the Fiduciary promptly in the event of a breach; restrict sub-processing without prior authorisation; delete or return data on termination; and cooperate with audits and compliance reviews. It must also record the subject matter, duration, nature, and purpose of processing with sufficient specificity.
Most vendor contracts in circulation today do not cover this ground. They were drafted before the DPDP Act came into force, oriented around older frameworks or generic liability allocation principles. They are not adequate — and the inadequacy is the Fiduciary's problem, not the Processor's.
The Breach Notification Problem
Consider the breach notification obligation. When a personal data breach occurs, the Data Fiduciary must notify the Data Protection Board within 72 hours. The Fiduciary must also notify affected individuals. The clock starts when the breach occurs — not when the Fiduciary finds out about it.
Now consider that the breach did not occur in your systems. It occurred in your Processor's. Your payroll vendor was compromised. Your cloud storage provider had a misconfigured bucket. Your customer support platform leaked ticket data. The breach was not yours — but the notification obligation is. And if your vendor contract does not require the Processor to notify you immediately upon discovering a breach, you may not hear about it until days or weeks later, by which point your 72-hour window has long closed.
The breach notification provisions of your vendor contracts are not a formality. They are the mechanism by which you are able to meet your own statutory obligations. If they are inadequate, your compliance programme has a structural gap that no internal process can fix.
Sub-Processors: The Visibility Problem
A further complexity arises from sub-processing. The vendor you engage to process data on your behalf may itself engage sub-vendors — other platforms, infrastructure providers, specialist services — who in turn handle personal data. Each layer of this chain remains within the scope of your obligations as the Data Fiduciary.
Most businesses have limited visibility into their vendors' sub-processing arrangements. If your vendor contract does not require disclosure of sub-processors and prior authorisation before new sub-processors are engaged, you may have no idea how far the chain extends or who is ultimately handling the data you are responsible for.
The Audit That Cannot Be Deferred
The vendor contract review is one of the most immediately actionable items in any DPDP Act compliance programme — and one of the most commonly deferred. It feels like a procurement exercise rather than a legal one. It involves negotiating with vendors who may resist substantive changes to their standard terms. It is unglamorous work.
But it is not optional. The May 2027 compliance deadline applies to the full scope of a Data Fiduciary's obligations — including the obligations that flow through its Processor relationships. A business that has updated its website privacy notice and redesigned its consent flows, but has not reviewed its vendor contracts, has completed the visible part of compliance and left the structural part untouched.
Start with the vendors that handle the most personal data, or the most sensitive categories of data. Map the sub-processing arrangements. Identify the contracts that have no data protection provisions at all. Work outward from there. The exercise is manageable if begun now. It is not manageable if begun in April 2027.