\n<\/p>\n
Contributor: Ankit Kumar (Research Fellow-LL.B Mania)<\/em> | Reviewer: Akanksha Vatsa<\/em><\/p>\n India\u2019s data protection landscape changed<\/a> permanently on 14 November 2025, when the Ministry of Electronics and Information Technology notified<\/a> the Digital Personal Data Protection Rules, 2025. These Rules operationalise the Digital Personal Data Protection Act, 2023<\/a>, India\u2019s first comprehensive personal data protection law.<\/p>\n For startup founders, the impact<\/a> is direct. Almost every business<\/a> today relies on third-party vendors, payroll tools, cloud hosting, CRM software, marketing platforms, and analytics services, and these processes involve personal data belonging to your customers or employees. Under the DPDP Act, a business that determines the purpose and means of processing personal data acts as the Data Fiduciary. Even where personal data is processed on its behalf by a Data Processor, the Data Fiduciary continues to bear the statutory responsibility for complying with the Act. In practical terms, outsourcing data processing does not outsource compliance.<\/p>\n The mechanism that governs this responsibility is the Data Processing Agreement, commonly referred to as a \u201cDPAs\u201d. It establishes how personal data may be processed, the security safeguards the processor must maintain, how data breaches are reported, and the consequences of non-compliance.<\/p>\n This guide explains when a DPA is required under the DPDP framework, the clauses it should contain, and the practical issues founders and legal teams should look for before signing any vendor agreement. Substantive compliance obligations under the DPDP Rules take full effect on 13 May 2027, but the time to prepare is now.<\/p>\n A Data Processing Agreement is a legally binding contract between a Data Fiduciary and a Data Processor that governs how personal data will be processed on behalf of the Data Fiduciary. It defines the processor\u2019s obligations relating to security, confidentiality, breach reporting, use of sub-processors, deletion or return of personal data, audit rights, and compliance with applicable data protection laws. Under India\u2019s DPDP framework, a well-drafted DPA is one of the most important contractual safeguards for managing vendor-related privacy risks.<\/p>\n The single most important principle underlying the DPDP Act is this: outsourcing data processing does not outsource compliance responsibility.<\/em><\/p>\n When you send your customers\u2019 or employees\u2019 personal data to a vendor, that vendor ordinarily acts as a Data Processor, an entity processing data on your instructions. For example, an AdTech Platform engages a Payment Gateway Service Provider to collect payments from its users on its platform.<\/p>\n The Act places the entire compliance burden on the Data Fiduciary. If your cloud service provider suffers a breach and your users\u2019 data is exposed, the Data Protection Board of India<\/a> will hold your business responsible. Penalties<\/a> for non-compliance with security safeguards can reach \u20b9250 crore per breach. That is why vendor oversight is no longer just an IT function; it is a legal and governance responsibility. Failure to report a breach carries a further penalty of up to \u20b9200 crore.<\/p>\n Hence, DPA is the contractual mechanism through which you bind your processors to meet the same standards the law demands of you. A well-drafted DPA enables the Data Fiduciary to impose contractual obligations on its vendors relating to security safeguards, confidentiality, breach notification, deletion of personal data, and regulatory cooperation. It also provides contractual remedies, including indemnity where agreed, if the processor breaches those obligations.<\/p>\n Under the provisions of the DPDP Act, there are two roles that have been distinguished clearly. Knowing which group your vendors belong to will help identify the type of agreement that needs to be executed.<\/p>\n A Data Fiduciary<\/strong> means a person or an entity who has determined the purpose and means of processing the personal data. Where a business determines its data requirements and how to use the data, that business is considered the Data Fiduciary. For example, when an e-commerce business decides that it should collect customer name and address information, a fintech firm chooses what transaction history should be kept, or a human resource management tool decides which employee details to store, they ordinarily act as the Data Fiduciary for that processing.<\/p>\n A Data Processor<\/strong> refers to a person or an entity that processes personal data for a Data Fiduciary as per the instructions of the Data Fiduciary. A Data Processor doesn\u2019t have an independent authority to determine the purpose of data processing. Typical Data Processors include payroll service providers processing employee salary records on behalf of an employer, cloud hosting providers storing customer databases, CRM platforms managing customer information under client instructions, outsourced customer-support providers, and managed IT service providers.<\/p>\n The basic test here is whether a vendor decides for itself what data to collect and why, or merely follows your instructions in data processing.<\/em> Where the latter scenario applies, it is a Data Processor, and thus, a DPA should be signed.<\/p>\n Where the vendor has an independent role in data collection, it may be a different Data Fiduciary requiring users\u2019 permission to process the data. Some vendors, particularly SaaS providers, may perform both roles for different processing activities<\/em>. Businesses should therefore classify each processing activity carefully instead of automatically executing a DPA in every situation.<\/p>\n Yes, where a business engages a Data Processor to process personal data on its behalf, the DPDP Act requires that engagement to be governed by a valid contract. Section 8(2) of the Digital Personal Data Protection Act, 2023 permits a Data Fiduciary to engage a Data Processor only under a valid contract. While the Act does not prescribe a document specifically titled a \u201cData Processing Agreement\u201d, businesses typically satisfy this requirement through a standalone DPA<\/em>, a data-processing addendum<\/em>, or comprehensive data-processing provisions<\/em> within the principal vendor agreement.<\/p>\n Further, the substantive obligations most relevant to DPAs, security safeguards, breach notification, data principal rights, and cross-border transfers take effect on 13 May 2027.<\/p>\n Businesses should not wait until May 2027. Drafting and implementing a DPA framework across all vendor relationships takes considerable time, and the 18-month runway exists precisely to allow for proper preparation.<\/p>\n A Data Processing Agreement should do far more than merely allocate contractual risk. It should clearly define how personal data will be processed, identify the parties\u2019 respective responsibilities, and establish practical safeguards enabling the Data Fiduciary to comply with its statutory obligations under the DPDP Act. Although the Act does not prescribe a clause-by-clause template, the following provisions are considered essential in practice.<\/p>\n The agreement should clearly define the scope, purpose and duration of processing, the categories of personal data involved, the categories of Data Principals affected and the specific processing activities authorised by the Data Fiduciary.<\/p>\n The processor should process personal data only in accordance with documented instructions and should not use the information for any independent commercial purpose unless separately authorised by law or contract.<\/p>\n Without clear contractual limitations, the processor may use personal data beyond the agreed business purpose, making compliance monitoring significantly more difficult for the Data Fiduciary.<\/p>\n Every individual at the processor\u2019s organisation who accesses your personal data, whether a permanent employee, a contractor, or temporary staff, must be bound by a confidentiality obligation. Data breaches frequently originate from insiders, not external attackers. This clause creates both contractual and personal accountability for employees who misuse data, and it signals to the vendor that they must implement proper internal access controls. The DPA should also require the processor to maintain an access log and revoke access immediately upon personnel departure.<\/p>\n The DPDP Rules, 2025, prescribe minimum technical and organisational safeguards; hence, your DPA must contractually require the processor to implement all of these. Under Section 8(5) of the Act, you remain liable for security failures caused by your processor\u2019s negligence. The DPA does not transfer that statutory liability, but it gives you a right of contractual recourse when the failure is the vendor\u2019s fault.<\/p>\n Under Rule 7 of the DPDP Rules, you, as the fiduciary, are required to notify the Data Protection Board of India within 72 hours of becoming aware of a breach, with full details of the cause, scope, mitigation measures, and remedial steps. You must also notify each affected data principal. Separately, under the CERT-In Directions, 2022, cybersecurity incidents, including data breaches, must be reported to the Indian Computer Emergency Response Team within 6 hours of detection. This means a breach may simultaneously trigger two reporting obligations to two different authorities under two distinct legal regimes. Your vendor typically becomes aware of a breach before you do, and any delay in their notifying you could cause you to miss both deadlines.<\/p>\n While the DPDP Rules do not themselves prescribe a specific notification window between processor and fiduciary, the CERT-In 6-hour reporting<\/a> obligation makes it commercially essential to require the processor to notify you as early as possible upon discovering a breach. It is recommended to include a contractual notification window of 6 hours in your DPA to ensure you have sufficient time to meet the CERT-In deadline in parallel with the DPDP 72-hour obligation<\/a>. No materiality threshold should apply, meaning all breaches must be reported regardless of apparent severity. The notification must include the date and time of the breach, categories of data affected, estimated number of individuals impacted, likely consequences, and steps already taken to contain it. The processor must cooperate fully with your investigation, and where the breach arose from the processor\u2019s fault, all costs of notification and remediation must be borne by the processor.<\/p>\n Suppose a payroll service provider suffers a ransomware attack affecting employee salary records. Although the processor discovers the incident first, the employer acting as the Data Fiduciary remains responsible for complying with its statutory breach-notification obligations. A well-drafted DPA therefore ensures that the processor immediately escalates the incident, shares all relevant technical information, and cooperates throughout the investigation and notification process.<\/p>\n A sub-processor is any third party that your primary vendor engages to carry out part of the data processing. Your CRM vendor might use a separate cloud database provider, your payroll tool might use a third-party email service, and so on. Your data flows through all of these sub-processors without your direct knowledge unless the DPA requires disclosure and prior approval.<\/p>\n Your DPA must require the processor to obtain your prior written approval before engaging any new sub-processor, provide at least 30 days\u2019 advance notice of proposed changes, impose data protection terms on each sub-processor that are at least as stringent as your DPA, and remain fully liable to you for any failure by a sub-processor. The agreement should maintain or incorporate an up-to-date list of material sub-processors together with the services they perform and, where relevant, the countries in which they process personal data.<\/p>\n The DPDP Act grants Data Principals several important rights, including the right to access information relating to the processing of their personal data, seek correction, completion, updating or erasure of personal data, nominate another person to exercise their rights in certain circumstances and seek grievance redressal. These rights must be fulfilled by you as the fiduciary within prescribed timelines, but the actual data typically sits with your processor. Your DPA must obligate the processor to forward any data principal request it receives directly to you within 24 hours, and to provide you with the technical capability needed to fulfil correction and deletion requests promptly.<\/p>\n When your relationship with a vendor ends, or at any point you request it, the processor must delete or return all personal data in its possession within 30 days. This includes all copies, backups, and data held by sub-processors. The processor must provide written certification confirming the date, method, and scope of deletion. Processing logs must be retained for a minimum of one year after deletion and made available to you for audit purposes. Data that lingers with a former vendor is both a security risk and a compliance liability.<\/p>\n You must have the contractual right to verify that the processor is actually complying with the DPA\u2019s obligations. This means the right to audit compliance directly or through an independent third-party auditor, with reasonable advance notice in ordinary circumstances and the right to conduct an unannounced audit in the event of a suspected breach. The processor should also be required to share copies of any third-party security certifications they hold, such as ISO 27001<\/a> or SOC 2 reports<\/a>.<\/p>\n Many organisations rely on generic GDPR-based Data Processing Agreements without adapting them to the DPDP Act. Common drafting mistakes include incorrectly classifying vendors as Data Processors, failing to define the permitted processing purpose, omitting breach-escalation procedures, overlooking sub-processor arrangements, ignoring deletion obligations and assuming that statutory liability automatically shifts to the processor through contractual indemnities. Periodic review of vendor agreements is therefore as important as executing the DPA itself.<\/p>\n The liability regime of your DPA requires close scrutiny. The liability caps of most vendors limit their maximum exposure to the cost of their fee structure, which may be either a monthly subscription or a yearly subscription. If your business has a monthly fee structure for the use of SaaS technology of \u20b950,000, then your liability cap will come up to \u20b96 lakhs. This is an extremely low value for your liability cap if the processor\u2019s violation leads to a statutory penalty of up to \u20b9250 crore imposed by the regulator on your business.<\/p>\n Your DPA needs to create a three-part liability regime. A cap of 100% to 200% of the annual fee is appropriate in case of general contractual breaches that have nothing to do with the breach. In case of a data breach caused by the processor, a super cap should be established at 2X to 3X annual fees. Third-party claims, including regulatory penalties, compensations due to the data principal, and legal costs related to non-compliance on the part of the processor, cannot be covered by a cap. No cap at all should exist for the indemnity clause in relation to such third-party claims.<\/p>\n The indemnity clause shall provide for compensating your business against any regulatory fine levied by the Data Protection Board of India as a result of the processor\u2019s breach\/noncompliance, compensation awarded to data principals as a result of processing failure, and the legal costs involved in making the processor pay damages.<\/p>\n Yes. The DPDP Act does not distinguish between startups and established businesses when a vendor processes personal data on their behalf. Whether a company has ten customers or ten million, outsourcing customer or employee data to cloud providers, payroll platforms, CRM software or other service providers should be governed by an appropriate contractual framework. Early-stage startups can often incorporate data-processing clauses within their existing vendor agreements instead of negotiating a lengthy standalone DPA.<\/p>\n Before signing a vendor agreement involving personal data, confirm that:<\/p>\n Where a Data Fiduciary engages a Data Processor to process personal data on its behalf, the engagement must be governed by a valid contract under Section 8(2) of the DPDP Act. That contract may take the form of a standalone Data Processing Agreement or appropriate clauses within a vendor agreement.<\/p>\n Yes. The DPDP Act does not require a separate document titled \u201cData Processing Agreement\u201d. Suitable data-processing provisions may be incorporated into the principal vendor agreement, provided they adequately govern the processor\u2019s obligations.<\/p>\n The Data Fiduciary remains responsible under the DPDP Act for compliance in respect of processing undertaken on its behalf by the Data Processor. However, the DPA may provide contractual remedies against the processor where the breach results from its failure to comply with the agreement.<\/p>\n Not necessarily. The requirement depends on whether the SaaS provider processes personal data on behalf of the customer as a Data Processor or processes data for its own independently determined purposes as a Data Fiduciary. Some SaaS providers perform both roles depending on the processing activity.<\/p>\n Yes. Many businesses address DPDP compliance by executing a short data-processing addendum that supplements their existing Master Services Agreement or vendor contract instead of replacing the entire agreement.<\/p>\n The DPDP Act fundamentally reframes how Indian businesses must approach vendor relationships. By placing exclusive liability on the Data Fiduciary for all processing, including processing performed by third-party vendors, the Act makes the Data Processing Agreement one of the most consequential legal documents a startup can execute.<\/p>\n A DPA under the DPDP regime is not a formality to be copied from a template and filed away. It is a risk allocation instrument that, when properly drafted, protects your business from potentially ruinous regulatory penalties by contractually binding the processor to your own legal obligations and creating enforceable rights of recovery when those obligations are breached.<\/p>\n Businesses that begin reviewing their vendor contracts before the substantive compliance obligations become operational will be better placed to implement the DPDP framework efficiently. Preparing a vendor inventory, classifying processing activities, and updating existing agreements now will significantly reduce compliance risks once the full regulatory regime is in force.<\/p>\n <\/p>\n <\/p>\n
Contributor: Ankit Kumar (Research Fellow-LL.B Mania) | Reviewer: Akanksha Vatsa Introduction India\u2019s data protection landscape changed permanently on 14 November 2025, when the Ministry of Electronics and Information Technology notified the Digital Personal Data Protection Rules, 2025. These Rules operationalise the Digital Personal Data Protection Act, 2023, India\u2019s first comprehensive personal data protection law. Home […]<\/p>\n","protected":false},"author":1,"featured_media":360682,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[182016,182019,182020,182021,182017,182018,116860],"tags":[23159,40293,11603,182022,157482,116862,182023,1780,10048,23233],"dealstore":[],"offerexpiration":[],"class_list":["post-360681","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-clause-risk-notes","category-data-processing-agreement","category-dpa","category-dpdpa-safeguards","category-law-of-contracts","category-practical-guides","category-technology-law","tag-agreements","tag-clauses","tag-data","tag-data-processing-agreement","tag-dpa","tag-dpdpa","tag-dpdpa-safeguards","tag-essential","tag-processing","tag-vendors"],"yoast_head":"\nIntroduction<\/h2>\n
What is a Data Processing Agreement (\u201cDPA\u201d)?<\/strong><\/h2>\n
Why Every Business Using Third-Party Vendors Needs a Data Processing Agreement?<\/h2>\n
The Two Roles: Data Fiduciary and Data Processor<\/h2>\n
Is a DPA Legally Mandatory?<\/strong><\/h2>\n
(i)\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Processing Instructions and Purpose Limitation<\/h2>\n
(ii)<\/strong> Confidentiality Obligations<\/strong><\/h2>\n
(iii)\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Security Safeguards<\/h2>\n
(iv)\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Breach Notification<\/h2>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Practical Example<\/strong><\/h3>\n
(v)\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Sub-Processor Controls<\/h2>\n
(vi) Data Principal Rights<\/strong><\/h2>\n
(vii)\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Data Deletion and Return<\/h2>\n
(viii)\u00a0\u00a0\u00a0\u00a0\u00a0 Audit Rights<\/h2>\n
Common Mistakes Businesses Make While Drafting DPAs<\/strong><\/h2>\n
Liability and Indemnity<\/h2>\n
Should Small Startups Also Sign a DPA?<\/strong><\/h2>\n
A Checklist for Founders<\/h2>\n
\n
Frequently Asked Questions<\/span><\/strong><\/h2>\n
1. Is a Data Processing Agreement mandatory under the DPDP Act?<\/strong><\/h2>\n
2. Can a vendor agreement replace a standalone DPA?<\/strong><\/h2>\n
3. Who is responsible if the vendor causes a data breach?<\/strong><\/h2>\n
4. Should every SaaS provider sign a DPA?<\/strong><\/h2>\n
5. Can an existing vendor agreement be amended instead of signing a new DPA?<\/strong><\/h2>\n
Conclusion<\/h2>\n
\n\t\t\t\t Post Views:<\/span> 94<\/span>
\n\t\t\t<\/p>\nRelated<\/em><\/h3>\n<\/p><\/div>\n\n","protected":false},"excerpt":{"rendered":"