Does DPDP apply to B2B SaaS companies?

A B2B label does not decide a role, and section 2's role definitions are not themselves duties. As at 27 October 2026, those definitions are in force, while the main applicability, lawful processing and Data Fiduciary obligations discussed below are not. Once the relevant provisions commence, a SaaS provider can be a Data Fiduciary for one processing activity and a Data Processor for another.

Diagram headed "B2B SaaS: test scope, then role, then duty". A status band says that as at 27 October 2026, section 2's role definitions are in force while sections 3, 4 and 8 and Rule 6 are not. Step 1 says section 3 must reach the processing and that its exclusions plus section 17 may change the result. Step 2 applies the role test per flow: setting purpose and means points to Data Fiduciary, while acting on a Data Fiduciary's behalf points to Data Processor, and the same company can be both across different flows. Step 3 shows the explicit processor chain: section 8(1) leaves responsibility with the Data Fiduciary, section 8(2) permits processor involvement for an activity related to offering goods or services to Data Principals only under a valid contract, and Rule 6(1)(f) requires an appropriate security provision wherever applicable. A reading note says section 4(1) is framed on a person, so its direct effect on a processor is this site's interpretation rather than an express processor duty. The footer says the 18 month group is computed to 13 May 2027, may fall as late as 15 May 2027, and remains interpretation until officially confirmed.

Open the role map at full size.

First ask whether section 3 reaches the processing

Role comes after scope. When section 3 commences, clause (a) will cover processing of digital personal data within India where the data was collected digitally or was collected in another form and digitised later. Clause (b) will also cover processing outside India where it is connected with an activity related to offering goods or services to Data Principals within India.

Those are not the only words in the test. Section 3(c) excludes the personal data categories it names, and section 17 contains separate routes that can disapply the Act or named provisions when their conditions are met. A statement that every SaaS handling digital personal data is covered would therefore be too broad. The applicability checker walks the scope facts before it asks who holds which role.

Role 1: Data Fiduciary where you set purpose and means

The definition asks who, alone or with others, determines the purpose and means of processing personal data. A SaaS provider commonly does that for activities such as its own marketing leads, trial accounts, billing contacts, support contacts and product analytics. Where it does, it is the Data Fiduciary for that processing.

The individual remains the Data Principal even when the contact sits inside a customer company. But a named administrator is not automatically the SaaS provider's own Data Fiduciary flow. The answer still depends on who determines the purpose and means for that processing.

The Data Fiduciary and Data Processor role guide owns the general role comparison. This page applies that test specifically to SaaS processing flows.

Once the relevant provisions commence, the Data Fiduciary duties applicable to the processing will attach. Which ones apply depends on the facts. Child duties require the facts named in section 9, Significant Data Fiduciary duties require a notification under section 10, and section 17 can change the result. The business obligations map owns that duty analysis.

Role 2: Data Processor where you act on a customer's behalf

Section 2(k) defines a Data Processor as a person processing personal data on behalf of a Data Fiduciary. Customer records stored in a SaaS product can fit that role where the customer is the Data Fiduciary and the provider processes them on its behalf. The definition does not assign the role merely because the product is B2B, cloud based or located in a particular country.

The phrase count is useful because it shows how the Act and the English Rules structure the relationship. Counted again across the complete English texts on 27 October 2026:

The 9 Act occurrences appear in section 2(k), section 6(6) and its Illustration, sections 8(1), 8(2), 8(5), section 8(7)(b) twice, and section 11(1)(b). The 6 English Rules occurrences appear in Rule 6(1), clauses 6(1)(b) and 6(1)(f), Rule 8(3), its Illustration Case 2, and item (f) of the Second Schedule.

No operative duty among these 15 mentions is framed as "A Data Processor shall." Section 2(k) defines the role. That count is an applicability conclusion, not a complete statement of everything that can affect a processor.

Section 4(1) uses the broader word "person", so direct effect on a processor remains this site's interpretation rather than an express processor duty. Separate laws, including the current CERT In direction, may also apply. Data Processor obligations under DPDP owns that full analysis.

Where a processor is involved for an activity related to offering goods or services to Data Principals, section 8(2) permits that involvement only under a valid contract. Rule 6(1)(f) adds a security provision wherever applicable. The contract decision guide owns when that condition applies; the clauses guide owns agreement content; and the vendor and processor checklist tests implementation capabilities.

An offshore SaaS can be reached after section 3 commences

Once section 3 commences, processing outside India can fall within the Act where it is connected with an activity related to offering goods or services to Data Principals within India. Being offshore does not answer the question, but neither does the presence of 1 Indian user by itself: the statutory test is the connection to the offering activity, read with the rest of section 3 and any applicable section 17 route.

The separate foreign companies guide owns the complete scope analysis, including section 17(1)(d) for certain processing in India under a contract with a person outside India. This page does not turn that conditional route into a general SaaS exemption.

When the DPDP duties start

The DPDP obligations discussed here do not yet operate. Section 2's definitions are in force, but sections 3 to 5, section 6(1) to (8) and (10), sections 7 to 17, and Rules 3 and 5 to 16 are in their respective 18 month groups.

This site computes that group to 13 May 2027. The date is interpretation until officially confirmed. The Gazette masthead and eGazette file code differ by 1 day, and the instruments do not state how the period is counted, so the date could fall as late as 15 May 2027. The commencement date article explains both uncertainties.

Enterprise customers may ask for terms before the legal group commences because procurement and renewals run on their own calendars. Treat the next renewal as a commercial planning date, not as the legal commencement date.

What to do now

The steps below are this site's practical recommendations. They are preparation for future DPDP duties, not a statement that those duties already bind a processor.

Map each processing flow before assigning a company wide role. Record who determines purpose and means, who acts on whose behalf, what section 3 route could apply and which data sit outside the Act. The role checker works flow by flow.

Prepare the Data Fiduciary side where the provider sets purpose and means. Use the business obligations map to identify which future duties attach to that processing rather than treating a short list on this applicability page as complete.

Prepare the processor side as contract and product readiness. Agree security terms, deletion instructions, retention handling and a customer incident escalation period. The escalation period is a contractual recommendation, not a direct processor clock created by DPDP. The vendor and processor checklist tests those capabilities from either side.

Keep the current CERT In route separate. Decide whether the provider falls within a named entity class, classify the incident against Annexure I and preserve the 6 hour reporting path where both tests are met. Do not label that current duty as a DPDP duty.