Third-Party Data Processors And Privacy Compliance: Emerging Risks Under Digital Personal Data Protection Act, 2023
Aadhya Dadu
19 Sept 2026 11:00 AM IST

In contemporary times, businesses rarely process personal data entirely within the systems that they own and operate. Customer, employee, and vendor data now routinely passes through cloud infrastructure, Software-as-a-Service (“SaaS”) platforms, payroll administrators, customer-relationship-management systems, payment gateways, marketing and analytics tools, and background-verification agencies. Each additional vendor in this chain widens the perimeter across which an organisation's data obligations must be discharged, and correspondingly widens its exposure.
It therefore raises a real commercial question, does outsourcing the processing of personal data also imply outsourcing the regulatory responsibility for processing such data? Under the Digital Personal Data Protection Act, 2023 (the “DPDP Act/ Act”) read with the Digital Personal Data Protection Rules, 2025 (the “DPDP Rules/ Rules”) notified by the Ministry of Electronics and Information Technology (“MeitY”) on 13 November 2025, the answer is an unequivocal no.[1] The Act establishes accountability on the entity that determines the purpose and means of processing that is the 'Data Fiduciary', and for all processing undertaken by it or on its behalf is a 'Data Processor', and permits such engagement only under a valid contract.[2] Rule 6 of the notified Rules gives effect to the requirement for a Data Fiduciary to protect personal data in its possession or under its control, including processing undertaken on its behalf by a processor. It also includes the requirement that processor contracts must contain provisions obliging compliance with the same security safeguards.[3] A vendor may take on operational responsibility, but regulatory accountability cannot be delegated away.
Data Fiduciary and Data Processor:
The threshold question in any vendor relationship is one of characterization, not labeling. A data fiduciary decides the purpose and means of processing; whereas a data processor processes personal data on its behalf.[4] Cloud-hosting providers, payroll administrators, Customer Relationship Management (“CRM”) platforms and background-verification agencies are typically processors. But a contract that describes a vendor as a 'Data Processor' is not determinative if, in substance, the vendor retains independent discretion over why or how the data is used; for instance, by reserving the right to use client data for its own analytics or product development. The vendor may be a joint or independent fiduciary with its own direct duties under the Act, and not merely duties that flow through the client's contract. This classification determines everything that follows, including, the substance of the contract, the extent of the due diligence and the allocation of liability.
Key Risks:
Once a vendor is correctly identified as a data processor, the risks that attach to the relationship are practical rather than theoretical. Vendor onboarding frequently proceeds without answering basic questions such as, what data the vendor will access and why, where it will be stored, who within the vendor's organisation can see it, what security controls exist, and what happens to the data on termination. Data rarely stops at a single vendor as a realistic chain runs from the client to a primary vendor, to that vendor's sub-processors, to underlying cloud infrastructure, and often to further downstream providers. The longer this chain, the harder it becomes for the client to know with confidence where its data resides, who can access it, and whether it is genuinely and verifiably deleted. There are also sub-processing issues, where a vendor may itself outsource parts of processing to parties i.e., sub-processors, with whom the client has no direct contractual privity. This raises recurring questions of prior approval, flow-down of obligations and accountability if the sub-processor is the source of a failure.
These risks become starkly apparent in the event of a breach. A company may have strong internal cybersecurity, but the payroll vendor or CRM vendor may be breached and impact the same personal data. The Rules impose a direct duty on the data fiduciary to follow a strict two-stage notification process; firstly, on becoming aware of a breach, it must inform each data principal whose data has been breached, without delay; secondly, it must report to the Data Protection Board of India (the “Board”) with a full report containing the assessed impact and remedial measures within seventy-two hours, or such longer period as the Board may permit on being satisfied with a reasoned request.[5] That obligation lies on the data fiduciary, not the vendor, because a contract that does not require the vendor to give the company prompt notice, well within that window, leaves the company structurally incapable of meeting its own statutory deadline through no fault of its own. Rs. 250 crore for failure to implement reasonable security safeguards and Rs. 200 crore for failure to notify a breach under the Act[6].
That's why the privacy clause in a vendor contract can't be boilerplate anymore. A well-negotiated Data Processing Agreement (“DPA”) should set out precisely the scope and purpose of processing, and confirm that the vendor shall act only on documented instructions, the technical safeguards required under Rule 6 including encryption, control of access, monitoring and back-up arrangements[7], require prior approval or notice before sub-processors are engaged, with equivalent obligations flowing down the chain, and give the client meaningful audit rights, access to relevant certifications and periodic compliance reporting. Retention and deletion terms should be consistent with the data fiduciary's own obligations to erase under Rule 8, which requires return or destruction of data upon termination (including from back-ups) and written certification of same.[8]
Cloud, SaaS, and Artificial Intelligence Vendors:
The difficulty is most acute with cloud, SaaS and Generative-Artificial Intelligence (“GenAI”) vendors, where reliance is now embedded in almost every business function. A particularly current concern is the use of GenAI tools within the enterprise, the employees entering personal data into Artificial Intelligence (“AI”) platforms in the ordinary course of work, or a vendor's own AI features processing customer data and potentially using prompts or inputs to train or improve its models. Contracts with such vendors should explicitly include confidentiality of inputs, restriction on secondary use including for training of models, data retention within the platform and onward sub-processing to underlying foundation-model providers. The Act follows a similar logic of cross-border transfers of personal data, whereby transfer outside India is allowed except to jurisdictions restricted by notification by the government and also retains the government's power to impose additional conditions.[9] The global SaaS arrangements and intra-group sharing of data with an overseas parent should not be assumed to fall outside the fiduciary-processor framework simply by virtue of being within a single corporate group; the same questions of location, access and contractual protection apply with equal force.
Additionally, the relationship does not end at the end of the contract. There may be residual information in vendor databases. There may be back-ups on independent cycles. Sub-processors may have copies that were never returned. Logs may retain personal data long after termination. The Rules require the data fiduciary itself to delete personal data after the expiry of the specified period of retention, subject to prior notification and any overriding legal retention requirement[10], an obligation the data fiduciary cannot comply with unless its vendor contracts independently require deletion, destruction of back-ups and written certification on exit, including during migration to a replacement vendor.
Vendor Governance:
Third-party privacy risk should be managed as an enterprise risk. Use the volume and sensitivity of the data involved, and the importance of the relationship, to segment vendors. Due diligence, contractual requirements and ongoing monitoring should therefore be calibrated, with full due diligence and tailored terms for high-risks vendors dealing with sensitive or large volumes of data, proportionate terms for medium-risk relationships and a lighter, mostly self-certified process for the rest. Making sure that risk is actively considered and accepted, rather than inherited by negligence, is more important than producing paperwork.
The modern privacy perimeter doesn't end at the company's firewall. A company may have a comprehensive privacy policy, strong internal compliance procedures and robust cybersecurity and still have substantial regulatory and commercial exposure due to a third party processor over which it had insufficient contractual and operational control. The Digital Personal Data Protection compliance must evolve from a policy-centric exercise into an ecosystem-based governance model, in which vendor selection, contracting, cybersecurity, ongoing monitoring and exit management are treated as integral to privacy compliance rather than peripheral to it. The statute creates the legal obligation; commercial contracts and vendor governance determine whether a business can actually manage the risk that results. For general counsel and boards, the practical starting point remains simple: know every vendor that touches personal data, know precisely what each one does with it, and ensure the contract governing that relationship not merely the organisation's internal policy is capable of standing up to regulatory scrutiny.
DPDP Act 2023, S. 8(1),(2); DPDP Rules 2025, R. 6(1); MeitY, 'DPDP Rules, 2025 (Gazette Notification No. GSR 846(E), 13 November 2025). ↑
DPDP Act 2023, S. 2(i), (k) and S. 8(2). ↑
DPDP Rules 2025, R. 6(1) and R. 6(1)(f). ↑
DPDP Act 2023, S. 2(i),(k). ↑
DPDP Rules 2025, R. 7(1),(2); DPDP Act 2023, S. 8(6). ↑
Ibid. ↑
DPDP Rules 2025, R. 6(1)(a) to (e). ↑
Ibid, R. 8. ↑
DPDP Act 2023, S. 16. ↑
DPDP Rules 2025, R. 8. ↑
Author is an Advocate based in New Delhi. Views are personal.

