Data Fiduciary vs Processor: Your SaaS Role Under DPDP

Under India's Digital Personal Data Protection Act 2023, your SaaS company is either a Data Fiduciary, a Data Processor, or both and the role determines everything about your compliance obligations. 

A Data Fiduciary decides why and how personal data is processed. A Data Processor handles data on a Fiduciary's instructions. If your SaaS collects data directly from Indian users to deliver your product, you are a Fiduciary. If you only process data on behalf of another company's customers, you are a Processor. Many SaaS companies are both, depending on the data flow and getting the classification wrong means either over-investing in obligations that do not apply, or missing the ones that do.

Here is how to classify your SaaS correctly, what each role requires, and what happens when you are both.

What the DPDP Act Means by Data Fiduciary

The DPDP Act defines a Data Fiduciary as any person who, alone or in conjunction with others, determines the purpose and means of processing personal data.

Three words carry the weight here: purpose and means.

“Purpose” means why the data is being collected and what it will be used for. If your SaaS decides that you will collect user email addresses to send product notifications, your product determines the purpose.

“Means” means how the data is processed. The methods, systems, and decisions about how data flows through your product and infrastructure. If your engineering team designs those data flows, your company controls the means.

If your SaaS does both, determines why data is collected and decides how it is processed, you are a Data Fiduciary for that data. The obligations that follow are substantial.

Core obligations of a Data Fiduciary

Consent: You are responsible for obtaining valid consent from every Data Principal (the individual) before collecting their personal data. That consent must be specific to each purpose, accompanied by a plain-language standalone notice, and genuinely withdrawable at any time. Consent buried in terms of service does not meet the standard.

Data Principal rights: You must build and maintain a functioning process for users to access what data you hold about them, correct inaccurate data, and request erasure when the purpose of collection has been fulfilled. These are not paper commitments, regulators look for operational evidence.

Security safeguards: The Act requires Data Fiduciaries to implement reasonable security safeguards to prevent breaches. The DPDP Rules specify access controls, access logging and monitoring, data backups, and detection methods for unauthorised access. Failure here carries the highest penalty in the Act: up to ₹250 crore.

Breach notification: Any personal data breach must be reported to the Data Protection Board immediately on discovery, and affected users must be notified within 72 hours. There is no harm threshold, every breach triggers this obligation regardless of scale or severity.

Grievance Redress Officer: Data Fiduciaries must appoint a Grievance Redress Officer and publish contact details so users can raise complaints. This is a specific requirement with no GDPR equivalent.

Data processor oversight: If you engage third parties to process data on your behalf, cloud providers, analytics tools, customer support platforms, you are responsible for ensuring those processors meet the Act's security and handling standards. The contract with each processor must define processing scope, security obligations, and breach notification requirements.

Digisecuritas' DPDP Compliance Services build the full Data Fiduciary compliance programme, consent architecture, rights fulfilment processes, security safeguards, breach notification, and processor contracts, scoped to your SaaS product and data flows.

What the DPDP Act Means by Data Processor

A Data Processor is any person who processes personal data on behalf of a Data Fiduciary, and only in accordance with the Fiduciary's instructions.

The defining characteristic is absence of independent decision-making. A Processor does not decide why data is collected or what it is used for. It receives instructions from the Fiduciary and executes them.

Common SaaS examples of Data Processors:

• A cloud infrastructure provider hosting a SaaS application on behalf of that SaaS company

• A payment gateway processing transactions on behalf of a merchant

• An email delivery service sending notifications on behalf of a SaaS platform

• A data analytics vendor processing user behaviour data on behalf of its SaaS client

In each case, the processor handles personal data, but the decisions about purpose and means belong to the Fiduciary they serve.

What Data Processors are responsible for under DPDP?

The DPDP Act places fewer direct statutory obligations on Processors than on Fiduciaries. Processors are not directly required to obtain consent, manage data principal rights, or appoint a Grievance Redress Officer, those obligations sit with the Fiduciary.

However, Processors carry two significant responsibilities:

Contractual compliance: Processors must process personal data only as instructed by the Fiduciary, within the terms of a contract that meets the Act's requirements. Processing beyond those instructions creates liability.

Security safeguards: Processors are required to implement security measures to protect the personal data they handle. The standard mirrors what is required of Fiduciaries, access controls, logging, backups, breach detection. A processor breach that exposes a Fiduciary's user data creates liability for both parties.

Breach notification upstream: While the Fiduciary holds the direct obligation to notify the Data Protection Board and affected users, Processors must notify the Fiduciary immediately on discovering a breach. That upstream notification is what enables the Fiduciary to meet its 72-hour window to users.

Many SaaS Companies Are Both. Here Is How to Identify

This is where the classification becomes genuinely complicated. Most SaaS companies operate in both roles simultaneously, depending on the data flow in question.

Consider a B2B SaaS company that sells project management software to enterprise clients:

As a Data Fiduciary: The SaaS company collects personal data from its own users, account holders, billing contacts, to manage the commercial relationship. The SaaS company determines the purpose (account management, billing, product notifications) and means of that processing. For this data, the SaaS company is a Fiduciary.

As a Data Processor: The same SaaS company processes the data that its enterprise clients upload into the product, their employees' task data, project files, internal communications. The enterprise client determines why that data is in the system and what it is used for. The SaaS company processes it on the client's behalf. For this data, the SaaS company is a Processor.

The compliance implications are different for each role, applied to different data flows within the same product. Getting this mapping right is foundational, every compliance obligation that follows depends on correctly identifying which role applies to which data.

A practical mapping exercise covers three questions for each category of personal data in your product:

1. Who decided to collect this data and why?

2. Who designed the processing method and controls the data flows?

3. Is there a client or upstream entity whose instructions govern the processing?

If your company made the decisions in questions 1 and 2 independently, you are the Fiduciary. If a client's instructions govern the processing in question 3, you are likely the Processor for that data.

Digisecuritas' Data Classification and Protection Strategy service maps your SaaS data flows against the Fiduciary and Processor definitions under DPDP, producing a role classification that drives the rest of your compliance programme. For companies that have already run a GDPR controller-processor mapping, this extends and adapts that work rather than starting from scratch.

Significant Data Fiduciaries: A Third Category

The DPDP Act creates a further classification for large-scale Fiduciaries: the Significant Data Fiduciary (SDF). The Central Government designates SDFs based on factors including the volume and sensitivity of personal data processed, risk to data principals, national security implications, and impact on sovereignty.

SDFs carry obligations beyond standard Fiduciaries:

• Appointment of a Data Protection Officer based in India

• Annual Data Protection Impact Assessments (DPIAs)

• Regular independent data audits

• Additional data localisation requirements under Rule 12 of the DPDP Rules

For SaaS companies processing large volumes of Indian user data, particularly in financial services, health, or consumer platforms, SDF designation is a genuine possibility. Our detailed guide on Significant Data Fiduciary obligations under DPDP covers what designation means operationally and how to prepare.

Role Classification and Third-Party Risk

Whether your SaaS is a Fiduciary or a Processor, your relationship with the vendors and cloud providers in your stack has compliance implications.

As a Fiduciary, every vendor you engage to process Indian user data on your behalf needs a contract that meets the Act's Data Processor requirements. Your cloud provider, analytics vendor, and customer support platform are all in scope. Building that vendor oversight programme is a core part of DPDP compliance for any SaaS operating as a Fiduciary.

As a Processor, your relationship with your upstream Fiduciary clients needs to be documented in a contract that defines your processing scope, security obligations, breach notification obligations upstream, and data deletion on termination. SaaS companies that sell into enterprise clients need these contracts in place for every client whose data includes Indian user personal data.

The discipline of mapping and managing those relationships is covered in depth in our third-party vendor risk management guide, which applies directly to the vendor oversight obligations Fiduciaries carry under DPDP.

A Practical Classification Checklist

Use this to identify your role for each category of personal data in your product:

You are likely a Data Fiduciary if:

• Your product directly collects personal data from Indian users at signup, onboarding, or during product use

• Your company determines what data is collected and what it is used for, independently of client instructions

• Your engineering team designs the data flows and processing methods

• You have a direct relationship with the individuals whose data you hold

You are likely a Data Processor if:

• You process personal data uploaded or provided by a client, not collected directly from individuals

• The client determines the purpose of processing and you follow their instructions

• You have no direct relationship with the individuals whose data you are processing

• Your contract with the client defines the scope and limits of your processing

You are likely both if:

• You collect your own user data for account management and also process client-uploaded data within the same product

• Different data categories within your product answer the classification questions differently

Final Thoughts

The Data Fiduciary and Data Processor classification is not a formality. It is the lens through which every other DPDP obligation is determined, what consent you need, what rights you must fulfil, what contracts you need with vendors and clients, and what the regulator will look for if they ever examine your programme.

Most SaaS companies, when they actually map their data flows against these definitions, find they are operating as both in different parts of their product. That is not a problem. it is the normal state for a product-led SaaS with its own users and enterprise clients. The problem is operating without having mapped it.

A compliance programme built on an incorrect or unmapped role classification will have gaps that are hard to identify until a regulator or a client due diligence process surfaces them.

Digisecuritas helps SaaS companies map their data flows, classify their role under DPDP correctly, and build the compliance programme the classification requires. Book a Discovery Call to walk through your specific product architecture and understand exactly where your obligations sit.