DPDP Compliance for SaaS Companies: What Your Customers’ DPAs Can and Cannot Demand

Does the DPDP Act apply directly to a SaaS vendor?

The Act works through roles. A data fiduciary is the person who, alone or with others, determines the purpose and means of processing personal data (section 2(i)). A data processor is any person who processes personal data on behalf of a data fiduciary (section 2(k)). When a Mumbai lender uploads its borrowers’ records to your loan servicing platform, the lender decides why and how that data is used. It is the fiduciary. You are the processor.

Almost every operative duty in Chapter II of the Act is written for the fiduciary: notice, consent, security, breach intimation, erasure, grievance redressal. The Act does not impose a parallel set of duties on processors, and the penalty Schedule is framed around those fiduciary obligations. Section 8(1) makes the fiduciary responsible for processing “undertaken by it or on its behalf by a Data Processor”, irrespective of any agreement to the contrary. Section 8(2) then allows the fiduciary to engage a processor only under a valid contract.

Put together, your regulatory exposure as a vendor is indirect. The customer answers to the Data Protection Board for what you do, and it will pass that risk to you through the contract. That makes the DPA the document that defines your obligations, your liability and your audit burden. It is worth reading it as carefully as the commercial terms.

Two caveats. First, you are a data fiduciary in your own right for your own employees, your sales leads and your own website visitors, so the full Act applies to that data. Second, if you start deciding your own purposes for customer data, you stop being a mere processor for that activity. The section on AI training below explains why that matters. Being a data processor under DPDP Act terms is a description of what you do with the data, not a label the contract can fix.

Why DPDP compliance for SaaS companies starts with customer DPAs

The Rules and the commencement notification G.S.R. 843(E) were published on 13 November 2025. As of October 2026, most substantive obligations, including sections 3 to 17 (other than s.6(9)) and the penalty provisions, are scheduled to apply from 13 May 2027. The government proposed shortening that eighteen-month window in early 2026, and a notification could still bring the date forward, so check the current notification before planning around it.

Your customers are acting now because their exposure is large and their contracts are long. The Schedule to the Act allows the Board to impose penalties of up to ₹250 crore for failing to take reasonable security safeguards (section 8(5)) and up to ₹200 crore for failing to notify a breach (section 8(6)). These are maximums, imposed only where the Board finds a breach significant after an inquiry (section 33(1)), with the amount set using the factors in section 33(2). A three-year subscription signed in late 2026 runs well past May 2027, so procurement teams want DPDP terms in it from day one. See our guide on DPDP penalties and our guide on the enforcement timeline for the detail.

Which customer demands reflect the law?

Some clauses in a customer DPA are the customer meeting its own statutory duty through you. Refusing these makes you hard to buy from, because the customer cannot comply without them. Accept the substance and negotiate only the mechanics. For most teams, SaaS vendor DPDP readiness on these points is mostly product work: a delete path, a log retention setting and a way to act on one person’s record.

• A security safeguards clause. Rule 6(1)(f) requires the fiduciary’s reasonable security safeguards to include an “appropriate provision” in its contract with the processor, wherever applicable. The Rule asks for a provision, not a 40-page schedule.
• Stopping processing when consent is withdrawn. Under section 6(6), the fiduciary must, within a reasonable time, cease and cause its processors to cease processing that person’s data, unless law requires or authorises it. You need a way to act on a named individual.
• Erasure on instruction and at exit. Section 8(7)(b) requires the fiduciary to cause its processor to erase personal data made available to it, unless retention is necessary for compliance with law. Your product needs a reliable delete path, including backups on a defined cycle.
• Keeping logs for one year. Rule 6(1)(e) requires logs and personal data to be retained for one year for detecting and investigating unauthorised access, and Rule 8(3) requires personal data, traffic data and processing logs, including processing by a processor, to be kept for at least one year. Illustration Case 2 to Rule 8 uses a cloud host as its example.
• Help with data principal requests. The rights to access, correction, erasure and grievance redressal in sections 11 to 13 are owed by the fiduciary, but if the data sits in your system the customer cannot answer without you. An assistance clause is recommended practice that follows directly from the law.
• No use of the data for your own purposes. This follows from the definition of a processor in section 2(k). Stating it expressly is recommended practice.

Which DPDP demands can a SaaS vendor negotiate?

Other clauses go beyond anything the Act or Rules require. Most DPDP compliance SaaS questionnaires mix the two groups without saying which is which. They are legitimate commercial requests, and you may choose to accept some of them, but you are negotiating, not complying.

Breach notice within 24 hours is the most common example. Rule 7 requires the fiduciary to inform the Board and affected individuals without delay after it becomes aware of a breach, and to give the Board a detailed report within 72 hours of becoming aware. The Act and Rules set no deadline for a processor to tell the fiduciary. A short contractual window still makes sense, because the customer’s clock may be argued to start when its processor knew, but the length is a commercial choice. A workable vendor position is an initial notice without undue delay and within a fixed short period of confirming a breach, followed by updates covering the Rule 7(2)(b) items.

Unlimited liability for data protection is another. Recovering a regulatory penalty from a vendor under an indemnity is not settled in Indian law, and no SaaS business can price unlimited exposure. A separate, higher cap for data protection claims, sized against your insurance and the contract value, is a reasonable middle position. Audit rights and long security schedules are the third group: offer independent audit reports and a security schedule mapped to Rule 6(1)(a) to (g) first, with an on-site audit only after a confirmed incident or on reasonable notice once a year.

Customer asks, what the law says, and a reasonable vendor position

The table below is the version of this guide most vendors will keep open during a negotiation. “Recommended” means the term is good practice that supports the Act, not a requirement of it.

What does section 17(1)(d) mean for Indian vendors serving only overseas clients?

Many Indian IT services and BPO companies process personal data of people outside India under contracts with clients outside India. Section 17(1)(d) addresses exactly this, and it is the provision to cite when section 17(1)(d) overseas clients ask whether Indian law adds anything to their DPA. Where personal data of data principals not within the territory of India is processed under a contract with a person outside India by a person based in India, Chapter II of the Act (except sections 8(1) and 8(5)), Chapter III (the data principal rights) and section 16 do not apply.

The exemption is narrower than it sounds. Sections 8(1) and 8(5) are expressly kept, so reasonable security safeguards remain a legal requirement, and the ₹250 crore maximum in the Schedule attaches to section 8(5). How these fiduciary duties apply to an Indian vendor whose client is the real decision-maker is not fully settled, but the safe reading is that your security obligations under the Act continue. The exemption also covers only non-residents’ data. If a US client’s dataset includes people in India, that part is outside section 17(1)(d).

In practice, reflect the exemption in your DPA so the client does not expect Indian notice and consent machinery, but do not drop your security commitments on the basis that “DPDP does not apply”. Your client’s own law, such as the EU GDPR, will usually reach you through its contract anyway.

Can you train AI models on customer data?

Many SaaS terms still carry an old clause letting the vendor use customer data to “improve the services”. Read today, that can cover training machine learning models on support tickets, call recordings or CRM records. For personal data, this is where the processor label stops protecting you.

A processor processes on behalf of the fiduciary. If you decide to use a customer’s personal data to train your own models, you are determining a purpose of your own, which is likely to make you a data fiduciary for that processing under section 2(i). You would then need your own ground under section 4, either consent or a legitimate use under section 7, and you have no notice relationship with your customer’s users. The customer has its own problem too: consent under section 6(1) is limited to the specified purpose in its notice, and your model training is unlikely to be in it.

The reasonable vendor position is simple: no training on customer personal data unless the customer opts in for a defined purpose. If you want aggregated product telemetry, define it narrowly in the contract. The Act does not define anonymisation, so the contract definition carries the weight.

Sub-processor lists and the section 11 right

Section 11(1)(b) gives a data principal the right to ask the fiduciary for the identities of all other data fiduciaries and data processors with whom her personal data has been shared, with a description of the data shared. Your customer cannot answer that without knowing who you use: your cloud host, your email delivery service, your support tooling, your analytics provider.

Keep a current public sub-processor list with each provider’s function and location. Give advance notice of additions, flow down the same security and erasure terms, and remain responsible to the customer for your sub-processors. None of this is required of you by the Act, but it is the cheapest way to make your customer’s section 11 answers accurate. Section 16 lets the government restrict transfers to notified countries; as of October 2026 no such restriction had been located, though sectoral rules such as RBI payment data localisation still apply to regulated customers.

A ready DPA for SaaS India deals shortens the sales cycle

Vendors who wait for the customer’s paper end up negotiating twenty different DPAs, each drafted for the customer. A vendor that sends its own DPA with its order form usually negotiates from its own text, and enterprise procurement teams often accept a well-drafted vendor DPA with a few changes.

A ready pack for DPDP compliance for IT services and SaaS contains a DPA that names the roles, a security schedule mapped to Rule 6, a sub-processor list, an erasure and log retention statement, a breach notification procedure and a short note on section 17(1)(d) for overseas work. See our guides on data processing agreement clauses, data fiduciary vs data processor roles and our free data processing addendum template.

Why check your DPAs with ClauseAudit before 13 May 2027?

The pressure on your customers is real. Section 8(1) makes them answer for your processing, the Schedule allows penalties of up to ₹250 crore for security failures, and many contracts signed before November 2025 are likely to say nothing about DPDP. Many renewals are likely to come with a DPA, and some will contain terms the law does not require.

You have three honest options. An advocate’s review is thorough and is the right choice for material deals, but it is slower and costs more per contract. A free checklist is fast, but you still have to read every clause yourself and decide what is law and what is a commercial ask. The ClauseAudit DPDP Compliance Check takes minutes and costs ₹999 per contract. It reads every clause, including schedules and annexures, and labels each finding either as required by the DPDP Act or Rules, with the section or rule, or as recommended practice. You choose the vendor (data processor) side, so the findings read from your position, and you get a suggested redline and a negotiation email. The original document is not stored after the review.

It is an AI-assisted review and can miss things. For large or sensitive deals, children’s data at scale, or regulated customers in banking, insurance or health, have an advocate review the contract.