Engaging a KYC vendor, cloud provider, or email platform under DPDPA doesn't transfer your legal accountability — it multiplies where it can go wrong.
July 2026 · 6 min read
We hear a version of the same line often, from compliance teams at companies of every size: "That's on our KYC vendor" or "the email platform handles storage, that's their problem." It's an understandable instinct. It doesn't survive a read of Section 8 of the DPDPA.
The moment you bring in a Data Processor — any vendor, SaaS platform, cloud provider, or analytics firm handling personal data on your behalf — you remain the accountable party. Not jointly accountable with them. You, the Data Fiduciary, alone. That's not a footnote in the framework; it's the structural premise the whole Act is built on, and it's exactly how the Data Protection Board of India will act on a breach.
The obligations around engaging processors sit across four sub-sections, and read together they're unambiguous.
Section 8(2) requires you to ensure your processor only processes personal data for the purpose that consent was given for, and only as you've instructed. Their compliance is your responsibility, in full.
Section 8(3) makes a written contract mandatory before you can engage a processor at all. That contract has to define the scope of data covered, the permitted purpose, the security safeguards required (aligned to Rule 6), and what happens to the data on deletion.
Section 8(6) is where the cost lands. If your processor causes a breach, the Board's penalty falls on you, the Fiduciary — not the processor. Your contract with them is, from the Board's perspective, a private dispute between two commercial parties. The regulatory exposure is yours because you're the one who chose, onboarded, and signed with them.
Section 8(7) extends this to erasure. When a Data Principal withdraws consent, you have to erase their data, and that instruction has to reach every processor holding it. If your email tool still has a contact record months after withdrawal because nobody triggered the deletion request, that's your compliance failure — not the vendor's.
Picture a D2C brand running email campaigns. They collect consent for promotional messaging on their website, and use a third-party email automation platform for segmentation and sends.
That platform, like a lot of SaaS products, has a clause buried in its Terms of Service letting it use aggregated or "anonymised" customer-list data to improve its own analytics. The brand signed up and clicked accept.
Under the DPDPA, the brand's consent covered marketing communications. The platform is now using that same data for something else entirely — its own product analytics — without any consent obtained for it. Because the brand is the Data Fiduciary, that overreach is the brand's problem, regardless of who actually did the processing.
In our experience, most companies don't scrutinise vendor T&Cs to this level before signing. The DPDPA gives them a strong reason to start.
The uncomfortable reality: most vendor agreements signed in India today weren't written with DPDPA in mind at all. They're standard SaaS subscription terms, and they typically say nothing about sub-processors the vendor relies on (there are usually several — cloud infrastructure, monitoring, support tooling), breach notification timelines and obligations, confirmed deletion at termination or on consent withdrawal, or security standards aligned to Rule 6.
Signing that as-is leaves a gap the Board can walk straight through. A generic T&C silent on these points doesn't, in our view, satisfy Section 8(3)'s requirement for a valid governing contract.
Every DPA signed after DPDPA commencement should, at minimum, cover:
None of this is unusual — it's the baseline any responsible processing relationship should document anyway. The structural problem in India is that no equivalent of a GDPR-style vendor certification exists yet for buyers to shorthand this with. Until the framework matures further, the burden of verifying processor adequacy sits with you, contract by contract.
The practical starting point is simply knowing who your processors are. Most organisations we work with — even ones with mature compliance programmes — have an incomplete picture. Shadow IT, departmental SaaS subscriptions, and legacy integrations reliably surface vendors nobody remembered were touching personal data.
A register audit runs in three steps: list every vendor that receives, stores, or processes personal data on your behalf; check whether a DPDPA-aligned contract actually exists for each; and flag the gaps — no contract, generic T&Cs, or a processing scope in the contract that doesn't match what the vendor actually receives.
That last category deserves special attention. A contract permitting "user profile data" while the vendor actually receives transaction history and behavioural data is a real gap, even though a signed contract technically exists.
Keep the register live. When you add a new analytics tool or swap your SMS provider, it should update that day, not at the next annual review.
Under DPDPA, your accountability as a Data Fiduciary doesn't shrink when data leaves your systems — it extends to every processor you engage. Section 8 makes that a structural requirement, with real penalties attached. A processing agreement isn't paperwork; it's your primary lever for governing data you remain legally responsible for.
Closing this gap starts with the contracts themselves — our vendor agreement review checks whether your existing processor contracts actually protect you.
30 minutes to talk through your specific data footprint — no obligation.
Book a Consultation