Data Fiduciary vs. Data Processor: Who Really Carries the Liability Under the DPDP Act?
The most dangerous word in a vendor contract is "processor."
Picture an HR-tech vendor that signs a services agreement describing itself as a Data Processor for a large client. Six months in, its product team starts using the client's applicant data to improve the vendor's own screening model. Nobody objects. Nobody even notices. The contract still says "processor," and everyone assumes the label settles the question.
It does not. Under the Digital Personal Data Protection Act, 2023, roles are decided by who determines the purpose and means of processing, not by what a contract calls you. The moment that vendor chose to reuse the data for its own product, it stepped into a different role for that activity, with different exposure.
I have sat through enough vendor reviews, audit walkthroughs and post-incident meetings to say this plainly: the single most common root cause of DPDP trouble is not a missing policy. It is a misunderstood role. This article walks through the two roles, the tests that separate them, the challenges nobody warns you about, and what to do before the substantive obligations begin on 13 May 2027. If you want the wider programme view first, start with our DPDP audit readiness checklist.
The two definitions that decide everything
Strip the Act down and three definitions carry most of the weight.
Section 2(i) defines a Data Fiduciary as any person who, alone or in conjunction with other persons, determines the purpose and means of processing of personal data. Section 2(k) defines a Data Processor as any person who processes personal data on behalf of a Data Fiduciary. The individual whose data it is, the Data Principal, sits at the other end of both relationships.
| Question | Data Fiduciary | Data Processor |
|---|---|---|
| Statutory basis | Section 2(i) | Section 2(k) |
| Core test | Determines purpose and means, alone or jointly | Processes on behalf of a Data Fiduciary |
| Relationship with the Data Principal | Direct: notice, consent, rights, grievances | None required by the Act |
| Primary source of obligations | The Act and the Rules, directly | The contract with the Fiduciary (Section 8(2), Rule 6) |
| Penalty exposure under the Schedule | Framed around its obligations | Largely indirect, through the Fiduciary |
| Can one entity be both? | Yes, for different activities | Yes, for different activities |
Notice what the table does not say. The Act contains no long list of statutory duties addressed to Data Processors. Almost every obligation in Chapter II, from notice to security to breach reporting to erasure, is addressed to the Fiduciary. That design choice drives nearly every challenge in the rest of this article.
The test is who decides, not what the paper says
When I assess a relationship, I ignore the heading of the contract and ask who holds the decisions.
Who decided that this data would be collected at all? Who chose the fields, the retention period, the recipients? Who faces the Data Principal when they complain? Whose commercial interest does the processing serve? If a vendor answers "the client decides everything and we follow written instructions," it is behaving as a Processor. If it is mining the data for its own analytics, enrichment or model training, it is deciding a purpose of its own.
Two further points matter in practice.
First, roles attach to activities, not companies. A payroll vendor is a Processor for your salary run and a Fiduciary for its own marketing database. A bank is a Fiduciary for its customers and a Processor when it runs a service for another institution.
Second, the phrase "alone or in conjunction with other persons" in Section 2(i) means two organisations can both be Fiduciaries for the same processing. The Act does not build a separate joint-controller regime the way some other laws do. My advice is to document the allocation of responsibilities anyway, because a regulator will read the substance of the arrangement, not your drafting.
Consent Managers, whose registration framework under Rule 4 begins on 13 November 2026, are a separate registered category. They are neither of the two roles discussed here and answer to the Data Principal.
Accountability does not travel with the data
Here is the sentence every Fiduciary should memorise. Section 8(1) makes the Fiduciary responsible for compliance with the Act for processing it undertakes or that is undertaken on its behalf by a Data Processor, irrespective of any agreement to the contrary.
Read that as a risk-transfer clause that does not transfer risk. You can outsource the work. You cannot outsource the accountability.
Three other provisions reinforce it. Section 8(2) allows engagement of a Processor only under a valid contract. Section 8(5) requires reasonable security safeguards for personal data in the Fiduciary's possession or under its control, including processing done on its behalf by a Processor. Section 8(7) requires the Fiduciary to erase data when consent is withdrawn or the purpose is served, and to cause its Processor to erase the data it was given, unless law requires retention.
.png)
The Schedule attaches penalties of up to ₹250 crore for failing to take reasonable security safeguards, up to ₹200 crore for failing to give breach intimation, and up to ₹200 crore for breaching the children's data obligations. In deciding an amount, the Board looks at the nature, gravity and duration of the breach, the type of data involved, whether it repeated, and the mitigation attempted. The figures are ceilings, not tariffs. But look at whose obligations they are framed around. Your processor's lapse becomes your penalty.
| Obligation | Where it sits | Who must act in practice |
|---|---|---|
| Notice and consent | Sections 5 and 6; Rule 3 | Fiduciary |
| Reasonable security safeguards | Section 8(5); Rule 6 | Fiduciary, flowed down by contract to the Processor |
| Contract with each Processor | Section 8(2); Rule 6 | Fiduciary drafts, Processor performs |
| Breach intimation to the Board and affected principals | Section 8(6); Rule 7 | Fiduciary, relying on the Processor's early warning |
| Erasure when purpose ends or consent is withdrawn | Section 8(7) | Fiduciary orders, Processor executes |
| Grievance redressal and published contact | Sections 8(9) and 8(10) | Fiduciary |
| DPO in India, independent audit, DPIA | Section 10; Rule 13 | Significant Data Fiduciaries only |
Six challenges I see again and again
The definitions are tidy. Real organisations are not. These are the problems that actually surface in audits.
1. The vendor who quietly becomes a Fiduciary. Analytics providers, ad-tech platforms, CRM vendors and AI tooling firms often reserve the right to use customer data to "improve services." The moment they do, they are deciding a purpose. The client rarely notices, and the original notice to the Data Principal never mentioned it. Ask every vendor in writing: do you use our data for any purpose of your own?
| Vendor type | Usual role | What can tip it |
|---|---|---|
| Payroll and HRMS provider | Processor | Using employee data for benchmarking products sold to others |
| Cloud hosting provider | Processor | Rarely tips; check log and metadata use |
| Marketing automation or ad-tech platform | Processor, often a Fiduciary too | Cross-client profiling, audience building |
| Call centre or BPO | Processor | Recording reuse, training analytics for its own use |
| Diagnostic lab for a hospital | Often a Fiduciary in its own right | Direct patient relationship, own reporting duties |
| Credit bureau or data broker | Fiduciary | Acts for its own purposes by design |
2. Joint decision-making without joint paperwork. Two companies run a co-branded loyalty programme. Both decide the purposes. Neither wrote down who gives notice, who handles rights requests, or who reports a breach. When something goes wrong, each assumes the other owns it.
3. A liability gap the contract cannot close. Many vendor agreements cap liability at twelve months of fees. A statutory penalty ceiling of ₹250 crore does not respect that cap. The contract can allocate commercial loss between the parties. It cannot reduce what the Board may impose on the Fiduciary. Negotiate indemnities and insurance with that asymmetry in mind.
4. Sub-processor chains you cannot see. Your processor uses a cloud vendor, which uses a support contractor in another country. The Act is silent on sub-processors by name, but Rule 6 expects the Fiduciary's contract to carry the safeguards, and in practice that means they must flow down the chain. If your contract says nothing about sub-processors, you have a blind spot with your name on it.
5. A breach clock that starts before you know. Rule 7 requires the Fiduciary to inform each affected Data Principal and the Board without delay, followed by a detailed report to the Board within 72 hours of becoming aware, unless the Board allows longer on written request.
The Act does not say how fast a Processor must tell you. Your contract must. Whether a processor's knowledge is treated as yours has not been tested, so do not rely on the gap. I recommend notice in hours, with named contacts on both sides.
6. Erasure that never reaches the vendor. Section 8(7) obliges you to cause the Processor to erase. Teams build the front-end deletion button and forget the three vendors holding copies. Rule 8 also expects advance notice before erasure for certain classes of Fiduciary, and Rule 6 expects logs and related records to be retained for a year, so deletion needs a considered design, not a script.
A related misunderstanding deserves its own line. Indian outsourcing and BPO firms often assume they are out of scope. Section 17(1)(d) exempts processing of personal data of Data Principals outside India, done under a contract with a person outside India, from most of Chapter II, all of Chapter III and Section 16. But Sections 8(1) and 8(5) are expressly kept alive, and the exemption says nothing about Indian residents' data, your own employees' data, or domestic clients. Meanwhile Section 3(b) pulls offshore firms offering goods or services to people in India into the Act. And Section 16 follows a negative-list model for transfers out of India, with stricter sectoral rules continuing to apply.
Three myths worth retiring
"Our vendor is ISO 27001 certified, so we are covered." A certificate is useful evidence of a security programme. It is not evidence that your personal data, specifically, is protected the way Section 8(5) and Rule 6 expect. Section 8(1) leaves the burden with you, so ask for the logs, access reviews and encryption details that relate to your data, not a framed certificate.
"We are too small for vendor management to matter." The Act has no turnover or headcount threshold. Section 17(3) allows the Central Government to exempt notified classes of Data Fiduciaries, including startups, from a short list of provisions: notice under Section 5, Sections 8(3) and 8(7), the Significant Data Fiduciary duties in Section 10, and the access right in Section 11. Check whether any such notification exists for you at the time you read this. Even where one does, Sections 8(1), 8(2), 8(5) and 8(6) are not on that list. Your processor chain, your security duty and your breach duty stay with you.
"Processors carry no risk, so we can be relaxed about being one." Section 33 allows the Board to penalise a person for a significant breach, but the practical pressure on a Processor is commercial. Clients will demand audit rights, flow-down terms and uncapped indemnities. Losing a large account to a failed questionnaire is a penalty of its own. A Processor that cannot show where it keeps its client's data and who touched it will lose deals long before the Board hears of it.
If your client is a Significant Data Fiduciary
Section 10 allows the Central Government to notify Significant Data Fiduciaries based on factors such as the volume and sensitivity of data processed and the risk to Data Principals. Those entities must appoint a Data Protection Officer based in India, engage an independent data auditor, and carry out periodic Data Protection Impact Assessments. Rule 13 makes the audit and the DPIA annual.
If you are a Processor to such a client, expect them to push those assessments down to you. Be ready to describe your data flows, your sub-processors and your controls on short notice, and to support their auditor with evidence rather than assurances.
What a defensible processor contract contains
Section 8(2) says "valid contract." It does not say what is in it. Rule 6 adds one requirement: appropriate provisions for reasonable security safeguards. Everything else is professional judgment, and this is where I would spend your first quarter of effort.
| Clause | Why it matters | Red flag in the contract you already signed |
|---|---|---|
| Purpose limitation | Processing only on documented instructions | "To improve our services" with no boundary |
| Security safeguards | Rule 6 requires them to be written in | "Industry standard" with no specifics |
| Sub-processor approval and flow-down | Safeguards must survive the chain | Silence, or blanket permission |
| Breach notice to you | Your 72-hour report depends on it | No timeline, or longer than yours |
| Erasure or return at exit and on instruction | Section 8(7) requires you to cause erasure | No exit obligation |
| Location and cross-border disclosure | You must know where data physically sits | "Global infrastructure" |
| Log retention and evidence access | Rule 6 logging; you need proof | No right to request any documentation |
| Cooperation with rights requests | Fiduciary owns the answer, Processor holds the data | No turnaround commitment |
The calendar is not on your side
The Rules were notified on 13 November 2025. The Board provisions took effect immediately, the Consent Manager framework follows on 13 November 2026, and the substantive obligations apply from 13 May 2027. As of today, that leaves roughly seven months to re-paper every processor relationship.
If I had one quarter, I would do five things in this order:
- List every vendor that touches personal data, including the ones Marketing bought on a credit card.
- Classify each relationship by activity, using the tests above, and note where a vendor uses data for its own purpose.
- Rank by volume and sensitivity, and start repapering at the top.
- Set breach-notice and erasure SLAs that fit inside your own Rule 7 and Section 8(7) obligations.
- Capture evidence as you go: signed terms, due-diligence notes, test results, dated and owned.
How VaultDef helps
Most of the pain above has one cause: the Fiduciary cannot see its own vendor chain. VaultDef is built to give you that sight, and to leave a dated trail while it does.
| Challenge | What the work needs | Where VaultDef fits |
|---|---|---|
| Unknown data and unknown recipients | A map of where personal data sits and who receives it | Automated data discovery and classification, RoPA and data mapping |
| Vendor role confusion | One register tying each vendor to specific processing activities | Vendor and cross-border tracking linked to the RoPA |
| Notice and consent that match reality | Consent records and notices tied to actual purposes | Consent and notice management |
| Rights and erasure reaching downstream | Tracked requests with a clear audit trail | Data principal rights workflow |
| The 72-hour breach clock | A rehearsed, documented response | Breach workflow and incident response |
| "Prove it" from a customer or auditor | Dated, tamper-evident evidence | Evidence trail built for audit |
The point is not the software. The point is that when a client's questionnaire arrives on a Thursday evening asking whether you are a Fiduciary or a Processor, and for which activities, you can answer from a register rather than from memory.
Closing thought
The Data Fiduciary and Data Processor distinction looks like a definitions exercise. It is really a question about accountability: who decides, who answers, and who can prove it. The Act answers the first two clearly. The third is up to you.
Start with your vendor list this week. Everything else follows from knowing who holds your data and in what role.
ABOUT VAULTDEF VaultDef turns this work into a working programme: automated data discovery and classification, RoPA and data mapping, consent and notice management, data principal rights, breach workflow, DPIA, vendor and cross-border tracking, and an evidence trail built for the day someone says "prove it." Request a walkthrough.
