DPDP for SaaS: two roles, one product

A SaaS company sits on both sides of the DPDP Act. Your customers hand you their employees', patients' or shoppers' data to process on their behalf. At the same time, you collect your own data: admin accounts, trial sign-ups, billing contacts, website leads and product analytics. The Act treats these two very differently.

Getting this split right is the whole game for SaaS. It decides which notices you publish, which consents you need, what goes in your DPA and how you answer the security questionnaire that arrives with every enterprise deal.

Is a SaaS company a data fiduciary or a data processor?

A Data Fiduciary decides the purpose and means of processing (section 2(i)). A Data Processor processes on behalf of a fiduciary (section 2(k)). The role belongs to each data flow, not to the company.

As a fiduciary, all the Act's obligations apply to you directly: notice, consent, security, breach intimation, retention, rights and grievances. As a processor, the Act mostly works through your customer. Section 8(1) makes the fiduciary responsible for processing done on its behalf, and section 8(2) lets it engage a processor only under a valid contract. Your customers will therefore push their obligations into your contract. Our fiduciary vs processor guide has the full test.

The reference case study, an illustrative implementation, shows the split in practice: a payroll SaaS with 1,420 customers that was a processor for employee payroll data and a fiduciary for its own employee-facing app, with nobody having drawn the line between the two.

When does a SaaS vendor become a fiduciary for customer data?

The moment you use customer data for your own purposes, you decide the purpose and means for that use, and you are a fiduciary for it. Common examples:

• Product analytics that capture end users' names, emails or phone numbers as event properties and are used to improve your product or sales.
• Cross-sell or marketing to your customers' end users or employees.
• Benchmarking reports built from identifiable customer data.
• Sharing with partners for their purposes.

The DPDP Act has no “legitimate interests” ground. For these uses you need the person's consent under section 6, or one of the specific legitimate uses in section 7, and in most of these cases none of the section 7 uses fit. The practical options are to stop, to remove identifiers before the data reaches your analytics, or to get consent through a notice you control. Strip personal fields from analytics events by default; it is cheaper than a consent flow.

What will enterprise customers ask?

Enterprise buyers are adding DPDP questions to their security and vendor questionnaires. The themes repeat:

What should a DPDP DPA include?

The Act does not prescribe DPA wording. These are the clauses that map to its requirements and that enterprise buyers expect. Your counsel drafts; we help make sure the product can keep each promise.

• Roles and instructions: you process only on the customer's documented instructions and for the services.
• Security: the Rule 6 measures (encryption, access control, logging and monitoring, backups, one-year log retention), described concretely.
• Breach notice: a fixed number of hours from confirmation, with the facts the customer needs for its Rule 7 report.
• Sub-processors: a published list, advance notice of changes, an objection route, and the same terms flowed down.
• Assistance with rights: help to answer access, correction and erasure requests within the customer's deadlines.
• Consent withdrawal: stop processing a person's data on the customer's instruction, so the customer can meet section 6(6).
• Retention and erasure: erase on instruction and at exit, covering backups on a stated cycle, with confirmation; keep logs for at least one year where Rule 8(3) requires.
• Location: where data is stored and accessed, and notice before changes.
• Audit: reports, certifications and reasonable audit rights.

Which tenant-level controls should you build?

Contract promises are easier to keep, and easier to sell, when the product enforces them. The controls that remove most procurement friction are:

In the reference case study, one admin console section let each tenant set retention periods, export everything, delete leavers' records after their statutory period, view an access log and see the sub-processor list. That single page answered a large share of procurement questions before they were asked.

How do you run a sub-processor register?

Your customers are responsible for your sub-processors, through you. Keep one register that engineers update and that feeds your public list, so the two never drift apart.

Review it quarterly. Any tool that receives tenant data, including analytics, error tracking and session replay, belongs on it. Cross-border hosting is allowed under the Act today; see the cross-border guide for the conditions.

How fast should a SaaS vendor report a breach to customers?

Under Rule 7, your customer, as fiduciary, must inform the Board and each affected person without delay, and send the Board a detailed report within 72 hours of becoming aware. Section 8(6) has no materiality threshold: every personal data breach is reportable. The customer cannot start until you tell them, so your notice window eats into theirs.

Commit to a window measured in hours. The reference case study committed to notify customers within 24 hours of confirmation, working back from the Board's 72 hours. CERT-In's separate 6-hour reporting direction (April 2022) continues to apply in parallel for reportable cyber incidents, so check whether it reaches you directly. The breach notification guide covers the content of each notice.

What does Rule 6 security mean for a SaaS product?

Rule 6 sets minimum safeguards for fiduciaries and requires them to be written into processor contracts. For a SaaS product, they usually map to: encryption at rest and in transit, with per-tenant keys where practical; role-based access with just-in-time support access; centralised logs with monitoring and review; tested backups and restores; at least one year of log retention; security terms in every sub-processor contract; and named owners who check the controls work. Failing to take reasonable security safeguards carries the highest penalty in the Schedule, up to ₹250 crore, and as a fiduciary for your own users that ceiling applies to you directly. Our security safeguards guide covers each measure.

What to do next

1. Map roles per flow and write a one-page role statement for your DPA and website.
2. Clean analytics: remove personal fields from events, or move those uses under your own consent.
3. Publish a DPDP DPA with your counsel, and a live sub-processor list.
4. Ship tenant controls for retention, export, deletion and audit logs.
5. Set the breach chain: a notice window in hours, a runbook and a drill.
6. Handle your fiduciary side: notices, consent and rights for your own users and leads.

Track it against the compliance checklist, with 13 May 2027 as the deadline. If you want an engineering-led team to run this alongside your counsel, as in the reference case study, talk to us.

This guide explains the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 as notified on 13 November 2025. It is general information, not legal advice. Check the official text, and your counsel, before relying on it.