Data Fiduciary vs Data Processor: Roles, Obligations, and Liability

The DPDP Act 2023 splits every processing arrangement into two roles. The Data Fiduciary decides why and how personal data is processed. The Data Processor executes on the fiduciary’s behalf. The classification is not a formality: it determines who carries obligations that run to Rs 250 crore at the top of the penalty Schedule, who answers Data Principal rights requests, and who faces the Data Protection Board when something breaks.

The Statutory Definitions

Two definitions in Section 2 carry the whole structure.

“‘Data Fiduciary’ means any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data.” (Section 2(i))

“‘Data Processor’ means any person who processes personal data on behalf of a Data Fiduciary.” (Section 2(k))

The operative words are “determines the purpose and means” and “on behalf of.” If your organisation decides why data is collected and how it is handled, you are the fiduciary, whether the processing happens in-house or is outsourced entirely. If you execute another entity’s instructions without deciding the purpose, you are the processor.

The Act then fixes accountability in one direction:

“A Data Fiduciary shall, irrespective of any agreement to the contrary or failure of a Data Principal to carry out the duties provided under this Act, be responsible for complying with the provisions of this Act and the rules made thereunder in respect of any processing undertaken by it or on its behalf by a Data Processor.” (Section 8(1))

Read that clause twice. Responsibility for the processor’s work sits with the fiduciary, and no contract clause moves it. A bank that outsources loan processing remains answerable for the partner’s handling of borrower data. This is the structural difference from GDPR, which imposes direct obligations on processors; the DPDP Act runs everything through the fiduciary.

Obligations, Side by Side

The fiduciary column below is a summary; the seven fiduciary obligations are mapped in depth separately.

Obligation	Data Fiduciary	Data Processor	Reference
Obtain consent	Yes. Free, specific, informed, unconditional, unambiguous	No. Acts on the fiduciary’s instructions	Section 6
Give notice	Yes. Itemised, standalone notice per Section 5 and Rule 3	No	Section 5, Rule 3
Answer rights requests	Yes. Access, correction, erasure, grievance	Cooperates with the fiduciary	Sections 11 to 14
Breach notification	Yes. Board without delay, detailed report within 72 hours, Data Principals without delay	Alerts the fiduciary per contract	Section 8(6), Rule 7
Security safeguards	Yes	As directed, under the contract	Section 8(5)
Erasure	Yes, when purpose is served or consent withdrawn, subject to legal retention	Deletes on the fiduciary’s instruction	Section 8(7)
Engage under valid contract	Yes. May engage a processor only under a valid contract	Is the counterparty to that contract	Section 8(2)
SDF duties (DPO, DPIA, audit)	Yes, if designated	No	Section 10
Direct penalties	Yes, up to Rs 250 crore at the Schedule’s top tier	No direct Schedule exposure; liability is contractual	The Schedule

The 72-hour breach clock runs under Rule 7, which becomes enforceable on 13 May 2027; the breach notification framework covers the sequence, including the CERT-In reporting that is in force today.

Where the Liability Actually Lands

The penalty Schedule prices fiduciary failures: Rs 250 crore for security safeguard failures under Section 8(5), Rs 200 crore for breach notification failures under Section 8(6), Rs 150 crore for Significant Data Fiduciary obligations, Rs 50 crore for the residual tier. The full penalty framework maps every tier.

The processor’s exposure is real but indirect. It runs through three channels: indemnity clauses in the processing agreement, termination and the loss of regulated clients who cannot carry a non-compliant vendor, and scrutiny of the processor’s role when the Board investigates the fiduciary. A processor serving banks, NBFCs, or insurers should treat DPDP capability as commercially existential even though the Schedule does not name it.

When One Entity Wears Both Hats

Most organisations hold both roles at once, split by data category.

A SaaS HR platform is the fiduciary for its own employees’ payroll and attendance data, and the processor for the employee data its clients run through the platform. The client is the fiduciary for that data; the platform executes.

An NBFC pulling a credit report is the fiduciary for the lending decision. The credit bureau is a fiduciary in its own right for the credit information it maintains. When two fiduciaries share data about the same borrower, each carries its own consent and notice obligations toward that individual.

A payment gateway processes transaction data on the merchant’s behalf. The moment it uses the same data for its own fraud analytics under its own decisions, it is a fiduciary for that activity.

The compliance consequence: the classification runs per processing activity, not per company. Your consent records, retention schedules, and rights workflows must distinguish the data you control as fiduciary from the data you merely process. One framework per role, mapped in the data inventory.

The Data Processing Agreement

Section 8(2) permits a fiduciary to engage a processor “only under a valid contract.” The Act stops there. It does not prescribe the contract’s contents, which means the clauses that actually protect the fiduciary are the fiduciary’s to demand.

Clause	What it does
Scope of processing	Fixes the data categories, purposes, and permitted activities
Instruction-only processing	Bars the processor from processing beyond documented instructions
Security safeguards	Sets the minimum technical and organisational measures, mapped to Section 8(5)
Breach notification SLA	Obligates the processor to alert the fiduciary within a fixed window, short enough to meet the fiduciary’s own clocks under Rule 7
Sub-processor control	Requires prior written consent and flows the obligations down
Rights cooperation	Binds the processor to execute access, correction, and erasure instructions on statutory timelines
Data return and deletion	Requires return or verified deletion at contract end
Audit rights	Lets the fiduciary inspect compliance, on site and on paper
Indemnification	Prices the processor’s failures back to the processor

The BFSI overlay. Where the fiduciary is RBI-regulated, the contract must also carry the retention mandates: KYC records held five years under the RBI KYC Direction and PMLA Rules, retained even against an erasure request under the Section 8(7) carve-out. The processor must be contractually bound to hold those fields for the statutory period and to erase everything else on instruction. The retention conflict framework covers this mechanism in full.

Classify Before You Build

The five-step test in the checklist above settles the classification per activity: identify the data, ask who decides the purpose, ask who decides the means, map dual roles, and assess Significant Data Fiduciary exposure. Run it before building compliance infrastructure, because every downstream artefact, from consent records to the processor contract file, depends on which side of the line each activity sits.

Where ConsentOS Fits

ConsentOS records consent with the purpose it was given for, signed as an Electronic Consent Artifact, so a fiduciary can show which processing each consent covers. The Rights Management Portal takes Data Principal requests in one place, and the Data Inventory portal holds the map of data categories, systems, and processors that the classification test produces. For regulated fiduciaries, the Legal Obligation Override flags a statutory-retention conflict at erasure time and registers the denial with its legal basis, the artefact both the Board and a sector regulator will ask to see.

Run the Gap Assessment to score your fiduciary obligations, processor contracts included.