Answer in one line: SaaS companies under India's Digital Personal Data Protection Act, 2023 must map every personal-data stream (accounts, marketing, support, HR, and customer tenant data), choose a lawful basis per purpose, store consent with version history, and cascade withdrawals across CRM, ESP, ads, warehouses, and SDKs — while remaining accountable for processors under Section 8.

This guide is for product, growth, security, and legal leads at Indian SaaS startups and scale-ups. It expands the SaaS industry map from the Complynz DPDP Handbook.

Why SaaS is different under DPDP

Most product companies wear two hats:

  • Data Fiduciary for their own end users, leads, employees, and support tickets.
  • Data Processor for customer tenant data inside the product — still accountable via contracts, but the customer sets purpose.

Mixing those hats without a data-flow map is the fastest path to consent theatre: banners that never reach the warehouse, or DPAs that ignore analytics SDKs.

Figure 1 — SaaS data streams and dual hats

Use this map in your RoPA / processing inventory. Every box needs a purpose, basis, system owner, and retention class.

Figure 1. SaaS / product company — fiduciary vs processor streams under DPDP
flowchart TD
  HUB([SaaS / product company]) --> OWN[Fiduciary hat]
  HUB --> PROC[Processor hat]
  OWN --> U1[End-user accounts]
  OWN --> U2[Marketing / analytics]
  OWN --> U3[Support tickets]
  OWN --> U4[Employee / HR systems]
  PROC --> C1[Customer tenant data in product]
  U1 --> N[Sec 5 notice + per-purpose Sec 6]
  U2 --> N
  U3 --> N
  U4 --> N
  C1 --> DPA[Back-to-back DPA with customer]
  N --> SDK{SDKs / pixels / sub-processors?}
  SDK -->|Yes| MAP[DPA + data-flow map + breach SLA]
  SDK -->|No| VAULT[(Consent vault + version log)]
  MAP --> VAULT
  DPA --> VAULT
  VAULT --> SYS[CRM / ESP / ads / warehouse / product]
  SYS --> W{Withdrawal or DSR?}
  W -->|Yes| CAS([Cascade off every system + SDK])
  W -->|No| SYS
  class HUB,OWN,PROC,U1,U2,U3,U4,C1,N,MAP,DPA,SYS act;
  class SDK,W dec;
  class VAULT start;
  class CAS ok;
  classDef start fill:#DBEAFE,stroke:#2563eb,color:#0f172a;
  classDef act fill:#EFF6FF,stroke:#3B82F6,color:#1e3a8a;
  classDef dec fill:#FEF3C7,stroke:#D97706,color:#78350f;
  classDef ok fill:#D1FAE5,stroke:#059669,color:#064e3b;
  classDef stop fill:#FEE2E2,stroke:#DC2626,color:#7f1d1d;
  classDef note fill:#F1F5F9,stroke:#64748B,color:#334155;

What to put in the consent vault

  • Section 5 notice text version + language
  • Section 6 purpose codes (product, marketing, analytics — not one bundled toggle)
  • Timestamp, channel, and identity key
  • Withdrawal events and cascade acknowledgements from each system

Wire the vault to CRM, ESP, ads platforms, product feature flags, and the warehouse — not only the website CMP. See Complynz consent management.

Figure 2 — Consent capture and withdrawal cascade

Figure 2. SaaS consent end-to-end — notice, vault, systems, cascade
flowchart TD
  A([Product or marketing touchpoint]) --> B[Sec 5 notice - plain language]
  B --> C[Sec 6 granular consent per purpose]
  C --> D[(Consent vault + version log)]
  D --> E[Wire CRM / ESP / ads / product / warehouse]
  E --> F{Withdrawal or DSR?}
  F -->|Yes| G([Cascade off every system + SDK])
  F -->|No| E
  class A,B,C,E act;
  class D start;
  class F dec;
  class G ok;
  classDef start fill:#DBEAFE,stroke:#2563eb,color:#0f172a;
  classDef act fill:#EFF6FF,stroke:#3B82F6,color:#1e3a8a;
  classDef dec fill:#FEF3C7,stroke:#D97706,color:#78350f;
  classDef ok fill:#D1FAE5,stroke:#059669,color:#064e3b;
  classDef stop fill:#FEE2E2,stroke:#DC2626,color:#7f1d1d;
  classDef note fill:#F1F5F9,stroke:#64748B,color:#334155;

90-day SaaS action checklist

  1. Inventory product tenants vs first-party users vs employees.
  2. List every SDK, pixel, and sub-processor; attach DPAs and breach SLAs.
  3. Ship plain-language notices and purpose-level consent.
  4. Test one withdrawal end-to-end across marketing and product.
  5. Publish a DSR / grievance path with a realistic SLA.
  6. Run PII discovery on stores and logs you forgot about.

FAQ

Does DPDP apply if our SaaS customers are companies, not consumers?

Yes when you process digital personal data of individuals in India — including employee users of a B2B product, support contacts, and your own leads. Customer contracts do not replace your fiduciary duties for first-party data.

Are we a Significant Data Fiduciary as a startup?

SDF status depends on government notification criteria (volume, sensitivity, risk). Even without SDF designation, Sections 5–8 and rights duties still apply. Prepare DPO-ready evidence early if you handle health, finance, or children's data.

What is the practical compliance deadline?

Treat 13 May 2027 as the operating horizon for full Rules readiness while building controls now — buyers and investors already ask for evidence.

Where should SaaS teams start this week?

Download the DPDP Handbook, run a consent cascade test, and book a gap assessment if the map has more than three unknown vendors.

Related reading

Informational only — not legal advice. Deadline context: organisations should treat 13 May 2027 as the practical compliance horizon under the notified Rules timeline.