The DPA is the only document that stops vendor liability from becoming your liability under DPDPA.
DPDPA 2023 keeps the Data Fiduciary primarily liable for breaches caused by processors. The Data Processing Agreement is the operative document that allocates this risk between you and your vendor. A poorly drafted DPA leaves the fiduciary holding 250 crore in maximum penalty plus litigation cost. A well drafted DPA recovers the cost from the vendor.
The Document That Determines Whether DPDPA Liability Stops at the Vendor or Lands on You
Most enterprises using third party processors believe their compliance ends at choosing reputable vendors. They are mistaken.
Under DPDPA 2023, the Data Fiduciary remains primarily liable for breaches caused by its processors. The Data Protection Board imposes penalties on the fiduciary, not the vendor. The Data Principal sues the fiduciary, not the vendor. Reputational damage falls on the fiduciary, not the vendor. The vendor's role in the breach is the fiduciary's problem to recover from the vendor.
The Data Processing Agreement is the only document standing between a fiduciary and the full economic cost of a vendor caused breach. A well drafted DPA recovers the cost from the vendor. A poorly drafted DPA leaves the fiduciary holding 250 crore in maximum penalty plus litigation costs plus reputational damage.
This page explains how to draft DPAs that actually allocate risk in your favour, not vendor templates that allocate risk back to you.
Step One: Get the Roles Right
DPDPA 2023 introduces two operational categories of entities handling personal data.
Data Fiduciary is any person who alone or in conjunction with others determines the purpose and means of processing personal data. The fiduciary decides why data is being processed (the purpose) and how it is being processed (the means).
Data Processor is any person who processes personal data on behalf of a Data Fiduciary. The processor follows the fiduciary's instructions. It does not determine purpose or means.
The roles map approximately to the GDPR controller and processor distinction. The same enterprise can be a fiduciary for some processing activities and a processor for others. A SaaS company is typically a processor when it handles customer data on behalf of its enterprise customers, and a fiduciary when it processes its own employee or marketing data.
The DPA must precisely identify which party is the fiduciary and which is the processor for the specific processing activities covered. Mixed role arrangements (where the parties are simultaneously fiduciary and processor for different data flows) require careful articulation. A single party serving both roles in the same arrangement triggers different obligations and liability allocations for each role.
Misidentifying roles in the DPA creates two failures. First, the obligations imposed do not match what DPDPA requires. Second, in a regulatory enquiry, the regulator may reclassify the parties differently than the contract suggests, exposing the misidentified party to obligations it did not contractually accept.
Scope and Purpose: The Operative Limits on Processing
The DPA must define what the processor may do with the data. This is not a formality. It is a substantive constraint.
The scope clause specifies the categories of personal data being processed. Examples: full name, email address, phone number, location data, payment information, demographic information, behavioural data. Specificity matters. A clause permitting processing of all personal data is overbroad and may not satisfy DPDPA's purpose limitation principle.
The purpose clause specifies the precise purposes for which the processor may process the data. Examples: providing the service, customer support, billing, analytics for service improvement, fraud prevention. Each purpose must be articulated. The processor may not process data for purposes not specified, even if the data is the same.
The duration clause specifies how long the processor may process the data. Examples: for the term of the master services agreement plus a defined wind down period. Indefinite processing rights are not aligned with DPDPA's storage limitation principle.
The categories of Data Principals must be specified. Examples: customers of the fiduciary, end users of the fiduciary's products, employees of the fiduciary, business contacts. This affects the processor's obligations including accommodating Data Principal rights requests.
Tight scope and purpose clauses constrain the processor's permissible activities. Loose clauses give the processor latitude to use data for its own purposes (analytics, machine learning model training, marketing) without specific consent of the fiduciary.
Security Obligations: Where Most DPAs Are Weakest
DPDPA 2023 requires Data Fiduciaries to implement reasonable security safeguards. The same expectation flows to processors through the DPA.
The DPA security clause should not be vague. References to industry standard security practices invite disputes about what constitutes industry standard at any given time.
Specific security obligations to include:
Encryption. Data in transit (TLS 1.2 or higher). Data at rest (AES 256 or equivalent). Database level encryption. Backup encryption.
Access controls. Role based access control. Multi factor authentication for administrative access. Regular access reviews. Immediate revocation upon role change or termination.
Logging and monitoring. Detailed audit logs. Tamper resistant logging. Real time alerting on anomalous activity. Log retention period.
Vulnerability management. Regular vulnerability scanning. Penetration testing on defined cadence. Patch management within defined timelines based on severity.
Incident response. Documented incident response plan. Trained incident response team. Tabletop exercises on defined cadence.
Personnel security. Background checks for personnel with data access. Confidentiality obligations binding personnel post termination. Mandatory data protection training.
Physical security. Access controls to data centres. Visitor logs. Secure media disposal.
Business continuity. Backup procedures. Disaster recovery plan. Tested recovery time objectives.
Certification. ISO 27001, SOC 2 Type II, or equivalent. Annual recertification. Right to receive copies of audit reports.
Specificity in security obligations creates accountability. Vague clauses leave the fiduciary unable to enforce against actual security gaps until after a breach.
The Breach Notification Chain: 24 to 48 to 72
DPDP Rules 2025 require the Data Fiduciary to notify the Data Protection Board within 72 hours of discovering a personal data breach. If the breach occurs at the processor, the fiduciary may not even know about it.
The DPA must establish a notification chain that gives the fiduciary enough time to meet the 72 hour Board deadline.
Hour 0: Processor discovers a breach (security incident affecting personal data).
Hour 24 (Maximum): Processor notifies the fiduciary in writing. Notification must include the nature of the breach, the categories and approximate number of Data Principals affected, the categories and approximate number of records affected, the likely consequences, and the measures taken or proposed.
Hour 24 to 48: Fiduciary assesses the breach, gathers additional information, prepares Board notification, drafts Data Principal communication.
Hour 48 to 72: Fiduciary submits notification to the Data Protection Board, communicates with affected Data Principals, takes containment measures.
Without a 24 hour processor notification clause in the DPA, the fiduciary cannot reliably meet the Board's 72 hour deadline. The DPA should also require the processor to cooperate fully in investigation, provide forensic access if needed, and assist with Data Principal communications.
The penalty for failure to notify the Data Protection Board: up to 200 crore rupees. The DPA breach chain is not a paperwork exercise. It is the difference between meeting a 200 crore deadline and missing it.
Sub Processors: The Hidden Risk in Vendor Templates
Most processors do not perform all processing themselves. They engage sub processors: cloud infrastructure (AWS, Azure, GCP), customer support tools, analytics platforms, payment gateways, AI service providers. Each sub processor is another link in the chain. Each is another point of potential failure.
Vendor template DPAs typically grant general consent to sub processor engagement. The processor has the right to engage any sub processor at any time. The fiduciary has no visibility, no veto, no recourse.
A well drafted DPA replaces general consent with specific consent.
Initial sub processor list. The DPA includes a list of pre approved sub processors at execution. The fiduciary has reviewed and accepted these.
Notification of changes. The processor must notify the fiduciary in advance (typically 30 days) of any change to the sub processor list (additions, replacements). Notification gives the fiduciary an opportunity to object.
Right to object. The fiduciary has the right to object to a proposed sub processor on reasonable grounds. The processor must either find an alternative sub processor or permit the fiduciary to terminate without penalty if no alternative is acceptable.
Pass through obligations. The processor must impose on each sub processor contractual obligations equivalent to the DPA. The sub processor must be subject to the same security, breach notification, data return or deletion, and audit obligations as the processor.
Liability for sub processors. The processor remains liable to the fiduciary for sub processor acts and omissions. The fiduciary should not need to pursue sub processors directly to recover.
Vendor pushback on sub processor controls is predictable. Processors prefer general consent because it gives operational flexibility. The fiduciary's negotiation leverage is greatest before contract execution. Once the relationship begins, sub processor proliferation begins.
Audit Rights: How to Verify Without Disrupting
DPDPA expects fiduciaries to oversee processor compliance. Audit rights are the operational mechanism.
The DPA audit clause should specify:
Trigger and frequency. Routine audits annually. Trigger based audits upon material breach, regulatory enquiry, or material change in processor operations.
Scope. Security policies, technical safeguards, sub processor list, breach incident logs, training records, access controls, certifications. The processor cannot legitimately refuse audit on the operational areas covered by the DPA.
Mechanism. Direct audit by fiduciary personnel, or audit through an independent third party auditor. Most processors prefer third party audits because it limits direct fiduciary access to systems.
Notice period. Reasonable advance notice (30 days for routine audits, shorter for triggered audits).
Cost allocation. Fiduciary bears audit costs for routine audits. If the audit reveals material non compliance, audit costs shift to the processor.
Existing certifications. Processor may satisfy audit obligations through existing certifications (ISO 27001, SOC 2 Type II) and providing audit reports under NDA. The DPA should specify which certifications are acceptable.
Confidentiality. Audit findings are confidential. Information learned during audit may be used only for compliance verification.
Without audit rights, DPA compliance is faith based. With audit rights, it becomes verifiable.
Cross Border Transfer: Where Data Goes Matters
Many processors host data outside India. Cloud infrastructure may be in Singapore, Ireland, the US. Customer support may be in the Philippines or the US. Analytics may run on platforms based in the US or EU.
DPDPA 2023 does not impose blanket data localisation. Transfer outside India is permitted unless the central government notifies specific countries to which transfer is restricted.
However, sectoral regulators impose localisation:
RBI requires payment system data to be stored only in India. Foreign payment system operators must mirror data in India.
IRDAI requires insurance data to be stored in India.
SEBI requires investor data to be stored within Indian jurisdiction.
The DPA should address:
Permitted transfer locations. Specific list of countries and regions to which transfer is permitted.
Data residency. If data must be stored within India for sectoral compliance, the DPA must require the processor to maintain data residency.
Legal basis for transfer. Standard Contractual Clauses where required by destination country law (EU GDPR), equivalent protection certifications, explicit consent of Data Principals.
Restricted country contingency. If the central government later restricts a country to which the processor transfers data, the processor must repatriate the data within an agreed timeline.
Government access notification. If a foreign government accesses the data under foreign legal process, the processor must notify the fiduciary unless legally prohibited.
Cross border transfer terms are increasingly complex as more countries adopt data protection regimes with extraterritorial reach. Generic transfer clauses age quickly. The DPA should anticipate evolution.
Remediating Existing Vendor Contracts: A Sequenced Programme
An organisation likely has dozens or hundreds of vendor contracts that involve personal data processing. Most were drafted before DPDPA. None will satisfy the new requirements without amendment.
The remediation programme requires sequencing.
Inventory. Identify all vendor contracts that involve personal data. This requires consultation with procurement, IT, security, marketing, HR, customer service, and finance.
Risk classification. Tier vendors by risk. High risk: payment processors, cloud infrastructure, customer data platforms, AI service providers, large data volume processors. Medium risk: marketing tools, analytics, support tools. Low risk: niche tools with limited data.
Negotiation prioritisation. Begin negotiation with high risk vendors. They have the most operational impact and the longest negotiation timelines.
Template development. Develop a standard DPA template that you propose to all vendors. Vendors will counter with their own template. The negotiation is which template is the starting point.
Negotiation strategy. For large vendors with substantial leverage (AWS, Microsoft, Google), they will likely refuse fundamental changes to their template. Concessions need to be carefully selected. For mid sized vendors, more terms can be negotiated. For small vendors, your template will likely prevail.
Execution and tracking. Maintain a remediation tracker showing each vendor, status, and next action. Audit ready documentation.
Timeline. The DPDPA Phase III deadline is 13 May 2027. Working backwards, high risk vendor remediation should complete by mid 2026. Medium and low risk by end 2026. Final round of cleanup in early 2027.
Organisations that defer this programme will discover in 2027 that vendors are inundated with renegotiation requests and not all are willing to engage. Early movers get better terms.
What You Need to Know
You have hundreds of vendor contracts. The DPA between you and each one decides who pays when something goes wrong.
AMLEGALS drafts and negotiates DPAs across sectors: financial services, insurance, healthcare, technology, manufacturing, retail. We restructure your vendor base for DPDPA Phase III. Speak with us at [email protected].
[email protected]