A practical five-step framework for managing vendor risk under DPDP — classifying Fiduciaries vs. Processors, building enforceable contracts, and closing the gaps that create real compliance exposure.
A business can spend months getting its own consent flows, notices, and internal data practices right — and still carry significant DPDP exposure through a vendor most people in the compliance team have never directly interacted with. The payroll processor, the marketing automation platform, the cloud host, the customer support chatbot vendor, the logistics partner that gets a customer's address to fulfill an order — every one of these is a third party the Act holds you accountable for, whether or not you control what happens inside their systems.
This is the part of DPDP compliance that's easiest to underestimate, because the risk sits outside the organization's own walls. It's also one of the areas the Act treats with the least room for ambiguity: the Data Fiduciary's accountability doesn't stop where the vendor's system begins.
Why Vendor Risk Is Your Risk
Section 8 of the DPDP Act makes a Data Fiduciary responsible for compliance in respect of processing undertaken on its behalf by a Data Processor, regardless of what any contract says to the contrary. That single principle is the foundation of third-party risk management under the Act: outsourcing the processing doesn't outsource the accountability. If a vendor mishandles data, loses it, or uses it beyond the agreed purpose, the Data Fiduciary is still the party the Data Protection Board looks to first.
Step One: Classify Every Vendor Correctly
Not every third party is a Data Processor, and getting this classification wrong distorts everything downstream. The test is functional, not commercial: whoever determines the purpose and means of processing is the Data Fiduciary; whoever processes strictly on another party's instructions is the Processor.
| Vendor Type | Typical Role | Why |
|---|---|---|
| Cloud hosting provider | Data Processor | Stores/processes data purely on your instructions |
| Payroll or HR software vendor | Data Processor | Processes employee data for your stated purpose |
| Marketing automation platform | Data Processor (usually) | Sends campaigns per your instructions — unless it independently reuses the data for its own purposes |
| Analytics or ad-tech vendor | Often a joint or independent Data Fiduciary | May determine its own purposes for using the data (e.g., cross-client profiling) |
| Logistics/delivery partner | Data Processor for delivery, but becomes a Fiduciary if it also markets to those contacts | Role can shift depending on how the data is subsequently used |
| Referral partner or another business you share leads with | Data Fiduciary in its own right | Determines its own purpose for the data once received |
The most common misclassification error is treating every counterparty as a processor by default. A vendor that starts using the data you've shared for its own purposes — model training, its own marketing, aggregate analytics for other clients — has effectively become a Data Fiduciary for that use, and your original consent or contract doesn't automatically cover it.
Step Two: Build Contracts That Actually Say Something
Section 8(2) requires that a Data Fiduciary engage a Data Processor only under a valid contract. A vague "processor shall comply with applicable law" clause technically exists but does little to protect the Fiduciary if something goes wrong. A working contract needs specificity:
- Defined scope — exactly which data fields and purposes the vendor is authorized to process, not an open-ended reference to "customer data"
- No independent reuse — an explicit bar on using the data for the vendor's own purposes, including analytics, model training, or resale, without separate written authorization
- Sub-processor visibility — disclosure of any further parties the vendor engages, with advance notice of changes
- Security commitments — specific, verifiable measures (encryption, access controls, log retention) rather than generic assurances
- Breach notification timeline — a window tight enough for the vendor's notice to reach you well within your own 72-hour reporting obligation to the Board
- Erasure and exit terms — confirmed deletion on termination or consent withdrawal, with a defined process for verifying it happened
- Audit rights — your ability to request evidence of compliance, not just take the vendor's word for it
Step Three: Due Diligence Before Signing, Not After
Vendor risk assessment works best before a contract is signed, not as a retroactive fix once a relationship is already live. A practical due-diligence pass should look at the vendor's own security posture, whether they've had prior breach incidents, how many further sub-processors they rely on, and whether their systems are located in a jurisdiction relevant to any future government-notified transfer restrictions.
On that last point, it's worth being precise: Section 16 of the DPDP Act takes a "negative list" approach to cross-border data transfers — transfers are permitted by default, restricted only to countries the Central Government specifically notifies. As of now, no such restricted-country list has been issued, which means cross-border vendor relationships aren't automatically problematic under DPDP specifically. That said, sector-specific rules — such as the Reserve Bank of India's data-localization requirements for payment data — can impose stricter conditions that continue to apply regardless of what the DPDP framework itself permits.
Step Four: Monitor, Don't Just Contract
A signed agreement at onboarding doesn't guarantee ongoing compliance. Vendors change their sub-processors, get acquired, migrate infrastructure, or quietly expand what they do with client data over time. An ongoing third-party risk program needs:
- Periodic reconfirmation that the vendor's practices still match the contract terms
- A process for reviewing sub-processor changes as they're disclosed
- A mechanism to test — not just assume — that a consent withdrawal or erasure request actually propagates to the vendor's systems
- Re-assessment triggers tied to events like a vendor's own reported breach, a change in ownership, or a significant product change
Step Five: Plan the Exit Before You Need It
The riskiest moment in many vendor relationships is the end of it — when a contract terminates and nobody has confirmed what happens to the data the vendor was holding. An exit runbook, agreed at onboarding rather than negotiated during an already-tense termination, should specify how data gets returned or destroyed, what confirmation of deletion looks like, and how quickly access gets revoked once the relationship ends.
Bringing the Vendor Landscape Into One View
Most organizations don't have a single, current list of every third party touching their personal data — it's scattered across procurement records, individual department relationships, and contracts signed years before anyone was thinking about DPDP. Building that inventory, classifying each relationship correctly, and closing the gaps in existing contracts is detailed work, but it's also where a meaningful share of an organization's actual compliance exposure sits.