What is a Data Processing Agreement under DPDP — key clauses explained

What is a Data Processing Agreement under DPDP — key clauses explained
DPA

What is a Data Processing Agreement under DPDP — key clauses explained

A DPA is the legal contract that governs how a vendor handles your data. Here is what it is and what it must contain under DPDP.

Quick Answer: A Data Processing Agreement (DPA) under the DPDP Act is a legally binding contract between a Data Fiduciary and a Data Processor that governs how the Processor handles personal data on behalf of the Fiduciary. The Fiduciary must engage a Data Processor only under a valid contract — and the contract must ensure the Processor processes data only on documented instructions from the Fiduciary and in compliance with the Act. Key DPA clauses: purpose and scope of processing; restriction on sub-processing without authorisation; security obligations; breach notification to the Fiduciary; data deletion on termination; audit rights; cross-border transfer controls; and a prohibition on the Processor using data for its own purposes. Without a valid DPA, the Fiduciary is in breach of the Act's processor engagement requirements.

Why is a DPA legally required under the DPDP Act?

The Act prohibits a Fiduciary from engaging a Data Processor without a valid contract. This is not a formality — the absence of a DPA means the Fiduciary has no documented assurance that the Processor is handling data correctly, no contractual remedy if the Processor misuses data, and no basis for enforcing breach notification obligations. Regulators investigating a data breach will immediately ask for the DPA with the processor involved in the incident. 'We had an agreement but it did not have data protection terms' is not an acceptable response.

What are the mandatory elements of a DPDP DPA?

A DPDP-compliant DPA must include: (1) A description of the processing — what data is processed, for what purpose, for how long; (2) Instructions — the Processor acts only on documented Fiduciary instructions; (3) Sub-processor controls — the Processor cannot engage sub-processors without Fiduciary approval and must impose equivalent obligations on sub-processors; (4) Security — the Processor must implement appropriate technical and organisational security measures; (5) Breach notification — the Processor must notify the Fiduciary promptly of any incident; (6) Deletion — the Processor must delete data on termination or instruction; (7) Audit rights — the Fiduciary can audit the Processor's compliance.

What is the difference between a DPA and a standard service contract?

A standard IT service contract covers: service scope, SLAs, payment, IP rights, and termination. It does not address data protection — who controls the data, what happens if the vendor is breached, or the vendor's security obligations for your customers' data. A DPA is a separate or addendum agreement specifically governing data protection obligations. Many SaaS vendors include a DPA as a separately signable addendum to their main service terms. Ensure you have signed the DPA addendum — just signing the main service terms is not sufficient for DPDP compliance.

How should a DPA address cross-border data transfers?

If the Processor stores or processes your personal data outside India, the DPA must address the cross-border transfer. Once the government publishes its approved country list, the DPA should reference transfer only to listed countries. Until then, include a transfer provision that: identifies the data destination countries; requires the Processor to notify you if they change data storage locations; and commits to compliance with Indian cross-border transfer regulations as they are notified. If the transfer is to an SCC-equipped EU vendor, note that SCCs are not automatically compliant with DPDP but provide a useful framework.

How do you handle DPAs with global SaaS providers?

Global SaaS providers (Google, Microsoft, Salesforce, AWS) typically have standard DPA addenda that comply with GDPR. These provide a reasonable starting point for DPDP compliance — many of the underlying obligations overlap. Review the vendor DPA against the DPDP requirements and identify gaps: is breach notification to you within 48 hours? Does it restrict AI/ML training on your data? Does it name sub-processors? Negotiate on the specific gaps rather than seeking a complete redraft — global vendors will not issue fully custom DPAs for standard contracts.

What remedies does the Fiduciary have if the Processor violates the DPA?

The DPA should specify remedies for Processor breach: the right to terminate the contract immediately for a material breach (including a security incident caused by the Processor's negligence); indemnification from the Processor for costs incurred as a result of their breach (including Board penalties that arise from the Processor's failure); the right to audit compliance and direct remediation; and withholding of payment if the Processor fails to deliver deletion certificates. Note that Board penalty liability ultimately runs to the Fiduciary — the DPA's indemnification provision is your contractual route to recovery from a negligent Processor.

Frequently asked questions

Do we need a DPA with every vendor we use?

Only with vendors who process personal data on your behalf — Data Processors under the Act. A vendor who provides purely commercial services (office stationery, catering, pest control) with no access to personal data does not need a DPA. A vendor who provides payroll processing, cloud hosting, customer support software, or marketing automation — all of which involve processing personal data on your behalf — needs a DPA. The data sharing scope of each vendor relationship determines whether a DPA is required.

Can the same document serve as both a service agreement and a DPA?

Yes — a DPA can be integrated into the main service agreement or exist as a separate addendum. The integrated approach is administratively simpler. The addendum approach is common with global SaaS providers who issue the same DPA addendum to all customers regardless of their main contract terms. Either approach is valid as long as the DPA content meets the DPDP requirements. Use the addendum approach when the vendor insists on their standard DPA terms — it keeps your main contract negotiation separate from the DPA negotiation.

When should a DPA be executed — before or after data sharing begins?

Before. You cannot share personal data with a vendor and then execute the DPA retrospectively — the data sharing without a DPA is already a DPDP violation. Execute the DPA before granting the vendor any access to personal data. In practice, build the DPA execution into your vendor procurement process as a mandatory step before access credentials are issued. For existing vendors without DPAs, execute DPAs retrospectively as quickly as possible — while technically the sharing without a DPA was already a violation, remediation is treated more favourably than continued non-compliance.

Review and execute your vendor DPAs

Niti Bharat's Vendor DPA Review covers gap analysis of existing agreements, model DPA template, and negotiation guidance for both global SaaS and Indian vendor DPAs under DPDP.

Start Vendor DPA Review
Previous Post Next Post

Get Free DPDP Checklist