Confidential Dispatch

A guide to third-party Data Processor Agreements (DPAs) for Indian agencies

4 min readUpdated 2026-07-05
On this page
  1. 01Why a DPA is non-optional
  2. 02What a DPA needs to cover
  3. 03Agencies sit on both sides of it
  4. 04Common gaps that come back to bite
  5. 05FAQ
At a glance

Under India’s DPDP Act, a Data Fiduciary can engage a processor to handle personal data only under a valid contract — and because the Fiduciary stays accountable for what the processor does, that contract is your main protection. A Data Processor Agreement (DPA) should pin down the purpose and scope, security expectations, sub-processors, breach-notification-to-you, how the processor supports rights requests, and deletion or return of data when the work ends. For an agency, you’ll often be on both sides of a DPA — as the fiduciary hiring vendors, and as the processor a client hires.

Educational resource only. This explains Data Processor Agreements under India’s Digital Personal Data Protection Act, 2023 (DPDP Act); it is not formal legal advice.

The situation

Agencies, SaaS vendors and freelancers pass personal data around constantly — a client’s customer list into an email tool, leads into a CRM, files to a designer. The DPDP Act says that hand-off needs a contract, and because responsibility flows back to whoever decided the purpose, a loose or missing agreement is a real exposure — not just paperwork.

Use the template

DPDP DPA template — a ready-to-adapt Data Processor Agreement covering the clauses below.

Why a DPA is non-optional

The Act permits engaging a processor only under a valid contract — and it keeps the Fiduciary on the hook regardless. A Data Fiduciary is responsible for compliance for processing done on its behalf (Section 8), irrespective of any agreement to the contrary. So the contract doesn’t move your accountability to the individual — but it’s what lets you set the rules for the vendor, hold them to a standard, and recover from them if they fail. No DPA means no defined boundary on what a vendor may do with data you’re still answerable for.

What a DPA needs to cover

A good DPA turns “handle our data properly” into specifics. At minimum, it should fix:

  • Purpose and scope — exactly what the processor may do with the data, and nothing beyond it.
  • Instructions only — the processor acts on your instructions, not its own purposes; using the data for itself is off-limits.
  • Security standards — the safeguards expected, proportionate to the data’s sensitivity.
  • Sub-processors — whether the vendor may use its own sub-contractors, and on what terms.
  • Breach notification to you — prompt alerts so you can meet your own reporting clock.
  • Rights support — how the processor helps when an individual exercises access, correction, or erasure.
  • Deletion or return — what happens to the data when the engagement ends; no keeping it “just in case.”
  • Audit / assurance — your ability to check the processor is doing what it agreed.

Agencies sit on both sides of it

As an agency you’re usually the fiduciary hiring vendors and the processor a client hires — so you’ll negotiate DPAs from both directions. When a client hands you their customer data, you’re their processor, and you’ll sign their DPA (or should ask for one). When you then push that data into your own email or analytics tools, you’re the fiduciary engaging those vendors, and you need DPAs with them. Getting comfortable reading a DPA from both seats is part of the job — and being able to show clean processor terms is increasingly something clients check before they hire you.

Common gaps that come back to bite

Most DPA problems are omissions, not bad clauses. The recurring ones: no breach-notification-to-you clause (so a vendor’s incident silently eats your 72-hour window); silence on sub-processors (so your data travels further than you realised); no deletion-on-exit term (so copies linger with a former vendor); and a purpose written so broadly it authorises almost anything. Tighten those four and a basic DPA does most of its job.

FAQ

Do I legally need a contract with my data vendors?

Yes. The DPDP Act allows engaging a processor only under a valid contract. Beyond compliance, it’s your main tool to control and, if needed, recover from a vendor.

Does a DPA move my liability to the vendor?

No. Your accountability to individuals and the regulator holds irrespective of the contract. The DPA lets you set standards and recover from the vendor — it doesn’t shift your front-line responsibility.

We’re an agency — do we need our own DPA or the client’s?

Usually both. You sign the client’s DPA as their processor, and you put DPAs in place with the tools and sub-vendors you use as a fiduciary.

What’s the most important clause to get right?

Breach notification to you, plus a tight purpose limit and a deletion-on-exit term. Those prevent the failures that most often blow back on the fiduciary.

Reviewed by Confidential Dispatch Editorial Team
Last updated 5 July 2026
Not legal advice.

Collecting personal data from your own customers?

These are the rights your business has to honour. See where you stand with a two-minute self-check — no sign-up, no data stored.

Run the compliance self-check →