The Hidden Liability in Your Tech Stack: Why Your SaaS Vendors Expose You Under the DPDP Act

The Hidden Liability in Your Tech Stack: Why Your SaaS Vendors Expose You Under the DPDP Act

Quick exercise. Open a blank document and list every software tool your business used this week.

Your CRM. Your cloud hosting. Your email marketing platform. Your analytics dashboard. Your payment gateway. Your HR and payroll software. Your customer support chat tool. Your project management app.

Most founders get to ten or fifteen tools before they stop counting. Now here is the question that matters: if any one of those vendors suffers a data breach tomorrow morning, who does the Data Protection Board of India hold responsible?

Not the vendor. You.

In our previous article, we established that the DPDP Act, 2023 applies to every Indian website that collects personal data, with no small business exemption. This article picks up where that one ended. Knowing the law applies to you is step one. Step two is understanding that under the DPDP framework, legal responsibility does not stop at your own servers and your own employees. It follows your data wherever it goes, into every SaaS subscription, every cloud bucket, and every third-party integration in your stack.

The good news: this exposure is fixable. It is fixed through contracts, specifically through Data Processing Agreements, and through a structured audit of the tools you already use. This article shows you exactly how.

The Fiduciary Trap: Why You Answer for Your Vendors

Data Fiduciary vs Data Processor: The Distinction That Decides Everything

The DPDP Act divides the data world into two roles, and almost every liability question in this article flows from the difference between them.

A Data Fiduciary is the entity that decides why and how personal data is processed. If you run a business that collects customer names, emails, phone numbers, payment details, or employee records, you are a Data Fiduciary. You chose to collect that data. You decided what to do with it. The law attaches responsibility to that decision.

A Data Processor is any entity that processes personal data on behalf of a Data Fiduciary. Your CRM processes customer data on your behalf. Your hosting provider stores it on your behalf. Your analytics tool tracks it on your behalf. They are all Data Processors.

Here is the part that catches most businesses off guard. Section 8(1) of the DPDP Act makes the Data Fiduciary responsible for compliance with the Act, including for processing carried out by a Data Processor on its behalf, irrespective of any agreement to the contrary. Read that last phrase again. No contract, no terms of service, and no disclaimer can shift your statutory responsibility to your vendor.

What This Means for You: The DPDP Act creates a one-way street of accountability. Your vendors owe you whatever your contract says they owe you. You owe the regulator everything the Act says you owe. If those two documents do not line up, the gap comes out of your pocket.

The Only Control You Have Is Contractual

Section 8(2) of the Act adds one more rule that most founders have never read: a Data Fiduciary may engage a Data Processor only under a valid contract. That is not a suggestion. It is a statutory condition for lawfully sharing personal data with any vendor at all.

Think about what that means in practice. Every tool in your stack that touches personal data without a valid contract covering that processing is not just a compliance gap. It arguably makes the sharing itself unlawful, independent of whether any breach ever occurs.

The law, therefore, hands you exactly one instrument of control over your vendors: the contract. What you put in it, or fail to put in it, determines how exposed you are when something goes wrong. That brings us to the scenario where this gets expensive.

The 72-Hour Window: Why Standard SaaS Terms Will Fail You

What the Law Demands When a Breach Happens

The DPDP Rules, 2025, notified on November 13, 2025, turned Section 8(6) of the Act into a concrete, timed obligation under Rule 7. When a personal data breach occurs, the Data Fiduciary must do three things:

• Notify every affected Data Principal without delay, in clear and plain language, describing the breach, its likely consequences, the mitigation underway, and the protective steps they can take
• Send an initial intimation to the Data Protection Board without delay, covering the nature, extent, timing, and likely impact of the breach
• File a detailed report with the Board within 72 hours of becoming aware of the breach, including the full facts, the cause, the remedial measures, and what affected users were told

Two features of this rule deserve emphasis. First, there is no harm threshold. A breach affecting fifty records triggers the same notification duty as one affecting five million. Second, the 72-hour clock starts when you become aware of the breach, not when you finish investigating it. If your report is incomplete at hour 72, you file what you have and update the Board later.

And the penalty for getting this wrong is not symbolic. Failure to notify the Board and affected individuals sits in its own tier under the Act's Schedule, carrying a penalty of up to Rs. 200 Crore. The separate failure to maintain reasonable security safeguards carries up to Rs. 250 Crore.

The Notification Gap Hiding in Your Vendor Agreements

Now run the scenario honestly. Your email marketing vendor gets breached at 2 AM on a Saturday. Customer names, email addresses, and campaign data are exposed. Your 72-hour clock starts when you become aware. So the critical question is: when does your vendor tell you?

Open your vendor's standard terms of service and look for the breach notification clause. In most standard SaaS agreements, you will find one of three things:

• No notification commitment at all. Many standard terms simply do not address breach notification to customers
• A vague commitment. Phrases like "commercially reasonable efforts" or "without undue delay" with no fixed timeline
• A GDPR-shaped commitment. Global vendors often promise notification within 72 hours, calibrated for European controllers, not for a fiduciary who needs time to assess, verify, and file with the Indian Board inside the same window

Do the arithmetic. If your vendor notifies you at hour 60 of its own internal timeline, you have 12 hours to understand what happened, assess which of your Data Principals are affected, draft compliant notifications, and file with the Board. That is not a compliance process. That is a coin flip with a Rs. 200 Crore downside.

What This Means for You: A standard click-through SaaS agreement is drafted to protect the vendor, and it was almost certainly not drafted with the DPDP Act in mind. Unless your contract gives you a firm, short vendor-to-you notification timeline, your 72-hour obligation is a deadline you cannot control.

Do Not Forget CERT-In

The DPDP notification duty does not replace the older obligation under the CERT-In Directions, 2022, issued under Section 70B of the IT Act, 2000. Reportable cyber security incidents must be reported to CERT-In within 6 hours of noticing them. A vendor breach that exposes personal data will usually qualify as both a DPDP personal data breach and a CERT-In reportable incident. Two regulators, two clocks, one incident. Your incident response plan and your vendor contracts need to account for both.

DPA Non-Negotiables: The Clauses Every Vendor Contract Must Now Include

A Data Processing Agreement is the contract, or contract addendum, that governs how a vendor processes personal data on your behalf. Under the DPDP framework, it is the document that converts your statutory exposure into enforceable vendor obligations. Here are the clauses that are no longer optional.

1. Defined Purpose and Documented Instructions

The DPA must state exactly what personal data the vendor may process, for what purpose, and confirm that the vendor processes only on your documented instructions. This mirrors the Act's own logic: the fiduciary decides, the processor executes. A vendor that uses your customer data for its own purposes, such as product improvement or model training, steps outside the processor role and creates a compliance problem you did not authorise.

2. A Hard Breach Notification Timeline

This is the clause that makes the 72-hour rule survivable. Demand written notification of any personal data breach within a fixed number of hours of the vendor becoming aware, with 24 to 48 hours as the working standard. The clause should require the notification to include the nature of the breach, the categories and approximate volume of data affected, and the containment steps underway, so that your own Board filing has substance. Vague "prompt notification" language is not a timeline. Strike it or define it.

3. Security Safeguards With Teeth

Section 8(5) makes you responsible for reasonable security safeguards even when the data sits on your vendor's infrastructure. The DPA must therefore specify the vendor's security obligations: encryption standards, access controls, vulnerability management, and certifications such as ISO 27001 or SOC 2 Type II where proportionate. "Industry standard security" without definitions is a placeholder, not a safeguard.

4. Sub-Processor Controls

Your vendor has vendors. Your CRM runs on someone else's cloud; your support tool pipes data through someone else's infrastructure. The DPA must require the vendor to disclose its sub-processors, flow down equivalent obligations to them, and give you the right to object to new sub-processors that will touch your data.

5. Audit and Inspection Rights

You cannot verify what you cannot examine. The DPA should give you the right to audit the vendor's compliance, directly or through independent third-party reports and certifications. For most SaaS vendors, the practical compromise is annual third-party audit reports plus a right to question and escalate. Accept that compromise consciously, not by default.

6. Data Principal Rights Assistance

Under the DPDP Act, your customers can demand access to their data, correction of it, and erasure of it, and they will demand it from you, not your vendor. The DPA must obligate the vendor to assist you in honouring those requests within workable timelines, including locating and deleting personal data across their systems and backups.

7. Data Location and Cross-Border Restrictions

Section 16 of the Act permits cross-border transfer of personal data except to countries the Central Government restricts by notification. The restricted list approach gives you room to operate, but the government can notify restrictions at any time. Your DPA should record where your data is stored and processed, and give you exit or relocation rights if a jurisdiction becomes restricted.

8. Return and Deletion on Exit

When the contract ends, the data must come back to you and be deleted from the vendor's systems, including sub-processors, with written confirmation. A vendor that retains your customer data after termination is processing without a valid basis, and the liability for that lands on you.

9. Liability, Indemnity, and Insurance

Standard SaaS terms cap the vendor's liability at a few months of subscription fees. Against a Rs. 200 Crore notification failure, that cap is decorative. Negotiate carve-outs from the liability cap for data protection breaches and confidentiality violations, an indemnity for third-party claims arising from the vendor's failures, and evidence that the vendor carries cyber liability insurance.

10. Records and Cooperation With the Board

If the Data Protection Board opens an inquiry, you must be able to produce evidence of your vendor arrangements and the vendor's conduct. The DPA should require the vendor to maintain records of processing and to cooperate with regulatory inquiries, on your timelines rather than theirs.

The Tech Stack Audit: Finding Your Exposure Before the Board Does

Contracts fix the future. The audit fixes the present. Here is the sequence we walk clients through.

Step 1: Build the Vendor Inventory

List every tool that touches personal data. Pull from procurement records, corporate card statements, IT logs, and team leads. Do not forget the long tail: the free analytics plugin a developer added, the scheduling tool sales adopted, the survey platform marketing used once. Shadow IT is where audits fail.

Step 2: Map the Data

For each vendor, record what categories of personal data it processes, whose data it is, where the data is stored, and whether it leaves India. This map is the document you will reach for first in any breach or Board inquiry, and it is the foundation of every later decision.

Step 3: Review the Contracts

For each vendor on the map, pull the actual agreement in force and test it against the ten clauses above. Sort vendors into three buckets: covered with an adequate DPA, covered with an inadequate DPA, and no valid contract at all. That third bucket deserves attention first, because Section 8(2) makes processing without a valid contract a problem in itself.

Step 4: Verify Security Posture

Collect certifications, audit reports, and security documentation for the vendors that hold your highest volumes or most sensitive categories of data. A vendor with no certification, no audit report, and vague security language is telling you something. Believe it.

Step 5: Remediate by Risk

You cannot renegotiate forty contracts in a month, and you do not need to. Sequence the work by exposure: vendors holding the most personal data, the most sensitive categories, and the weakest contractual positions go first. For many businesses, the practical order is hosting and cloud, then CRM, then payment and payroll, then marketing and analytics, then everything else.

What This Means for You: An audit is not a one-time project. Vendors update their terms, add sub-processors, and ship new features that change what data flows where. Build a lightweight annual review into your compliance calendar, and treat any new tool adoption as a trigger for a mini-audit before the contract is signed, not after.

What You Can Do Internally, and Where Counsel Earns Its Fee

The Bottom Line

The DPDP Act did something quietly radical: it made you answerable for companies you do not control, and then handed you exactly one tool to control them. The contract.

The businesses that come out of this transition well will not be the ones with the fewest vendors. They will be the ones that know their stack, mapped their data, and converted their vendor relationships into enforceable obligations before the May 13, 2027 enforcement date arrives. The ones that struggle will be the ones still pointing at a vendor's terms of service when the Data Protection Board asks why the notification came late.

If your tech stack has grown faster than your contracts, that gap is fixable, and it is cheaper to fix now than after an incident. Reach out to our Corporate Advisory team to review your vendor agreements and build a DPA framework that matches how your business actually runs.

For the foundation piece in this series, read our earlier article on what Indian websites get wrong about DPDP compliance.