DPDP compliance for SaaS platforms

Why SaaS Has a Unique DPDP Problem

If you build SaaS, you sit in an unusual position under the DPDP Act. You are simultaneously a Data Fiduciary (for your own users - their account data, usage data, billing data) and a Data Processor (for your customers' end-users whose data flows through your platform). This dual role creates compliance obligations in both directions, and most SaaS companies handle neither.

The second problem is multi-tenancy. Your platform serves hundreds or thousands of customers, each with their own users. When a Data Principal rights request arrives - "delete my data" - you need to know: whose tenant is this user in? What data do we hold about them in our systems versus what data our customer (the tenant) holds? Who is responsible for responding - us or our customer?

The third problem is your sub-processor stack. A typical B2B SaaS platform uses AWS or GCP for hosting, Stripe or Razorpay for billing, SendGrid or SES for transactional email, Mixpanel or Amplitude for analytics, Intercom or Freshdesk for support, and Snowflake or BigQuery for data warehousing. Every one of those is a sub-processor, and under DPDP, your customers (who are Data Fiduciaries) need to know about every single one.

The 6 DPDP Obligations SaaS Companies Must Get Right

Obligation 1: The Dual-Role Architecture

You need to separate your compliance posture into two tracks:

Track A - You as Data Fiduciary: For your direct users (the people who sign up, log in, pay you), you bear full DPDP responsibility. You need a privacy notice, consent mechanisms, a data principal rights portal, breach notification capability, and data retention policies. This is identical to any other company's obligations.

Track B - You as Data Processor: For your customers' end-users (the data that flows through your platform because your customers use it to serve their users), you are a Data Processor acting on your customer's instructions. Your obligations here are defined by your DPA with each customer, not directly by the Act - but the Act requires your customers to ensure you are compliant.

Practically, this means you need two sets of documentation: a customer-facing privacy notice and consent flow for Track A, and a customer-facing DPA and sub-processor disclosure for Track B.

Obligation 2: Data Processing Agreement (Your Side)

Every SaaS company needs a standard DPA that enterprise customers can review, redline, and sign. This is no longer optional - it is a procurement gate for any Indian enterprise customer subject to DPDP.

Your DPA must address: - Scope of processing: what personal data you process, for what purposes, on whose instructions - Security safeguards: encryption, access controls, logging, incident response - with specifics, not vague "reasonable measures" - Sub-processor disclosure: a complete list of every sub-processor, what they do, where they process data, and the customer's right to object to new sub-processors - Breach notification: your commitment to notify the customer within 24 hours of detecting a breach affecting their data (they need this to meet their 72-hour DPBI obligation) - Data deletion: your process for deleting a customer's data upon contract termination, including timelines and certification - Data principal rights cooperation: how you will assist the customer in responding to access, correction, and erasure requests from their users - Audit rights: the customer's right to audit your compliance, directly or through an independent auditor - Cross-border transfers: where data is stored and processed, and confirmation that destinations are on the permitted list

If you do not have a DPDP-specific DPA today, you are losing enterprise deals. Build one now.

Obligation 3: Sub-Processor Register and Notification

Under DPDP, your customers (Data Fiduciaries) are accountable for how you and your sub-processors handle their users' data. They need to know every sub-processor in your chain.

What you need: - A public sub-processor list on your website (standard practice - see how Stripe, Twilio, and HubSpot do this) - A notification mechanism when you add or change a sub-processor (email to all customers with DPAs, with a 30-day objection window) - Contractual flow-down: every sub-processor agreement must include DPDP-equivalent protections

Template sub-processor register:

Sub-processor | Service provided | Data processed | Location of processing | DPA in place AWS (Amazon Web Services) | Cloud hosting | All tenant data | Mumbai (ap-south-1) region | Yes Stripe | Payment processing | Billing name, email, payment details | US + India | Yes SendGrid | Transactional email | Email addresses, email content | US | Yes Mixpanel | Product analytics | User IDs, event data, device metadata | US | Yes Intercom | Customer support | Name, email, support conversations | US + EU | Yes

Obligation 4: Multi-Tenant Data Principal Rights

When a data principal rights request arrives, you need a clear decision tree:

Step 1: Is this person our direct user (Track A) or our customer's end-user (Track B)?

If Track A (our direct user): - We are the Data Fiduciary. We process the request directly. - Access: provide all personal data we hold about them. - Erasure: delete from all systems within 7 days.

If Track B (customer's end-user): - Our customer is the Data Fiduciary. They should be processing this request. - If the request comes to us directly: redirect the requestor to our customer (the tenant admin), and notify the tenant admin that a request has been received. - If the request comes from our customer (tenant admin): process it within the SLA defined in our DPA. - Provide tools in your admin dashboard for tenant admins to export and delete their users' data self-service.

What your platform needs: - A tenant admin data export function (CSV/JSON export of all personal data for a specific user) - A tenant admin data deletion function (hard delete a user's data across all platform systems) - Audit logging of all data export and deletion actions - A public-facing DSR form for Track A requests - Documentation for tenant admins explaining their responsibilities and your cooperation process

Obligation 5: Cross-Border Transfer Documentation

If your SaaS is hosted on AWS Mumbai but uses Mixpanel (US), SendGrid (US), and Stripe (US + India), you are transferring personal data outside India. Under Section 16 and Rule 15, this is permitted only to countries or territories on the government's approved list.

What you need: - A data flow map showing where personal data moves across borders - Confirmation that every destination country is on the permitted list (the government has not yet published the restricted list - but plan for it) - Contractual safeguards with every sub-processor that processes data outside India - Disclosure in your privacy notice and DPA about cross-border transfers - The ability to offer India-only data residency if a customer requires it (this is becoming a procurement requirement for government and BFSI customers)

Obligation 6: Security Evidence and Logging

Section 8(4) requires "reasonable security safeguards." For a SaaS company, this means your security posture must be demonstrable, not just claimed. Enterprise customers and the DPBI will ask for evidence.

What "reasonable" looks like for SaaS: - Encryption at rest (AES-256 or equivalent) and in transit (TLS 1.2+) - Role-based access control with principle of least privilege - Multi-factor authentication for admin access - Audit logging of all data access, modification, and deletion events - Regular vulnerability assessments and penetration testing - Incident detection and response capability - SOC 2 Type II or ISO 27001 certification (not legally required, but increasingly expected by enterprise buyers and useful as evidence of "reasonable safeguards")

Log retention: maintain data access logs for at least 1 year. These logs are your evidence if the DPBI investigates.

The SaaS DPDP Budget

For a B2B SaaS company with 10–100 employees:

One-time setup: ₹8–25 lakh - DPA drafting (legal counsel): ₹2–5 lakh - Privacy notice and consent flow implementation: ₹1–3 lakh - Data principal rights tooling (admin export/delete, DSR form): ₹2–5 lakh (engineering time) - Sub-processor audit and DPA negotiation: ₹1–3 lakh - Data mapping and flow documentation: ₹1–3 lakh - Compliance platform: ₹2–5 lakh/year

Recurring annual: ₹5–15 lakh - Platform subscription - Annual security audit / pen test - DPA maintenance and sub-processor updates - SOC 2 / ISO 27001 maintenance (if applicable)

The real cost driver: Engineering time. Building tenant admin data export, deletion, and audit logging into your platform is a 2–4 sprint investment. But it is also a product feature - enterprise customers will pay more for a platform that makes their own compliance easier.

The 12-Week SaaS DPDP Sprint

Week 1–2: Audit. Map all personal data flows (Track A and Track B). List all sub-processors. Document current security posture.

Week 3–4: Legal. Draft or update your DPA. Draft your privacy notice. Get legal review.

Week 5–6: Sub-processors. Send DPA requests to all sub-processors. Build your public sub-processor register. Set up notification mechanism for changes.

Week 7–8: Engineering Sprint 1. Build tenant admin data export function. Build tenant admin data deletion function. Add audit logging for data access and deletion events.

Week 9–10: Engineering Sprint 2. Build or deploy DSR intake form for direct users. Implement consent mechanism for direct user data. Test deletion pipeline end to end.

Week 11–12: Validate. Run ComplyDP Readiness Scan. Address gaps. Conduct breach tabletop exercise. Publish updated DPA and sub-processor list.

SaaS-Specific FAQ

Q: Our customer is the Data Fiduciary, not us. So we don't need to worry about DPDP? A: Wrong. You are a Data Processor, and the Act requires Data Fiduciaries to ensure their processors comply. If you cannot demonstrate compliance, you will fail enterprise procurement. You also have direct obligations for your own users' data (Track A).

Q: We already have a GDPR DPA. Is that enough? A: No. GDPR DPAs reference different legal bases (legitimate interests, which DPDP does not have), different timelines (30 days for erasure vs 7), and different regulators. You need a DPDP-specific DPA or a combined DPA that addresses both.

Q: Do we need to offer India data residency? A: Not yet required by law for most companies, but increasingly required by Indian enterprise and government customers in procurement. If you host on AWS, offering ap-south-1 (Mumbai) as the default region for Indian customers is low-cost and high-signal.

Q: We use AI/ML on customer data for product features. What does DPDP require? A: If you use personal data for AI/ML (recommendations, predictions, automated decisions), you must disclose this in your privacy notice and DPA, and ensure your customers have consented to this specific use. If you are designated an SDF, you may face algorithmic accountability and transparency requirements.

Getting Started

Run ComplyDP's free Readiness Scan at complydp.com/scan to see where your SaaS platform stands. It covers all 43 DPDP controls including processor obligations, sub-processor risk, and cross-border transfers.