Data Fiduciary vs Data Processor: Redrafting Your B2B Vendor DPAs Under the DPDP Act 2023

Most Indian B2B contracts signed before 2024 were not written with the Digital Personal Data Protection Act, 2023 in mind. They have a confidentiality clause, sometimes a data security schedule borrowed from a GDPR template, and almost never a clause that survives a Section 8(2) reading. With the DPDP Rules, 2025 notified on 13 November 2025 and full substantive compliance due by 13 May 2027, every company that qualifies as a Data Fiduciary now has a fixed runway to fix this. This article is written for the person who has to actually do that: pull out the vendor MSA, find the data clause, and redraft it. It covers the legal distinction only to the extent it changes what goes in the contract, then moves straight into the clauses that need to change and why.

What is the difference between a Data Fiduciary and a Data Processor under the DPDP Act

A Data Fiduciary decides why and how personal data is processed. A Data Processor processes that data strictly on the Fiduciary’s written instructions and has no independent purpose of its own. Section 2(i) of the DPDP Act defines the Fiduciary as the party determining the purpose and means of processing, while Section 2(k) defines the Processor as the party processing data on the Fiduciary’s behalf. The distinction is not fixed by company size or by who owns the customer relationship. It is fixed by who controls the purpose.

This matters at the contract level because the DPDP Act places almost every enforceable obligation on the Fiduciary. Under Section 8(1), the Fiduciary remains accountable for compliance across the entire processing chain, including anything done by a vendor on its behalf. A cloud hosting provider, a payroll processor, an email marketing platform, and a KYC verification vendor are all, in the overwhelming majority of B2B arrangements, Data Processors. The company that hired them is the Fiduciary, and the Fiduciary cannot contract its way out of that accountability. It can only contract its way to recourse.

Direct answer: the practical test for classification is control over purpose, not control over data. If your CRM vendor stores customer data exactly as instructed and for no purpose beyond delivering the service, it is a Processor. If that same vendor starts using the data to train its own product or to generate insights for other clients, it has stepped outside the instruction and becomes a Fiduciary for that use, with the full weight of the Act attaching to it independently.

Attribute	Data Fiduciary	Data Processor
Determines purpose of processing	Yes	No, acts only on written instruction
Direct statutory liability under the Act	Yes, primary accountability under Section 8(1)	No direct statutory liability, but full contractual liability
Must engage the other party under a valid contract	Yes, mandated by Section 8(2)	Bound by the terms of that contract
Responsible for breach notification to DPBI	Yes, within the Rule 7 timeline	Must notify the Fiduciary immediately so the Fiduciary can meet that timeline
Can appoint sub-processors independently	Not applicable	Only with the Fiduciary’s prior authorisation, since the Act is silent and the contract must fill the gap

Why does Section 8(2) make every undocumented vendor relationship a compliance gap

Section 8(2) of the DPDP Act permits a Data Fiduciary to engage a Data Processor only under a valid contract. Rule 6 of the DPDP Rules, 2025 goes further, requiring that the contract bind the Processor to security safeguards that match the Fiduciary’s own obligations under the Act. Read together, this means an oral arrangement, a purchase order with no data clause, or an MSA silent on personal data processing is not a compliance gap that can be closed later with a policy document. It is a contract that does not meet the Section 8(2) threshold at all.

For most companies, the exposure is not the flagship SaaS agreement, which usually already has a security schedule. It is the long tail: the analytics tool procured on a corporate card, the recruitment platform onboarded by HR without legal review, the regional logistics partner running on a two-page service agreement from 2019. A Data Protection Board inquiry after a breach will not distinguish between a vendor that processed data under a defective DPA and one that processed data under no DPA at all. Both fail Section 8(2). The redrafting exercise, therefore, has to start with an inventory, not with a template.

What clauses in a legacy vendor MSA typically fail a DPDP reading

Most MSAs drafted before 2023, and a surprising number drafted after, share the same four gaps. Each is fixable, but the fix has to be specific rather than a blanket reference to “applicable data protection laws.”

Direct answer: the four most common failure points are an undefined scope of processing, no breach notification timeline running to the Fiduciary, no sub-processor authorisation mechanism, and a generic indemnity clause that does not map to the DPDP Act’s actual penalty structure. Fixing these four closes most of the Section 8(2) gap for a typical B2B vendor contract.

• Undefined scope of processing. Many MSAs describe the service, not the data. A redraft needs a schedule that names the categories of personal data involved, the specific purpose for each category, and an express prohibition on the vendor using the data for any purpose outside that instruction.
• No breach notification clock running to the Fiduciary. The Fiduciary has to notify the Data Protection Board of India without delay, and file a detailed report within the timeline set by Rule 7. A vendor contract that lets the vendor investigate internally before notifying the Fiduciary makes that statutory clock impossible to meet. The redraft needs the vendor’s notification obligation triggered on becoming aware of a breach, not on confirming one.
• No sub-processor authorisation mechanism. The DPDP Act does not regulate sub-processing directly, which means the contract is the only place this gets governed. Silence here means a cloud vendor’s own sub-vendors, backup providers, or support contractors sit entirely outside the Fiduciary’s visibility.
• A generic indemnity clause. Standard MSA indemnity language usually caps liability at fees paid over twelve months. Against a DPDP Act penalty that can run into hundreds of crores for a single incident, that cap is not a negotiating outcome, it is a decision to absorb the entire penalty exposure internally.

Clause	What the legacy MSA usually says	What the DPDP-compliant redraft should say	Legal basis
Scope of processing	General confidentiality obligation covering “customer data”	Named categories of personal data, stated purpose per category, prohibition on secondary use	Section 8(2), Rule 6
Security safeguards	Reference to “industry standard security”	Specific technical and organisational measures, benchmarked to the Fiduciary’s own safeguards	Section 8(4), Section 8(5), Rule 6
Breach notification	Vendor notifies “promptly” or “as required by law”	Vendor notifies the Fiduciary immediately on becoming aware, defined in hours not days	Rule 7
Sub-processing	Silent, or a general right to subcontract	Prior written authorisation for each sub-processor, flow-down of equivalent obligations	Contractual, since the Act is silent
Deletion on termination	“Return or destroy data” at vendor discretion	Certified deletion within a fixed period, covering backups and archives	Section 8(7)(b)
Indemnity	Capped at fees paid, standard mutual indemnity	Uncapped or high-cap indemnity for regulatory penalties caused by vendor non-compliance	Contractual risk allocation against Section 8(1) exposure

How should sub-processor clauses be structured when the Act itself is silent

This is the clause founders and in-house counsel underestimate most often. The DPDP Act does not mention sub-processors. That silence does not mean sub-processing is unregulated, it means the entire governance burden sits on the DPA. A payroll vendor that quietly routes data through a sub-contracted HR analytics platform, or a cloud host that relies on a third-party monitoring tool, creates a processing chain the Fiduciary has no visibility into unless the contract requires it.

The workable structure has three parts. First, the Processor must seek prior written authorisation before engaging any sub-processor, either specific to each named sub-processor or general with a published list and a right for the Fiduciary to object. Second, every sub-processing arrangement must carry obligations equivalent to the primary DPA, not a lighter version of it. Third, the Processor remains fully liable to the Fiduciary for a sub-processor’s failure, so the Fiduciary is never left negotiating with a party it has no direct contract with.

Where does penalty exposure actually sit, and how does that change negotiating leverage

The DPDP Act imposes no direct statutory penalty on the Data Processor. Penalties under the Act attach to the Data Fiduciary, and they are not small. The Schedule to the Act sets five distinct tiers rather than a single ceiling, and they stack. A failure to implement reasonable security safeguards under Section 8(5) carries the highest exposure, up to ₹250 crore. A failure to notify the Board and affected Data Principals of a breach carries a separate exposure of up to ₹200 crore, as does a violation of the additional obligations relating to children’s data under Section 9. Non-fulfilment of a Significant Data Fiduciary’s additional obligations under Section 10 carries up to ₹150 crore, and any other violation of the Act or Rules carries a residual exposure of up to ₹50 crore. Because these tiers are assessed per violation rather than per proceeding, a single breach that stems from inadequate safeguards and is then reported late can expose a Fiduciary to the safeguards tier and the notification tier simultaneously, pushing cumulative exposure well past any single cap.

This asymmetry is exactly why the DPA, not the Act, is the only place a Fiduciary can recover from a Processor’s failure. A vendor that caused the breach faces no direct DPBI penalty. It faces whatever the Fiduciary negotiated into the contract, and nothing more. A DPA with a low indemnity cap does not just under-protect the Fiduciary, it removes the only lever the Fiduciary has against a vendor whose negligence triggered a nine or ten figure penalty.

Violation type	Statutory basis	Penalty ceiling
Failure to implement reasonable security safeguards leading to a breach	DPDP Act, Section 8(5), Schedule	Up to ₹250 crore
Failure to notify the Board or Data Principals of a breach	DPDP Act, breach notification obligation, Schedule	Up to ₹200 crore
Violation of obligations relating to children’s data	DPDP Act, Section 9, Schedule	Up to ₹200 crore
Non-fulfilment of a Significant Data Fiduciary’s additional obligations	DPDP Act, Section 10, Schedule	Up to ₹150 crore
Any other violation of the Act or Rules by a Data Fiduciary	DPDP Act, Schedule, residual category	Up to ₹50 crore
Example cumulative exposure from one incident triggering the safeguards and notification tiers together	DPDP Act, Schedule (penalties stack per violation)	Up to ₹450 crore in that combination alone

Direct answer: because the Processor carries no direct statutory liability, negotiating leverage on indemnity caps should track the sensitivity and volume of data handled, not the size of the vendor contract. A ₹15 lakh annual analytics contract that touches sensitive financial data for two lakh customers should carry an indemnity structure closer to the Fiduciary’s own penalty exposure than to the contract value.

Which vendor categories carry the highest redraft priority

Not every vendor relationship needs the same urgency. A sector-by-sector read helps a legal or procurement team sequence the redraft rather than trying to touch every contract simultaneously.

• Payroll and HR platforms. These vendors hold PAN, Aadhaar, bank details, and salary data for every employee. The DPA should specifically address deletion timelines on employee exit and sub-processor use by the payroll platform’s own technology stack.
• Cloud hosting and infrastructure. High sub-processor complexity, since most cloud providers layer monitoring, CDN, and backup services from third parties. Audit rights and named sub-processor lists matter most here.
• Marketing automation and CRM platforms. The highest risk of purpose creep, since these vendors have a commercial incentive to use customer data for their own product improvement or benchmarking. The scope of processing clause needs to be unusually specific.
• Analytics and AI-enabled tools. Any vendor training a model on your data, even in aggregate or anonymised form, needs a clause that expressly defines whether that constitutes processing on your instruction or the vendor acting as an independent Fiduciary for that use.
• BFSI-adjacent vendors, such as KYC and payment processors. These carry a dual compliance burden, since a DPA here has to satisfy both the DPDP Act and RBI or SEBI sectoral cybersecurity requirements. A single incident can trigger penalties under both regimes.

How should a legal team sequence the audit and redraft of an entire vendor book

Redrafting every vendor contract at once is not realistic for most companies, and it is not what the phased timeline demands. The Data Protection Board’s core provisions took effect from 13 November 2025, Consent Manager provisions come into force from 13 November 2026, and the remaining substantive obligations, including the DPA requirements under Section 8, become enforceable from 13 May 2027. That gives a Fiduciary a defined window, not an open-ended one.

1. Build a Data Processor inventory. List every vendor that touches personal data, including cloud, HR, marketing, analytics, logistics, and payment vendors. Most companies find this list is two to three times longer than they expect once shadow IT tools are included.
2. Classify each relationship. Confirm which vendors are genuinely Processors and flag any that show signs of acting as an independent Fiduciary, such as using data for their own product training.
3. Score existing contracts against the four failure points. Scope of processing, breach notification, sub-processor authorisation, and indemnity. A contract failing on two or more should be prioritised for redraft ahead of one failing on none.
4. Redraft in order of data sensitivity and volume, not contract value. A low-value vendor touching sensitive health or financial data outranks a high-value vendor touching only non-personal operational data.
5. Build a standard DPA addendum that can be attached to existing MSAs rather than renegotiating the entire commercial agreement, which is usually faster to get signed than a full contract rewrite.

What negotiation and maintenance clauses get missed even in a careful redraft

Three items get dropped even by teams that handle the four main failure points properly.

Consent-withdrawal cascade. When a Data Principal withdraws consent, every entity processing that individual’s data, including contracted processors, must stop. This is not automatic just because the Fiduciary’s own systems reflect the withdrawal. The DPA needs a clause obligating the Processor to halt processing on receiving a stop instruction, within a defined turnaround time, and to confirm that halt in writing. Without this clause, the Fiduciary can be fully compliant on its own side and still be exposed by a Processor that kept processing for days after a withdrawal.

Negotiation leverage when a vendor pushes back. Vendors resist uncapped indemnity and audit rights more than any other clause. Three arguments tend to move this faster than a legal citation on its own: point to committed contract volume as leverage where the relationship is meaningful, reference what comparable enterprise clients in the same sector are already requiring from that vendor, and where the vendor has direct competitors offering DPDP-ready terms, name that fact plainly rather than treating it as a bluff. Positioning DPDP terms as a non-negotiable regulatory floor rather than a bespoke ask from one customer also shortens the back-and-forth considerably.

Review cadence. A DPA signed today should not be treated as permanent. Build in an annual review clause, or a review trigger on any material change to the scope of processing, the vendor’s sub-processor list, or the vendor’s own security certifications. Without this, a DPA that was compliant at signing quietly drifts out of alignment as the vendor’s stack changes underneath it.

• Treating the DPA as a policy document rather than a negotiated contract. Many companies attach a generic “data processing addendum” downloaded from a template site without adjusting the indemnity or sub-processor clauses to their actual risk. This satisfies the paperwork requirement and nothing else.
• Assuming the vendor’s standard DPA is sufficient. SaaS vendors, particularly global ones, often offer a GDPR-drafted DPA and treat it as DPDP-equivalent. The two regimes diverge on deletion mandates, breach notification timing, and the absence of a “legitimate interest” basis under the DPDP Act, so a GDPR DPA rarely survives an unmodified copy-paste.
• Leaving sub-processor lists undefined “for flexibility.” This feels efficient at signing and becomes unmanageable the moment a breach investigation needs to trace which third parties actually touched the data.
• Capping indemnity at fees paid without reference to data sensitivity. A contract with a ₹10 lakh annual value and a ₹10 lakh indemnity cap offers no real protection against a ₹50 crore penalty exposure if that vendor’s negligence caused the breach.
• Redrafting the DPA in isolation from the privacy policy and consent notice. The DPA, privacy policy, and consent architecture have to describe the same processing activities consistently. A DPA that authorises a use the privacy policy does not disclose to the Data Principal creates a fresh compliance gap even after the redraft.

A practitioner’s view from live vendor negotiations

In the commercial contract engagements we have run at Treelife, the pattern that shows up most often is not a missing DPA, it is a DPA that exists but was drafted for a different regulatory moment. A large share of Indian B2B vendor contracts signed between 2018 and 2023 carry data clauses written for the erstwhile IT Rules, 2011 framework under Section 43A of the IT Act, which the DPDP Rules have since repealed. Those clauses reference “sensitive personal data or information” categories and consent mechanisms that no longer track the DPDP Act’s definitions.

The second pattern is where clients get stuck negotiating, and it is rarely the clause language itself. It is the moment a vendor’s own legal team pushes back on an uncapped indemnity by pointing to their standard terms. That objection has a specific counter, and it is worth having ready before the redraft conversation starts, which the next section covers. For the broader compliance programme this redraft sits inside, including data mapping, consent architecture, and audit sign-off, see our DPDP Rules, 2025 deep dive. This article stays narrower on purpose: the clause-by-clause work on the contracts themselves.

Case study

Situation: A Series C fintech in Bengaluru with 40 active B2B vendor contracts, including four cloud infrastructure providers and a payroll outsourcing vendor handling data for 600 employees.

Challenge: No central vendor inventory existed. Three of the four cloud contracts had no data processing clause at all, and the payroll vendor’s DPA capped indemnity at three months of fees against a customer base exceeding two lakh end users.

What Treelife did: Built a full Data Processor inventory across all 40 vendors, scored each against the four DPDP failure points, and redrafted DPA addenda for the eleven highest-priority vendors within a sequenced eight-week plan, starting with the payroll and two highest-volume cloud contracts.

Outcome: All eleven priority DPAs signed within the deadline, indemnity exposure on the payroll contract restructured from a three-month cap to a penalty-linked indemnity, and the redrafted vendor pack was subsequently used during a Series D diligence process to close an investor’s DPDP compliance query in a single exchange rather than a multi-round back-and-forth.

FAQ’s on Data Fiduciary vs Data Processor

Q: Can the same company be a Data Fiduciary and a Data Processor at the same time?
A: Yes. The classification depends on the specific processing activity, not on the company as a whole. A SaaS company is a Fiduciary for its own employee and customer data, and a Processor for any customer data it processes strictly on that customer’s instruction through its platform.

Q: Does a vendor DPA need to be a standalone document, or can it live inside the main MSA?
A: Either works legally, provided the data processing terms are specific and enforceable. A standalone addendum is usually faster to negotiate and update than reopening the full commercial agreement, which is why most companies now use an addendum structure.

Q: What is the realistic cost of redrafting a full vendor contract book?
A: This varies by vendor count and contract complexity, but the cost driver is legal review time per contract rather than a fixed per-document fee. Prioritising by data sensitivity, as set out above, usually reduces the immediate redraft list to a fraction of the full vendor book.

Q: How long does a typical vendor DPA redraft and re-signature take?
A: For a standard addendum with an existing, cooperative vendor, two to four weeks from first draft to countersignature is typical. Vendors resisting indemnity or audit rights clauses can extend this considerably, which is why sequencing by priority matters.

Q: What documentation should sit alongside the redrafted DPA?
A: A data processing register mapping what data each vendor receives, the vendor’s own security certification (such as ISO 27001, where available), and a record of the sub-processor authorisation exchanged under the new clause.

Q: Does the DPDP Act restrict sending vendor data outside India?
A: No. The DPDP Act permits cross-border transfer of personal data by default, restricted only where the Central Government specifically notifies a country or territory. The DPA should still include a clause requiring the vendor to flag any offshore processing so the Fiduciary can track exposure if such a notification is issued.

Q: If a vendor’s data breach exposes us to a DPBI penalty, can we recover that from the vendor?
A: Only to the extent the DPA allows. The DPBI’s penalty is imposed on the Fiduciary regardless of fault allocation between the parties. Recovery from the vendor depends entirely on the indemnity clause negotiated in the DPA, which is why a capped or generic indemnity clause is a direct financial risk, not boilerplate.

Q: Do Significant Data Fiduciaries need anything additional in their vendor DPAs?
A: Yes. An SDF’s DPA should reflect its additional obligations, including data protection impact assessments and independent audits, since a vendor’s processing activity may need to feed into those assessments. SDF status is notified by the Central Government based on data volume, sensitivity, and risk profile, and is not self-declared.

Q: What happens if a vendor refuses to sign a DPDP-compliant DPA?
A: Continuing to send personal data to that vendor without a valid contract fails the Section 8(2) threshold outright. In practice, vendors handling meaningful volumes of Indian personal data are increasingly expected to comply as a market condition, and refusal is becoming a legitimate ground for switching vendors.

Q: How does this differ from a GDPR data processing agreement?
A: The DPDP Act mandates deletion of personal data once the purpose is served, whereas GDPR allows a choice between deletion and return. The DPDP Act also lacks a “legitimate interest” processing basis, relying more heavily on consent and specified legitimate uses, which changes how the scope of processing clause should be drafted.

Q: Should the DPA include a specific breach notification timeline in hours, or just reference the Rules?
A: A specific number of hours is stronger. Referencing “as required by law” leaves the vendor room to interpret the timeline, whereas a fixed clock, tied to becoming aware of a breach rather than confirming one, ensures the Fiduciary has enough runway to meet its own reporting deadline to the Board.

Q: What happens to sub-processors already engaged before the redraft?
A: These need to be disclosed and ratified under the new DPA terms, not grandfathered silently. The redraft should include a schedule listing all existing sub-processors as of the effective date, with the same authorisation and flow-down obligations applying going forward.

Q: Is a data processing register mandatory under the DPDP Act itself?
A: The Act does not mandate a named “register” by that term, but maintaining one is close to unavoidable in practice, since it is the only way to demonstrate the due diligence and contractual safeguards that determine whether a Fiduciary can defend itself in a DPBI inquiry.

Regulatory references

• Digital Personal Data Protection Act, 2023, Sections 2(i), 2(k), 8(1), 8(2), 8(4), 8(5), 8(7)(b), 9, 10, and the Schedule (penalty provisions)
• Digital Personal Data Protection Rules, 2025, Rules 6, 7, 8, 14 (notified 13 November 2025, gazette G.S.R. 846(E))
• Enforcement Notification, Ministry of Electronics and Information Technology, dated 13 November 2025, setting phased effective dates of 13 November 2025, 13 November 2026, and 13 May 2027

External sources

• Ministry of Electronics and Information Technology
• Digital Personal Data Protection Act, 2023 and Rules, official text