Data Fiduciary vs Data Processor: which role are you?

Almost every duty in this framework lands on a named role, so the label decides who answers for a processing activity and who does not. Section 4(1) is the exception worth knowing, because it opens "A person may process", and what the framework asks of a processor directly sets out why that is unsettled. The glossary carries both terms with their citations: Data Fiduciary and Data Processor. For the framework both roles sit in, start with the overview of the DPDP Act and Rules.

The test is short, and most of the confusion comes from applying a longer one.

The whole test is one question: who determines purpose and means

"“Data Fiduciary” means any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data"

"“Data Processor” means any person who processes personal data on behalf of a Data Fiduciary"

If you decide why the personal data is processed and how, you are the Data Fiduciary for that processing. If you handle it on someone else's behalf, under their decisions, you are their Data Processor for it.

2 features of the wording do a lot of work. The first is "alone or in conjunction with other persons", which lets 2 or more organisations be Data Fiduciaries for the same processing when they decide it together. The second is that the processor definition is relational: it does not create a free standing status, it describes a person processing on behalf of a particular Data Fiduciary. There is no such thing as being a Data Processor in general.

The DPDP role test, applied to one processing activity at a time. Who determines the purpose and the means? Determine them, alone or with others, and you are the Data Fiduciary. Process on another organisation's behalf and you are its Data Processor. Section 3(c) puts some processing outside the Act entirely, so no role attaches: limb (i) for an individual acting for a personal or domestic purpose, and limb (ii) for personal data the Data Principal made publicly available, which is open to a company as well.

What the test never asks

4 questions get asked in place of the statutory one, and none of them appears in either definition.

The practical version: write down a single processing activity, then ask who chose the purpose and who chose the means. Anything else you know about the relationship is evidence at best.

Who is capable of holding a role at all

Both definitions open with "any person", and the Act defines that word.

"“person” includes— (i) an individual; (ii) a Hindu undivided family; (iii) a company; (iv) a firm; (v) an association of persons or a body of individuals, whether incorporated or not; (vi) the State; and (vii) every artificial juristic person, not falling within any of the preceding sub-clauses"

A sole proprietor, a partnership, a housing society, a school trust and a government department are all capable of being a Data Fiduciary. Nothing in the definitions requires incorporation, registration or a minimum size.

Several routes take processing outside the framework altogether, and none of them is a third role. Each is an exclusion from the Act itself, so no role attaches because no part of the Act applies. The clearest is section 3(c)(i).

Section 3(c)(i) provides that the Act does not apply to "personal data processed by an individual for any personal or domestic purpose". An individual keeping a personal contact list decides the purpose and the means of that processing, and the Act still does not reach it. That exclusion is available to an individual and to a personal or domestic purpose, so it does nothing for a company and nothing for the working files of a business.

Section 3(c)(ii) is the second, and it is built the other way round: it turns on the data rather than on who is processing it. The Act does not apply to personal data "made or caused to be made publicly available" either by the Data Principal herself, or by a person under a legal obligation in India to publish it. That limb is not confined to individuals, so a company determining the purpose and means of processing such data is outside the Act for that processing too. Note what the gateway turns on: the clause asks who made the data public and under what authority, not whether the data happens to be findable. On this site's reading, personal data that reached the open web without any act of the Data Principal and without a legal obligation to publish it, a breach dump or a leak being the clearest case, was not made publicly available by either of the 2 persons the clause names, so limb (ii) does not reach it. Data the Data Principal herself posted is a different matter, and the Act prints an Illustration to that effect about an individual blogging her views on social media.

Those 2 limbs are not the whole of it either. Sections 3(a) and 3(b) confine the Act in the first place, to digital personal data processed within India and to processing outside India connected with offering goods or services to Data Principals in India. Section 17(2) then provides that the provisions of the Act do not apply to processing by an instrumentality of the State that the Central Government notifies, or to processing necessary for research, archiving or statistical purposes carried on in accordance with the standards the Rules prescribe.

Section 17(1) is different in kind and should not be described the same way. It disapplies Chapter II, except sections 8(1) and 8(5), together with Chapter III and section 16, in the situations it lists. That leaves the person inside the Act with fewer duties rather than outside it, so a role still attaches.

One organisation, both roles, at the same time

The definitions attach to processing, not to a company. Section 8(1) speaks of "any processing undertaken by it or on its behalf", and the processor definition is tied to the fiduciary whose behalf is being acted on. Reading those together, this site treats the role as a property of each processing activity, which means a single organisation routinely holds both roles at once, for different data, at the same moment.

That is the normal state of affairs rather than an edge case. A payroll bureau is the Data Fiduciary for its own employees and its own client relationships, and the Data Processor for the salary data its clients send it. A logistics company decides why and how it processes its drivers' data, and handles the delivery addresses a marketplace passes it under that marketplace's instructions.

The same test, worked through 8 engagements

Each line below applies section 2(i) and section 2(k) to a described engagement. The definitions are the official text; the application of them to these facts is this site's reading, and a real engagement can change its answer on facts the description does not carry.

One thing the definition does not resolve, and it decides several of these rows. Section 2(i) asks who determines the purpose and the means, and the Act never says what happens when 1 organisation sets the purpose while another largely designs how the processing is done, which is the ordinary position with any software product. This site reads the means as determined by the organisation that chooses the tool and instructs its use, so a vendor's engineering decisions inside a product it was engaged to run do not by themselves make it a Data Fiduciary. That is a reading. Nothing in the Act or the Rules settles it, and no Indian decision construing section 2(i) has been found.

The last line deserves a warning. The Act names no joint fiduciary machinery, allocates nothing between co deciders and provides no mechanism for one of them to carry the compliance load for the other. Counted over the registered extractions on 29 August 2026, "in conjunction" appears once in the Act, in section 2(i), and once in the Rules, in Second Schedule item (h). On this site's reading each of them is a Data Fiduciary and each is separately answerable under section 8(1) for the processing it is party to, and an agreement between them changes what they owe each other rather than what they owe under the Act.

Why the Act says Fiduciary where other laws say controller

The wording of section 2(i) tracks the controller test familiar from other regimes almost exactly, which is why the vocabulary is worth understanding rather than translating.

The word arrived in Indian data protection drafting through the 2018 report of the Committee of Experts chaired by Justice B.N. Srikrishna. The report described the relationship it wanted to name: "At its core, each relation between data principal and data fiduciary is undergirded by elements which characterise a classic fiduciary relationship: a data principal (data subject) entrusts personal data to a data fiduciary (data controller) for a particular purpose (financial transaction)." It then reasoned from that relationship to a duty: "If abuse of power is to be prevented, it is critical that the data fiduciary is obliged to use the personal data entrusted to it by the data principal only for the purpose for which the principal reasonably expects it to be used." Read the report's own next sentence before carrying that too far. It calls that passage "the germ of the collection and purpose limitation principles", and it had already settled on a wider general obligation earlier in the same chapter, so the sentence is not the origin of the fiduciary duty on its own.

The draft Bill the Committee submitted with that report carried the reasoning into a general clause. Clause 4 read: "Fair and reasonable processing.—Any person processing personal data owes a duty to the data principal to process such personal data in a fair and reasonable manner that respects the privacy of the data principal." Note who it bound. "Any person processing personal data" would have reached a Data Processor directly, without passing through a fiduciary.

That clause is not in the enacted law. The phrase "fair and reasonable" appears 0 times in the DPDP Act 2023 and 0 times in the DPDP Rules 2025, counted on 29 August 2026 across the registered extractions of both instruments. What the Act enacted instead is a list of specific duties, and it addresses almost all of them to the Data Fiduciary. Section 4(1) is the exception, because it opens "A person may process the personal data of a Data Principal only in accordance with the provisions of this Act and for a lawful purpose", and whether that reaches a Data Processor directly is unsettled.

This site therefore reads the word fiduciary as a description of the relationship the Committee set out to name, rather than as an independent source of obligation. On that reading, if a duty is not written into the Act or the Rules, it is not owed because of the label. That reading cuts both ways: it is also why nothing extra can be read into the label by a counterparty drafting a questionnaire.

What did survive is the test itself, and the Rules use its words in a place where the defined term would not sit easily. Item (h) of the Second Schedule to the DPDP Rules 2025 lists "Accountability of the person who alone or in conjunction with other persons determines the purpose and means of processing of personal data, for effective observance of these standards".

Read it for what it is. The Schedule's own heading confines it to processing by the State and its instrumentalities under section 7(b) and to the research, archiving and statistical purposes in section 17(2)(b), and rule 1(4) puts rules 5 and 16, which carry it, in the Rules' own 18 month group, computed as 13 May 2027 and interpretation until officially confirmed, so it requires nothing of anyone today. Items (f) and (g) of the same Schedule do use the defined terms Data Fiduciary and Data Processor. This site therefore reads item (h) as descriptive drafting for the 1 case where the Act itself does not apply, rather than as proof of the general role test. It is consistent with that test; it does not establish it.

Responsibility does not move with the work

"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) settles the question a contract cannot, from the day it commences, and it has not commenced: clause (c) of G.S.R. 843(E) puts section 8 in the 18 month group, computed as 13 May 2027 and interpretation until officially confirmed. On its terms, outsourcing the processing will not outsource the responsibility for it, and "irrespective of any agreement to the contrary" means a clause purporting to shift that responsibility will not shift it.

Section 8(2) adds the precondition: a Data Fiduciary may engage a Data Processor for any activity related to offering goods or services to Data Principals "only under a valid contract". And section 8(7)(b) shows which way the duties run. When personal data must be erased, it is the fiduciary that must "cause its Data Processor to erase any personal data that was made available by the Data Fiduciary for processing to such Data Processor". The duty is the fiduciary's. This site reads the capability as necessarily the processor's, because a fiduciary cannot cause an erasure its processor cannot perform, but that is a reading: the sub-section says nothing about capability and imposes nothing on the Data Processor.

Because of that shape, the contract is where a processor's obligations actually come from. What must be in it and whether you need one at all are separate questions, and what the framework asks of a processor directly is a shorter list than most vendor questionnaires assume.

Getting the label wrong, in either direction

Both errors are common and they fail differently.

Calling yourself a processor when you determine the purpose is the more expensive one. Every Chapter II duty that will attach to you as a Data Fiduciary when Chapter II commences, notice, the erasure timer, security safeguards, breach intimation and grievance redressal, will go unperformed, and no contract with a client will cure it, because section 8(1) does not let responsibility be allocated away by agreement.

Calling a vendor a processor when it decides its own purposes fails in the opposite direction. If the vendor determines the purpose and means for some of the processing, then for that processing it is a Data Fiduciary in its own right and will need its own lawful basis for it under section 4, which commences with the same group. Writing "the vendor acts as a Data Processor" into an agreement does not turn the vendor's own product analytics, model training or data resale into your processing, and it does not give the vendor a basis it lacks.

The reliable habit is to list the processing activities first and label each one, rather than labelling the counterparty and then inheriting that label for everything it touches.

When any of this starts

Section 2 is in force. Clause (a) of the commencement notification G.S.R. 843(E) brought it into force on the date the notification was published, 13 November 2025, so both definitions are law today.

The duties that make the distinction bite are not. Clause (c) of the same notification places "sections 3 to 5, sub-sections (1) to (8) and (10) of section 6,sections 7 to 10, sections 11 to 17" in a group that comes into force 18 months from publication, and section 8 sits inside it, carrying the responsibility rule, the contract precondition and the erasure duties. Sub-section (9) of section 6 is the 1 provision in that span that does not travel with them: clause (b) of the notification puts it 1 year from publication instead. This site computes that as 13 May 2027, which is interpretation until officially confirmed, because the notification states a period rather than a date. The 13 or 14 November question explains why that computation carries a 1 day discrepancy in the Government's own printing.

So the position today is that the vocabulary is law and the duties are not yet. That makes this the cheap moment to fix the labels: an activity map built now is the input to almost everything that lands in May 2027, and correcting a role after the duties attach means correcting the notices, contracts and deletion paths already built on top of it.

What to do with the answer

Run the role checker with one specific processing activity in mind, then run it again for the next activity rather than assuming the answer travels. Where vendors handle data for you, work the vendor and processor checklist against each engagement.

If the answer comes back Data Fiduciary, the duty list is on section 8 and its neighbours in Chapter II. If it comes back Data Processor, Data Processor obligations under DPDP covers what that role actually requires and, more usefully, what it does not.