A customer wants a DPA — what is it and do I need one?
Everything Indian IT vendors need to know about Data Processing Agreements under DPDP Rules 2025 — and why having one ready is now a commercial advantage.
It used to arrive as a vague request: "Can you sign our data agreement?" Now it arrives with a deadline: "We need your signed DPA before we can process your invoice." If you have been getting these requests and have been improvising responses or forwarding them to a lawyer who has never seen the DPDP Act, this guide is for you.
A Data Processing Agreement is the contractual backbone of any vendor relationship involving personal data under India's DPDP framework. Understanding what it is, when it is required, what it must contain, and how to use it commercially will save you time, legal fees, and potentially deals. If you are still unsure whether you are a vendor who processes data or a controller of that data, read our earlier post on Data Fiduciary vs Data Processor: which one is my company? first, because your DPA obligations depend on that classification.
What is a DPA under DPDP Rules 2025?
The DPDP Act 2023 establishes that a Data Fiduciary (your client, in most vendor scenarios) must not engage a Data Processor (you, as the vendor) without a written contract that specifies the purpose and scope of processing. The DPDP Rules 2025, which operationalise the Act, add further detail about what such contracts must address.
At its core, a DPA is a written agreement between a Data Fiduciary and a Data Processor that:
- Defines the categories of personal data being processed
- Specifies the permitted purposes and the processing activities the Processor may perform
- Establishes the security standards the Processor must maintain
- Sets out breach notification obligations — how fast the Processor must tell the Fiduciary if something goes wrong
- Addresses sub-processing — whether the Processor can engage further sub-processors and under what conditions
- Governs data retention and deletion — what happens to the data when the engagement ends
- Grants audit rights to the Fiduciary to verify the Processor's compliance
- Allocates liability and indemnification between the parties
Think of it as a master data rulebook layered on top of your commercial contract. It does not replace your service agreement — it supplements it, specifically for personal data handling.
When is a DPA legally required?
Under the DPDP Act 2023, a written contract between the Data Fiduciary and Data Processor is mandatory wherever the Fiduciary engages a Processor to handle personal data on its behalf. This requirement applies whenever:
- Your client (the Fiduciary) shares personal data of Indian residents with you for processing
- You access your client's systems containing personal data to deliver your services
- You collect personal data directly from individuals on your client's behalf
In practical terms, if you are an IT services vendor, a SaaS provider, a managed services company, a BPO, or any outsourced services firm that touches personal data belonging to your client's customers, employees, or partners — a DPA is legally required. This is not a grey area in the DPDP framework.
The question is not whether you need a DPA. It is whether your existing vendor contract already contains all the elements that a DPA must include. Many legacy MSAs and SaaS subscription agreements do not. Enterprise clients' legal teams have started flagging this and requiring a separate DPA addendum, or a full redraft of the services agreement to incorporate DPDP-compliant data processing clauses.
What enterprise clients are actually asking for
When a large bank, hospital chain, or e-commerce company sends you a DPA to sign, here are the clauses that their legal teams scrutinise most carefully:
Processing instructions clause
Enterprise clients want a clause stating that you will only process their personal data strictly according to their written instructions and not for any other purpose — including your own product improvement, training data, or analytics — without their express consent. This is the clause that most SaaS vendors stumble on, because their standard terms typically include broad rights to use anonymised data for product improvement.
Security measures annex
A DPA typically includes a schedule describing the technical and organisational security measures (TOMs) the Processor commits to maintaining — encryption standards, access controls, penetration testing frequency, backup procedures. Enterprise clients in BFSI especially want quantified commitments, not vague language about "industry-standard security."
Breach notification timeline
This is one of the most commercially significant clauses. Most enterprise DPAs require the Processor to notify the Fiduciary of any personal data breach within 24–72 hours of discovery — because the Fiduciary has its own obligation to notify the Data Protection Board on a government-prescribed timeline. If your breach notification SLA is not clearly defined in the DPA, you are exposing both yourself and your client to regulatory risk. This connects directly to the penalty exposure that flows from late or missed breach notifications.
Sub-processor approval
If you use third-party cloud providers, subcontractors, or offshore development teams to deliver your services, the DPA will typically require you to list them, get prior written approval before adding new sub-processors, and flow down the same data protection obligations to any sub-processor you engage. This is the clause that catches cloud-first companies off guard — they are sub-processing through AWS or Azure and have never thought to mention it to their clients.
Data return and deletion
When the contract ends, what happens to the client's data in your systems? Enterprise DPAs require a specific timeline for deletion or return, and often require the Processor to provide written certification of deletion. If your systems are multi-tenant, this clause requires careful thought about how you technically achieve data segregation and deletion.
Why a ready DPA template is now a sales asset
Traditionally, vendors have been reactive on DPAs — waiting for the client to send their template, then spending weeks reviewing it with counsel, then negotiating clause by clause. This process can delay contract closure by four to eight weeks, and for a mid-size IT vendor where cash flow matters, that delay has a real cost.
The vendors who are winning enterprise deals fastest in the current DPDP environment are those who can say: "Yes, we have a standard DPA — here it is." Arriving at the procurement table with your own well-drafted DPA template signals three things to the client's legal team: you understand DPDP, you process data professionally, and you are not going to be a compliance liability.
A vendor-side DPA template also gives you negotiating leverage. Rather than reacting to the client's template — which will be written entirely in the client's favour — you can start from a balanced position and negotiate towards the middle. If you have been waiting for clients to initiate the DPA conversation before thinking about it, read our post on responding to DPDP security questionnaires — the DPA request usually follows the questionnaire quickly.
What a vendor-side DPA template should include
A DPDP-compliant DPA for an Indian IT vendor should, at minimum, cover:
- Parties and purpose: Identify the Fiduciary and Processor clearly; describe the processing purpose in specific terms, not generic language
- Data categories: List the categories of personal data covered — avoid catch-all definitions that include data you do not actually handle
- Processing instructions: State that you process only on the Fiduciary's documented instructions, with exceptions only where required by Indian law
- Confidentiality: Commit that your personnel with access to the data are bound by confidentiality obligations
- Security measures: Attach a schedule of your current technical and organisational measures
- Sub-processing: List current sub-processors; require written approval for new ones; flow-down obligations
- Data principal rights: Commit to assisting the Fiduciary in responding to data principal requests (right to access, correction, erasure)
- Breach notification: 24-hour internal detection escalation; 48-hour notification to the Fiduciary
- Audit rights: Allow the Fiduciary to audit (with notice and at their cost, within reason)
- Deletion on termination: Specify timeline and certification process for data deletion
- Liability cap: Negotiate a reasonable cap that aligns with your insurance cover
- Governing law: Indian law and jurisdiction
Need a DPDP-compliant DPA template ready to sign?
Our DPA Generator produces a fully customised, DPDP Rules 2025-compliant Data Processing Agreement for your company — ready in minutes, drafted to protect you as a vendor.
Generate My DPA — ₹1,999Frequently Asked Questions
Can I refuse to sign a client's DPA?
Technically yes, but commercially it almost certainly means losing the contract. Under DPDP, the Fiduciary (your client) has a legal obligation to have a written processing contract with you. If you refuse to sign one, they cannot legally engage you to process their personal data. In practice, the conversation is about the terms of the DPA, not whether to have one. Use a vendor-side template to negotiate from a position of strength rather than reacting to the client's template.
How is a DPA different from a standard NDA or confidentiality agreement?
An NDA covers confidential information broadly — trade secrets, business strategies, technical specs. A DPA is specifically about personal data of individuals and is governed by the DPDP Act framework. They serve different purposes and should both exist in a vendor relationship that involves personal data. An NDA does not substitute for a DPA, and having an NDA in place does not mean you have met your DPDP obligations.
What happens if a breach occurs and we don't have a signed DPA?
The absence of a DPA does not reduce your legal exposure — it may increase it. Under DPDP, both the Fiduciary and Processor are expected to have appropriate contractual and technical safeguards in place. If a breach occurs without a DPA, the Fiduciary may claim the entire liability rests with you as an unauthorised or non-contracted Processor. More practically, the absence of a DPA with a clear breach notification timeline makes it harder to coordinate the response quickly, which can worsen the regulatory outcome for both parties.