Third-party vendors and data processors: who's responsible when things go wrong?

At a glance

Under India’s DPDP Act, if a vendor processing data on your behalf causes a breach, you — the Data Fiduciary — remain accountable to the affected people and the regulator. A contract can’t shift that responsibility away; the Act makes you answerable for processing done on your behalf. Your vendor answers to you under your contract, but the individual whose data leaked, and the Data Protection Board, look to you first. That’s why vendor choice and oversight are a compliance duty, not an afterthought.

Educational resource only. This explains responsibility for processors and vendors under India’s Digital Personal Data Protection Act, 2023 (DPDP Act); it is not formal legal advice.

The situation

You use vendors for the things you don’t do in-house — a cloud host, a CRM, an email tool, an analytics provider, an outsourced support desk. Each one touches your customers’ personal data. When one of them leaks it or misuses it, the question that suddenly matters is: whose problem is this, legally? Mostly, it’s yours — but not only yours.

The default answer: the Fiduciary is accountable

If the data is being processed on your behalf, you stay responsible for it — full stop. The Act is explicit that a Data Fiduciary is responsible for complying with the law for any processing undertaken by it or on its behalf by a Data Processor (Section 8). So when a vendor handles your customers’ data to your instructions and something goes wrong, the accountability to the individual and to the Data Protection Board of India runs back to you.

This is deliberate. The person whose data leaked chose to trust you, not your sub-contractor they’ve never heard of — so the law keeps you on the hook rather than letting responsibility evaporate down a chain of vendors.

Where the vendor’s responsibility sits

The vendor isn’t off the hook — but it primarily answers to you, through your contract, not directly to your customer. A Processor must be engaged only under a valid contract, must stay within your stated purpose, keep the data secure, and delete it when the job’s done. If it fails, it has breached its agreement with you, and you can pursue it on that basis — indemnities, termination, damages.

And a vendor that goes off-script — using your data for its own purposes — steps into Fiduciary shoes for that misuse and picks up direct obligations of its own. But for ordinary “processing on your behalf,” the outward-facing responsibility is yours; the vendor’s is inward-facing, to you.

Why “it was the vendor’s fault” isn’t a defence

Pointing at your processor doesn’t discharge your duty — the Act removes exactly that escape route. Your responsibility holds irrespective of any agreement to the contrary: you can’t contract your way out of accountability to the individual, even if your vendor agreed to take the blame. Practically, that means before the regulator, “our vendor messed up” explains how the breach happened but doesn’t answer who is responsible — that’s still you. What a good contract does is let you recover from the vendor afterwards; it doesn’t move the front-line accountability.

How to protect yourself before something goes wrong

Since you carry the risk, treat vendor management as part of your own compliance — not the vendor’s problem. Concretely:

• Contract properly. Use a written Data Processing Agreement that fixes purpose, security standards, sub-processors, breach-notification duties to you, and deletion on exit.
• Diligence the vendor. Check its security posture before handing over data — you’re vouching for it by using it.
• Limit what you share. Give each vendor only the data it needs for its task; less shared, less exposed.
• Get breach commitments. Require prompt notice to you so you can meet your own reporting duty to the Board and to individuals.
• Keep a record. Know which vendors hold which data under which contract — you can’t oversee what you haven’t mapped.

FAQ