The Liability Doesn't Leave with the Data
There's a misunderstanding we encounter regularly when working with compliance teams at mid-size and enterprise companies in India. It goes like this: "We've outsourced that to our KYC vendor" or "The email platform handles storage, it's their problem." The logic feels reasonable until you read Section 8 of the Digital Personal Data Protection Act, 2023.
The moment you engage a Data Processor, any vendor, SaaS platform, cloud provider, or analytics firm that handles personal data on your behalf, you remain the accountable party. Not jointly accountable. You. The Data Fiduciary. This isn't a technicality. It's the structural premise of how DPDPA assigns responsibility, and the Data Protection Board of India (DPBI) will act on it accordingly.
What Section 8 Actually Says
The obligations on Data Fiduciaries when engaging processors are spelled out across Section 8(2), 8(3), 8(6), and 8(7), and together, they paint a clear picture.
Section 8(2) requires that the Data Fiduciary ensure the processor only processes personal data for the purpose for which consent was obtained and only as instructed by the Fiduciary. The Fiduciary is responsible for the processor's adherence. Full stop.
Section 8(3) makes the contract non-optional. You cannot engage a Data Processor without a valid written agreement. That contract must define: the scope of data being processed, the purpose for which it can be used, the security safeguards required (aligned with Rule 6 of the Draft Rules), and the deletion obligations when processing ends.
Section 8(6) is where it gets expensive. If a Data Processor causes a personal data breach, the DPBI penalty lands on the Data Fiduciary, not the processor. Your contract with the processor is, in the DPBI's eyes, a civil matter between two private parties. The regulatory accountability is yours because you chose the vendor, onboarded them, and signed the agreement.
Section 8(7) extends erasure obligations downstream. When a Data Principal withdraws consent, the Fiduciary must erase the data, and that instruction must flow to every processor handling that data. If your email automation tool still holds a contact record after consent withdrawal because you never triggered a deletion request, that's your compliance failure, not the tool vendor's.
A Scenario We've Seen Play Out
Consider a D2C brand running email marketing campaigns. They collect consent for promotional communications through their website. They use a third-party email automation platform to manage campaigns, segmentation, and send scheduling.
The email platform, like many SaaS products, has a clause buried in their Terms of Service allowing them to use aggregate or anonymised data from customer lists to improve their own product analytics. The D2C brand signed up and clicked "I agree."
Under DPDPA, the brand obtained consent for marketing communications. The processor is using that data for something else entirely, their own analytics. The processor didn't obtain consent; they processed data beyond the scope the brand's consent covered. And because the brand is the Data Fiduciary, the brand is accountable for that overreach.
In our experience, most companies don't review SaaS T&Cs at this level before onboarding. The DPDPA creates a hard incentive to change that.
The Problem with Generic SaaS T&Cs
Here's the uncomfortable truth: the majority of vendor contracts in India today were not written with DPDPA in mind. They're generic SaaS subscription agreements that say nothing about:
- Sub-processors the vendor uses (and there are usually several, cloud infra, monitoring tools, support systems)
- Obligations to notify the Fiduciary in the event of a breach, and within what timeframe
- Confirmation of deletion at contract termination or on consent withdrawal
- Security standards aligned with Rule 6 requirements
Signing these agreements as-is creates a compliance gap the DPBI can walk straight through. In our view, a generic T&C that doesn't address DPDPA obligations does not satisfy Section 8(3)'s requirement for a valid contract governing the processing relationship.
What a Compliant Processor Contract Looks Like
We'd argue that every Data Processing Agreement (DPA) signed after DPDPA commencement should include, at minimum:
- Processing scope: what categories of personal data are covered, the specific purposes permitted, and an explicit prohibition on processing for the processor's own purposes
- Security standard: a requirement that the processor meet the technical and organisational safeguards specified in Rule 6, not just "reasonable security"
- Sub-processor disclosure: the processor must list all sub-processors and seek the Fiduciary's approval before adding new ones
- Breach notification timeline: the processor must notify the Fiduciary within a defined window (24-48 hours is our recommendation) so the Fiduciary can meet their own DPBI notification obligation
- Deletion confirmation: on contract termination or on Fiduciary instruction following consent withdrawal, the processor must confirm deletion in writing within a defined period
None of these are exotic requirements. They are the minimum a responsible processing relationship needs to document. The challenge in India is structural: in markets where GDPR compliance operates as a vendor credential, buyers can shorthand this by asking for a certification. No equivalent designation exists under DPDPA today. The next version of the regulatory framework is expected to address this. Until it does, the burden of verifying processor adequacy sits entirely with the Data Fiduciary, contract by contract.
Conducting a Data Processor Register Audit
The practical starting point is knowing who your processors are. In our experience, most organisations, even those with active compliance programs, have a partial picture at best. Shadow IT, departmental SaaS subscriptions, and legacy integrations routinely surface vendors no one remembered were processing personal data.
A Data Processor Register audit involves three steps: first, enumerate every vendor that receives, stores, or processes personal data on your behalf; second, check whether a DPDPA-aligned contract exists for each; third, flag the gaps, vendors with no contract, vendors with generic T&Cs, and vendors where the processing scope in the contract doesn't match actual data flows.
That third category deserves particular attention. A contract that permits processing of "user profile data" but where the vendor actually receives transaction history and behavioural data is a gap, even if a contract technically exists.
The register is also a live document. When you add a new analytics integration or swap your cloud SMS provider, the processor register should update on day one, not at the next annual review.
The Bottom Line
Under DPDPA, the Data Fiduciary's accountability doesn't diminish when personal data leaves their systems, it extends to every processor they've chosen to trust with it. Section 8 makes this structural, and the DPBI's penalty framework makes it consequential.
Processor contracts aren't paperwork overhead. They're the primary mechanism through which you exercise control over data you're legally responsible for.
Download the DPDPA Compliance Guidebook at truconsent.io/guide, includes a Data Processor Register template and a DPA clause checklist aligned with Section 8 and Rule 6.