Data Fiduciary vs Data Processor: which one is my company?
Understand where your business sits in the DPDP chain — and what obligations flow from that classification.
When your enterprise client sends a DPDP security questionnaire, one of the first questions is almost always: "In what capacity do you process personal data on our behalf — as a Data Fiduciary or a Data Processor?" If you have to guess, you are not alone. This distinction is one of the most practically important — and most commonly misunderstood — aspects of the DPDP Act 2023.
Getting it wrong has consequences. A company that treats itself as a Processor when it is actually a Fiduciary misses a range of compliance obligations — consent management, breach notification, data principal rights — that it was always supposed to own. A company that over-classifies itself as a Fiduciary may take on more compliance burden than necessary for a simple processing engagement. More practically: when your client's legal team reviews your questionnaire response, a wrong classification signals that your compliance team does not understand the law it is claiming to comply with.
The definitions in plain language
The DPDP Act 2023 defines these terms precisely, but the key distinction is about decision-making authority.
A Data Fiduciary is any person or entity that, alone or jointly with others, determines the purpose and means of processing personal data. "Purpose" means why the data is being processed. "Means" means how it is processed — the tools, methods, and systems. If your company makes those decisions, you are a Fiduciary, regardless of whose data it technically is.
A Data Processor is any person who processes personal data on behalf of a Data Fiduciary, strictly under a contract with that Fiduciary. The Processor does not decide why the data is being processed — the Fiduciary does. The Processor simply executes the processing task as instructed.
Notice what is absent from the Processor definition: the Processor has no direct obligation to the data principal (the individual whose data is being processed). The Processor's obligations run to the Fiduciary, not to the individual, and they are defined by their contract rather than by the Act directly.
Real examples from the Indian IT landscape
Scenario A: Payroll SaaS platform — Data Fiduciary
A payroll software company collects employee salary details, tax information, and bank account numbers directly from its corporate clients and processes them to generate payslips and tax filings. The software company decides what data fields to collect, how to store them, what the retention period is, and how to handle employee queries. Even though the data "belongs" to the employees of the corporate client, the payroll software company is making the core processing decisions. It is a Data Fiduciary — and it is responsible for its own privacy notice, consent mechanisms (where required), data principal rights processes, and breach notification.
Scenario B: BPO handling data entry — Data Processor
A BPO firm receives a nightly file of insurance claim documents from an insurance company and data-entry operators key the information into the insurer's system. The BPO follows the insurer's instructions on exactly what fields to capture, how to handle errors, and when to delete data. The BPO has no discretion over the purpose or methodology of the processing. It is a classic Data Processor. Its DPDP obligations are defined by its contract with the insurer (the Fiduciary) — not by independent legal obligations to the policyholders whose data it processes.
Scenario C: Cloud infrastructure provider — Data Processor (usually)
A company providing cloud hosting or managed database services to enterprise clients typically processes whatever data the client puts into the environment, under the client's instructions, with no knowledge of or control over its purpose. This is generally a Processor relationship. The wrinkle comes if the cloud provider uses the data for its own purposes — improving its own ML models, for instance — in which case it becomes a Fiduciary for that specific use.
Scenario D: HR analytics SaaS — potentially both
A company that provides HR analytics software may be a Processor for the client's employee data that it processes to generate reports, but simultaneously a Fiduciary for the aggregate, anonymised benchmarking data it collects across all its clients to improve its own product. Many modern SaaS companies operate in both capacities simultaneously, across different datasets or different processing activities.
The three-question test to self-classify
If you are uncertain about your classification, work through these three questions for each category of personal data you handle:
Question 1: Who decided that this personal data should be collected in the first place?
If your company decided — you built the product feature that collects it, you defined the onboarding form, you chose to ask for it — you are likely a Fiduciary for that data. If your client told you to collect it, or gave you a dataset they had already collected, you are more likely a Processor.
Question 2: Who decides how long to keep the data and when to delete it?
If your retention schedule is set by your own policies, you are a Fiduciary. If you follow your client's retention instructions — delete it when they say, keep it as long as they need — you are a Processor.
Question 3: Can you use this data for your own purposes — product improvement, analytics, marketing — without asking the client first?
If yes, you are a Fiduciary for that use. If you are contractually prohibited from using the data for anything beyond the client's specific instruction, you are a Processor.
What obligations flow from each classification
The practical consequence of your classification is significant. Data Fiduciaries under DPDP carry direct statutory obligations: they must provide a consent notice to data principals before collecting data, implement security safeguards, notify the Data Protection Board and affected individuals of breaches, establish a grievance redressal mechanism, and ensure that personal data is erased when the purpose is fulfilled. Significant Data Fiduciaries (large-scale Fiduciaries designated by the government) carry additional obligations including Data Protection Impact Assessments and periodic audits.
Data Processors, by contrast, have no direct statutory obligations to data principals. Their obligations are contractual — they must process data only on the Fiduciary's instructions, implement security measures as contractually required, report incidents to the Fiduciary promptly, and submit to the Fiduciary's audit rights. This does not make Processor compliance easy — enterprise clients are demanding increasingly detailed contractual commitments — but the legal structure is different.
Understanding this distinction also helps you respond to clients who ask you to sign a Data Processing Agreement. A DPA is the contractual instrument that defines the Processor's obligations in detail. If you are a Processor, signing a DPA is both legally appropriate and commercially essential.
When classification is genuinely ambiguous
The Fiduciary/Processor line blurs most often in three situations. First, when a vendor provides both a software platform (Fiduciary for the platform data) and managed services running on top of it (Processor for the managed service data). Second, when a vendor uses client data to train its own AI or ML models — even "anonymised" training can raise Fiduciary questions. Third, when a vendor is a sub-processor — a company hired by a Processor, not directly by the Fiduciary — whose obligations run two levels up the chain.
In ambiguous cases, the safest default is to document your analysis in writing, apply the higher standard (Fiduciary) to be conservative, and get legal advice if the contract value justifies it. The DPDP Applicability Checker can help you work through these scenarios quickly with a structured self-assessment.
The classification question also matters for how you respond to clients who are now asking what DPDP compliance means for IT services firms. A Processor relationship requires a DPA. A Fiduciary relationship requires something broader — your own independent compliance programme.
Unsure whether DPDP applies to your company as a Fiduciary or Processor?
Use our free Applicability Checker to get a structured assessment of your DPDP scope in under 5 minutes.
Run the Applicability Checker — FreeFrequently Asked Questions
Can a company be both a Data Fiduciary and a Data Processor?
Yes — and many SaaS companies are. You can be a Fiduciary for data you collect directly from users for your own product, while simultaneously being a Processor for data your enterprise clients push into your system under their instructions. The key is to classify each dataset and processing activity separately, document each classification, and apply the appropriate obligations to each.
Does a Data Processor need a privacy policy?
Not necessarily under DPDP — the privacy notice obligation falls on the Data Fiduciary, not the Processor. However, most enterprise contracts require vendors to have a publicly visible privacy policy regardless of their DPDP classification, because it signals organisational maturity and covers the vendor's own employee data (for which the vendor is always a Fiduciary). A privacy policy is commercially almost always necessary even if it is not strictly legally required for your Processor activities.
What is a Significant Data Fiduciary and do I need to worry about it?
A Significant Data Fiduciary (SDF) is a Data Fiduciary designated by the Indian government based on volume and sensitivity of data processed, potential harm from a breach, and national security considerations. SDFs carry additional obligations including mandatory Data Protection Officers, Data Protection Impact Assessments, and periodic audits. The government has not yet published the list of SDFs — it will do so after the DPDP Rules are finalised. Mid-size IT vendors are unlikely to be designated SDFs in the first wave, but should monitor the government's announcements as the Rules are notified.