Does DPDP apply to B2B SaaS companies?

B2B teams often treat a personal data law as a consumer problem and therefore someone else's. The accurate picture is that a SaaS company holds 2 roles at once, and that the 2 roles are not symmetrical in a way that matters commercially.

Role 1: you are a Data Fiduciary for your own users

Your marketing site visitors, trial signups, webinar registrants, support contacts and the named administrators inside customer workspaces are people whose data you collect for your own purposes: selling, onboarding, support, billing, product analytics.

The definition turns on that: a Data Fiduciary is a person who, alone or with others, "determines the purpose and means of processing of personal data". You decide those purposes, so for that data you are the fiduciary and the whole duty set is yours. Notice, a lawful ground, safeguards, breach intimation, erasure, the rights machinery, the published contact. None of it is softened because your customers are companies. The Data Principal is the individual, and an individual at a company is still an individual.

This is the half B2B companies underweight, and it is the half where the duties are addressed to you by name.

Role 2: you are a Data Processor for customer data, and the framework almost never addresses you

The end user records your customers keep in your product are processed on their behalf, under their instructions. That is the definition: a Data Processor is "any person who processes personal data on behalf of a Data Fiduciary". Purely relational, with nothing in it about size or location.

Now the finding that changes how a SaaS company should read this framework. Counted across the full Gazette text of both instruments on 27 August 2026:

All 15, listed so you can check them: section 2(k) defines the term; section 6(6) and its Illustration have the fiduciary cease and cause its processors to cease; section 8(1) makes the fiduciary responsible for processing done on its behalf; section 8(2) permits the fiduciary to engage a processor only under a valid contract; section 8(5) has the fiduciary protect data including where a processor handles it; section 8(7)(b) has the fiduciary cause its processor to erase, and uses the term twice in that one clause, which is why 8 places in the Act carry 9 occurrences; section 11(1)(b) gives a Data Principal the right to obtain from the fiduciary the identities of the processors with whom her data has been shared. In the Rules: Rule 6(1) and 6(1)(b) on safeguards covering processor systems, Rule 6(1)(f) on the contract, Rule 8(3) on log retention, the Illustration to Rule 8, and item (f) of the Second Schedule.

Neither instrument contains a sentence beginning "A Data Processor shall". There is no processor register, no breach intimation duty of its own in either instrument, and no penalty entry aimed at a processor as such.

One provision does not fit the pattern, so do not state the point more strongly than that. Section 4(1) is framed on "a person" rather than on a Data Fiduciary, and section 2(s) defines person to include a company, so whether it binds a processor acting on a customer's instructions is an open question. The accurate statement for an applicability answer is that no duty is addressed to you as a Data Processor, not that the Act says nothing to you at all. Data Processor obligations under DPDP works through that question, the enforcement provisions that point the same way, and the 1 reporting duty that already binds a vendor in its own name today, which is the CERT-In 6 hour clock and not DPDP.

If you are carrying assumptions across from a regime where processors have their own direct obligations, that assumption does not hold on this side. Read the counts above and check them in the text rather than taking our word for it.

Which is why the contract is the entire mechanism

Nothing above means a SaaS vendor is unaffected. It means the pressure arrives through your customer, and through the document between you.

Section 8(2) is the hinge:

"A Data Fiduciary may engage, appoint, use or otherwise involve a Data Processor to process personal data on its behalf for any activity related to offering of goods or services to Data Principals only under a valid contract."

Read carefully, that is a duty on your customer to have a contract, not a duty on you to sign a particular one. And the Act does not say what the contract must contain. "Valid contract" is not defined in it.

The Rules then add the first specified element. Rule 6(1)(f) makes it part of the fiduciary's own safeguards duty to have:

"appropriate provision in the contract entered into between such Data Fiduciary and such a Data Processor, wherever applicable, for taking reasonable security safeguards"

So security terms in the vendor contract stop being good practice and become an element of your customer's compliance. Expect them to ask, and to ask in writing, because their duty is discharged by the provision existing.

2 more places the contract has to do work, and they pull against each other:

• Erasure flow down. Section 8(7)(b) requires the fiduciary to cause its processor to erase data it made available. Your deletion path is your customer's compliance path.
• A 1 year retention floor that reaches into your systems. Rule 8(3) requires the fiduciary to retain personal data, associated traffic data and other logs for at least 1 year from the date of processing for the Seventh Schedule purposes, including "in respect of any processing... on its behalf by a Data Processor". The Illustration to Rule 8 is squarely about a vendor like you:

"Case 2: X, a company engages a cloud service provider C as its Data Processor to host customer records. X as the Data Fiduciary, is required to ensure that the C also retains the data and associated logs for at least one year before erasure, unless any other applicable law requires a longer period."

That is the clearest statement in either instrument of how this framework sees a hosted service: the duty sits on the customer, and the customer must ensure the vendor does it. Which means your product needs to be able to do both things on request, delete and retain, for different data and different customers, and your contract has to say which applies when.

For what the document itself should carry, the clauses a DPDP data processing agreement needs works through the anchors, and the vendor and processor checklist runs it from either side of the relationship. For the operational side of role 2, what to build and what actually binds you today, see Data Processor obligations under DPDP.

An offshore SaaS with Indian users is still reached

Geography is not a way out of role 1. The Act "also apply to processing of digital personal data outside the territory of India, if such processing is in connection with any activity related to offering of goods or services to Data Principals within the territory of India".

There is no local representative duty attached to that, and no registration for a foreign vendor. Does DPDP apply to foreign companies sets out the full application provision, the outsourcing carve out in section 17(1)(d) that matters if you are an Indian vendor to foreign clients, and the blocking power in section 37.

When this starts

None of it binds anyone today. Sections 3, 6, 8 and 11 are all named in paragraph (c) of commencement notification G.S.R. 843(E), the group coming into force 18 months after publication, and Rule 1(4) puts Rules 6 and 8 in the Rules' own 18 month group. That computes to 13 May 2027, interpretation until officially confirmed.

The practical consequence for a SaaS company is unusual, though. Your customers will ask for contract terms long before the duty bites, because enterprise procurement moves on renewal cycles rather than on commencement dates. The contract work is the part that has a real deadline, and it is set by your renewal calendar and not by the Gazette.

What to do

Split your data map by role before anything else. Your own users on one side, customer end user data on the other. The role checker does this per data flow rather than per company, which is the right unit: the same entity is a fiduciary and a processor at the same time.

Treat role 1 as the real compliance project. That is where duties are addressed to you, and where a notice, a lawful ground, a deletion path and a published contact are your own obligations.

Treat role 2 as a contract and product readiness project. Deletion on instruction, log retention on instruction, breach notification to your customer inside their clock rather than yours, and the ability to be named in their subprocessor list.

Do not tell customers the Act names you as the duty holder. Every provision in the Act and the Rules that mentions a Data Processor is addressed to the Data Fiduciary, and a vendor that claims otherwise in a security questionnaire will be asked to point at the provision. Do not go further and tell them nothing in the framework reaches you: section 4(1) is framed on any person who processes personal data, and the CERT-In reporting duty already binds you.