Under DPDPA, Data Fiduciaries are accountable for how their vendors handle personal data — here is what every vendor data processing agreement must include, how to audit the sub-processor chain, and what happens when a processor causes a breach.
How DPDPA Defines "Data Processor" and Why the Definition Matters
The Digital Personal Data Protection Act 2023 defines a Data Processor as "any person who processes personal data on behalf of a Data Fiduciary." This is a straightforward principal-agent relationship: the Fiduciary determines the purpose and means of processing; the Processor carries out the processing as directed.
Who is a Data Processor in practice? Almost every SaaS tool your organisation uses. Your CRM is a processor. Your cloud storage provider is a processor. Your analytics platform is a processor. Your payroll software vendor is a processor. Any vendor whose product or service involves receiving, storing, or processing your customers' or employees' personal data is operating as a Data Processor under DPDPA.
This matters because the accountability chain under DPDPA is explicit: the Data Fiduciary is responsible for ensuring that every Data Processor they engage complies with DPDPA's requirements. This is not discharged by signing a contract. It requires active oversight — vendor selection criteria, contractual obligations, and periodic verification that processors are actually complying.
Data Fiduciary Accountability for Processor Conduct
Section 8(3) of DPDPA states that the Data Fiduciary shall be responsible for compliance with the Act, even where processing is carried out by a Data Processor on behalf of the Fiduciary. This is the accountability provision that puts the Fiduciary squarely in the frame when a processor causes a breach or commits a violation.
The implication is significant: if your CRM vendor suffers a breach that exposes your customers' personal data, the breach notification obligation falls on you — not on the vendor. The Data Protection Board will look to the Data Fiduciary first. Whether you can then seek indemnity from the vendor is a contractual matter between you and them; it doesn't change your obligations to the Board and to affected Data Principals.
This accountability structure creates a direct incentive to:
- Select processors carefully, not just on price and feature set
- Include DPDPA compliance obligations in vendor contracts, not just data security warranties
- Audit processor compliance periodically, not just at contract signing
- Terminate processors who cannot demonstrate ongoing compliance
What Every Vendor Data Processing Agreement Must Include
Under DPDPA, the contract between a Data Fiduciary and a Data Processor must be in writing and must address the processor's obligations under the Act. The following elements are essential in every vendor DPA for DPDPA compliance:
- Scope of processing: Exactly what personal data the processor will receive, for exactly what purposes, for exactly how long
- Processing instructions: The processor may only process personal data as instructed by the Fiduciary — not for the processor's own purposes
- Security obligations: The processor must implement and maintain reasonable security safeguards appropriate to the risk, and must notify the Fiduciary immediately (and in any event within 24 hours) of any personal data breach
- Sub-processor restrictions: The processor may not engage sub-processors without prior written consent from the Fiduciary, and must impose equivalent obligations on sub-processors
- Audit rights: The Fiduciary must have the right to audit the processor's data protection practices, either directly or through an independent auditor
- Data return and deletion: On termination of the agreement, the processor must return or delete all personal data in its possession, with a certification of deletion
- Data localisation compliance: If applicable, the processor must store and process personal data within India or in approved countries only
Sub-Processor Obligations: The Chain of Accountability
Most SaaS vendors don't operate alone — they use sub-processors for specific functions: cloud infrastructure, payment processing, analytics, email delivery, customer support tooling. Under DPDPA, the sub-processor chain matters because each link in the chain is touching your Indian customers' personal data.
Your vendor agreement should require:
- Advance notification before any new sub-processor is engaged, with an opportunity for you to object
- The vendor to impose the same data protection obligations on sub-processors that you have imposed on the vendor
- The vendor to remain liable for the actions of their sub-processors — they cannot escape accountability for a sub-processor breach by pointing to the sub-processor contract
- The vendor to provide a current list of sub-processors on request
In practice, large SaaS platforms publish their sub-processor lists publicly. Reviewing these lists before vendor onboarding — and checking whether sub-processors store data in India or in approved countries — is a reasonable due diligence step for any vendor who will process significant volumes of Indian personal data on your behalf.
The Processor Accountability Audit: What to Check Before Onboarding
A pre-onboarding processor accountability audit doesn't require a full security assessment for every vendor. A risk-tiered approach works: high-risk processors (those receiving sensitive personal data or large volumes of personal data) get full due diligence; lower-risk processors get a lighter review.
For high-risk processors, the pre-onboarding checklist should include:
- What security certifications does the vendor hold? (ISO 27001, SOC 2 Type II, ISNP certification for Indian vendors)
- Where is personal data stored? In India? In approved countries under DPDPA? In countries that require specific SCCs?
- Does the vendor have a documented incident response procedure with breach notification timelines?
- Does the vendor have a published sub-processor list?
- What rights do you have to audit the vendor's data protection practices?
- What is the vendor's data retention and deletion policy?
The answers to these questions should inform both the vendor selection decision and the contractual requirements you include in the DPA. A vendor who cannot answer these questions does not have adequate data protection practices — a warning sign worth acting on before onboarding, not after a breach.
Managing the Processor Registry at Scale
Large organisations with dozens or hundreds of vendors quickly discover that maintaining an up-to-date processor registry manually is unsustainable. The registry needs to be a living document — updated when vendors are onboarded or offboarded, when vendor sub-processor lists change, when contract renewals occur, and when vendor compliance status changes.
The minimum processor registry should contain, for each vendor: the vendor's legal name and contact, the categories of personal data they receive, the purposes for which they process it, the countries where they store or process it, the DPA reference, and the last review date.
Consentica by OpenBlockAI includes a Processor Registry as part of its consent governance infrastructure — linking each consent purpose to the processors authorised to process data under that purpose. When a Data Principal withdraws consent for a specific purpose, the withdrawal propagation reaches all registered processors for that purpose automatically, with delivery confirmation logged to the audit trail. This closes the gap between consent management and processor accountability that manual processes cannot bridge at scale.