Most companies in India are still operating with a Data Processing Agreement built around the GDPR. That is not surprising. The GDPR has been the world's template for years, and many Indian businesses inherited their DPAs from European clients, parent companies, or earlier counsel.
The trouble is that the Digital Personal Data Protection Act, 2023 is not the GDPR. It uses different terminology, takes a far narrower view of lawful processing, and creates obligations the GDPR does not. A DPA that reads cleanly under European law can leave real gaps under Indian law.
This is a working checklist. Ten points your DPA should pass before it gets signed. It is written from the perspective of someone who has drafted and redlined several hundred of them, not from a textbook.
A 60-second refresher on the players
Under the DPDP Act:
- Data Fiduciary decides why personal data is processed and how. Think: the GDPR's controller.
- Data Processor processes data on the Fiduciary's behalf, under its instructions.
- Data Principal is the individual the data belongs to. Think: the data subject.
- Data Protection Board of India is the enforcement authority.
Two things often surprise people. First, the Act is consent-first. The lawful bases for processing are far narrower than the GDPR's six grounds. You have consent on one hand and a limited list of "legitimate uses" under section 7 on the other, and that is essentially it. There is no general "legitimate interests" basis. Second, certain organisations may be notified as Significant Data Fiduciaries with additional obligations, including appointing a Data Protection Officer and conducting periodic Data Protection Impact Assessments.
The 10-point checklist
1. Pin the role clearly
The biggest source of trouble in a DPA is ambiguity about who is who. The agreement should name the parties as Data Fiduciary and Data Processor on its first page, and there should be no daylight between that labelling and what they actually do. If the Processor independently decides any aspect of the processing, what to do with the data, who to share it with, how long to keep it, it stops being a Processor for that activity and becomes a joint or independent Fiduciary, with different obligations.
2. State the lawful basis explicitly
Under the DPDP Act, the Fiduciary needs to be clear about its lawful basis: consent under section 6, or a section 7 legitimate use. The DPA should not leave the lawful basis to be inferred. State it. And state who is responsible for obtaining and demonstrating consent, with the standards required: free, specific, informed, unconditional and unambiguous, with a clear affirmative action.
3. Describe the processing in detail
Annex A of your DPA should set out, plainly: what categories of personal data are being processed, what categories of Data Principals they belong to, what the purpose of the processing is, and how long the data will be kept. Vague descriptions are the single most common gap I see in DPAs that come across my desk. "Personal data of customers, for service delivery" is not enough.
4. Security safeguards under section 8(5)
Section 8(5) of the DPDP Act requires the Fiduciary to take reasonable security safeguards to prevent personal data breaches. Pass this obligation through to the Processor with teeth: encryption in transit and at rest, access control on least-privilege principles, secure backup, periodic security testing and demonstrable incident response. Generic language like "industry-standard measures" is a placeholder, not a clause.
5. Personal Data Breach notification, what the Act actually says
The DPDP Act requires the Fiduciary to notify the Board and affected Data Principals in the event of a personal data breach. The Act itself leaves the timeline to rules. The draft DPDP Rules contemplate notification without delay, with detailed reporting within a defined window. Until the rules are final, your DPA should require the Processor to alert the Fiduciary very quickly. 24 to 48 hours from discovery is what I recommend, so the Fiduciary has any practical chance of meeting its statutory obligation.
Verbatra's DPA generator builds a Data Processing Agreement adapted to the DPDP Act in 60 seconds, with all of the above already wired in.
Open the DPA generator →6. Subprocessor controls
The DPA should require the Processor to obtain authorisation before engaging any subprocessor, to flow down equivalent obligations to that subprocessor by contract, and to remain fully liable for its subprocessor's acts. List the approved subprocessors in an annex and require notice before any change. This is one of the easiest controls to insert and one of the most often skipped.
7. Cross-border transfers under section 16
Here the DPDP Act takes a structurally different approach to the GDPR. Section 16 lets the Central Government restrict transfers of personal data to specified countries or territories by notification, a "negative list" approach that is the opposite of the GDPR's adequacy decisions. Your DPA should commit the parties to keeping their cross-border arrangements aligned with whatever the Government notifies from time to time, and should require the Processor to inform the Fiduciary about the geographies in which the data sits.
8. Data Principal rights
The DPA should require the Processor to assist the Fiduciary in responding to Data Principal requests under sections 11 to 15 of the Act: access to information about processing, correction and erasure, grievance redressal, nomination, and so on. Concretely, that means timelines for forwarding requests to the Fiduciary and supporting the response. Vague "reasonable assistance" obligations are not enough when the statutory clock is ticking.
9. Records, audits and accountability
The DPA should require the Processor to maintain records of its processing activities and make them available to the Fiduciary or its auditor on reasonable notice. For Significant Data Fiduciaries, and for any client that may be notified as one, periodic audits are not optional. Build the right to audit into the DPA from the start.
10. Termination, return or deletion
On termination, the Processor should return or delete all personal data, at the Fiduciary's choice, and certify the action. Carry the obligation through to any subprocessor and any backup copies. Define the limited exceptions where retention is required by law, and require deletion of those copies once the legal hold lifts.
Three common mistakes
Reusing the GDPR DPA verbatim
You will pass several of these points by accident if your DPA is a clean European template. You will fail others, especially around lawful basis (no general legitimate interests under DPDP), Data Principal rights wording, and the transfer mechanism. India does not yet have an SCC-equivalent framework that maps onto European Standard Contractual Clauses.
Treating consent as a one-time tick
Consent under the DPDP Act has to be free, specific, informed, unconditional and unambiguous, and the Data Principal must be able to withdraw it as easily as they gave it. Your DPA should require the Processor to support the Fiduciary in honouring withdrawals, not just in collecting consent.
Forgetting about the Significant Data Fiduciary regime
If your client may be notified as a Significant Data Fiduciary, the DPA needs to anticipate the additional obligations: Data Protection Officer appointment, periodic Data Protection Impact Assessments, audits by an independent data auditor. Building this in retroactively is much harder than including it from the start.
The bottom line
A DPA is a small contract that does a lot of quiet work. Under the DPDP Act, that work has changed. If your current DPA was written before December 2023, or was written by counsel who specialises in European law, give it a proper read against this checklist before the next time you sign one.