Module 12 · DPDP for SaaS — Building DPDP-Compliant Indian SaaS

Last updated: April 29, 2026

Why this module exists. Indian SaaS companies are growing 30% YoY and most are scaling faster than their compliance posture. Founders wait until “we hit ₹10 crore ARR” or “we have to sell to a regulated customer” — by which time retrofitting DPDP costs 5x more than building it in. This module is the day-one playbook.

Are you a Data Fiduciary or a Data Processor?

The answer is usually: both, depending on the data.

• For data about your customers themselves (signup, billing, communication) — you are the Data Fiduciary.
• For data your customers ingest into your platform about their users — you are the Data Processor for that data; your customer is the Fiduciary.

This dual role drives a lot of architectural decisions.

Multi-tenancy and DPDP

Pure multi-tenancy (same database, tenant ID column) has DPDP implications:

• One customer’s DSR doesn’t trigger erasure of another customer’s data — but ensure your data model enforces this.
• Cross-tenant data leak via bug = breach for every affected tenant.
• Cross-tenant query for analytics can introduce statistical re-identification risks.

Defensible patterns:

• Strict tenant ID enforcement at every database query (RLS in Postgres; equivalent in others).
• Tenant-level encryption keys for sensitive data (per-customer KMS keys).
• Aggregate analytics with k-anonymity ≥ 5 across tenants.
• Customer-controlled data residency for high-stakes verticals.

The day-one architectural decisions

1. Data inventory column. Every table that holds personal data, tagged in your schema. Generate the inventory automatically from migrations.
2. Person ID. Stable UUID for every data principal across systems.
3. Consent table. Every consent recorded — purpose, timestamp, version of policy, withdrawal flag.
4. Audit log. Every read/write to personal data attributed to a user + purpose.
5. Region-aware data store. Indian customers’ primary data in Indian region. Application logic enforces.
6. DSR API. One endpoint per system that handles access/erasure for a Person ID.
7. Soft-delete + scheduled hard-delete. Erasure pipeline runs daily.
8. Backup encryption + access control. Backups can’t be casually browsed.

Consent UX patterns

Bad: blanket “Accept all cookies” with a 4000-word privacy policy linked.

Good (per-purpose):

• Sign-up — necessary processing only. Clear, brief disclosure.
• Marketing emails — separate opt-in checkbox at signup; default unchecked.
• Behavioural analytics — opt-in granular toggles; default off where DPDP requires (children) or where business model allows.
• Third-party marketing — explicit, separate consent.
• Sensitive categories — explicit consent with prominent context.

Withdrawal: as easy as consent. One click in account settings.

The SaaS DPA — what your enterprise customers will demand

By 2026, every Indian enterprise customer asks for a DPA before signing. Your DPA template needs:

1. You as Data Processor for customer-uploaded data (their data principals).
2. Documented sub-processor list (your AWS region, your email provider, your support tools).
3. Sub-processor change notification (30 days, opt-out).
4. Breach notification within 24-72 hours.
5. Audit rights via SOC 2 Type II / ISO 27001 (don’t accept on-site audits at scale).
6. Data return/deletion at termination within 30-60 days.
7. Indian jurisdiction or alternative arbitration in India.
8. DSR cooperation — if your customer’s user requests DSR via you, you forward; if via your customer, you respond.
9. Cross-border transfer notice if applicable.
10. Indemnification for your processor failures.

SaaS-specific DPDP risks

• Onboarding form fields — collecting PAN, Aadhaar, phone for “we might need it later” = unnecessary processing per §8(7).
• Access logs — your engineers reading customer data for “support” without per-incident authorisation = unauthorised processing.
• Long retention — keeping every email customers send “for analytics” = unnecessary.
• Marketing emails to former customers — consent expires when relationship ends.
• Public-facing case studies — using customer data without explicit consent.

Trust signals customers expect

• Public privacy policy, current
• Public security page (how you protect data)
• SOC 2 Type II report (annual)
• ISO 27001:2022 certification (where industry expects it)
• DPDP-aligned DPA, easily downloadable
• Status page with security incident history
• Bug bounty programme (or vulnerability-disclosure policy)
• SOC 2 / ISO scope clarity — what’s in scope, what’s not

Defender’s checklist

• Day-1 architecture — Person ID, consent table, audit log, regional data residency.
• Privacy + security pages live before first customer.
• Standard DPA available for download.
• Sub-processor list public.
• SOC 2 Type II within 18 months of first paying customer.
• ISO 27001:2022 within 24 months for B2B SaaS, 36 months otherwise.
• DPDP DPA template aligned with §8(7) requirements.
• Annual DPIA for the core product processing.
• RingSafe Trust (or equivalent) for vendor risk management on your side.