DPDP Compliance for SaaS Companies and Startups in India

Most B2B SaaS founders assume DPDP is "an enterprise problem" their customers will worry about. That is half right. Under India's Digital Personal Data Protection Act, 2023 you almost certainly wear two hats at once — and the obligations are different for each. Getting the distinction right is the whole game.

You are both a Processor and a Fiduciary

The Act defines a Data Fiduciary as the entity that determines the purpose and means of processing, and a Data Processor as one that processes personal data on behalf of a fiduciary under contract.

For a typical SaaS company:

• For your customers' data (the records your customers upload and control), you are usually a Data Processor. Your customer is the Fiduciary; you act on their instructions.
• For your own users' data (your signups, your marketing list, your employees), you are a Data Fiduciary. You decide why and how that data is processed.

What to do: Write down, system by system, which hat you wear. Your product database is processor data; your CRM, marketing tool, and HR system are fiduciary data. The two attract different duties and you cannot manage them with one policy.

As a Processor: contracts are the core obligation

The Act allows a Fiduciary to engage a Processor only under a valid contract (§8(2)). That contract — a Data Processing Agreement (DPA) — is what makes your processing lawful. Your enterprise customers will demand one; you should have a standard DPA ready before they ask.

A workable DPA covers: the scope and purpose of processing, security obligations, breach-notification duties back to the Fiduciary, sub-processor terms, assistance with Data Principal rights, and deletion or return of data at the end of the engagement.

What to do: Publish a standard DPA and a current sub-processor list. Make signing it a self-serve step in your enterprise onboarding, not a bespoke legal negotiation every time.

Sub-processors: your vendors are your liability

The cloud host, the email API, the analytics tool, the support desk — every vendor that touches customer personal data is a sub-processor. Under the contractual chain, you remain answerable to your customer for what they do.

What to do: Maintain a living sub-processor register. Flow your DPA obligations down to each one in writing, and give customers advance notice before you add a new sub-processor that touches their data.

Consent for product analytics

This is where SaaS teams trip. Product analytics, session replay, and behavioural event tracking process personal data. When you do this on your own users (fiduciary data), you need a lawful basis — typically consent that is free, specific, and informed (§6). When you do it inside a customer's tenant, you are processing their data principals' data, and your customer (the Fiduciary) owns the basis — you must not repurpose it for your own analytics without their instruction.

What to do: Separate first-party product analytics on your own marketing site and signup flow (where you need consent — see DPDP cookie consent) from in-product telemetry on customer tenants (which your DPA must explicitly permit and bound).

When a startup becomes a Fiduciary's headache

Your customers will increasingly push obligations onto you because they are accountable. Expect requests to:

• Sign a DPA and keep a sub-processor list current
• Support their Data Principals' rights — help them fulfil access (§11), correction and erasure (§12) requests against data in your system
• Notify them of breaches fast enough that they can meet their own Board-reporting window (see breach reporting)
• Delete or export tenant data on offboarding

What to do: Build rights-assist and data-export endpoints into the product. A self-serve "export / delete this data subject" feature turns a painful manual SLA into a button — and becomes a sales advantage.

Retention is not "keep everything forever"

The Act requires erasure once the purpose is served or consent is withdrawn (§8(7)). For large consumer-facing platforms, the Rules go further: the Third Schedule sets a three-year retention limit (from last contact) for specified e-commerce, online-gaming, and social-media platforms above defined user thresholds, with a 48-hour pre-erasure notice (Rule 8). Most early-stage B2B SaaS will sit below those thresholds, but the general erasure duty still applies.

What to do: Define a retention period per data category and automate deletion. "We keep it indefinitely" is not a defensible position under DPDP.

A startup-sized compliance starting point

• Appoint and publish a contact for data questions and grievances (§8(9); Rule 9). See the Grievance Officer guide.
• Stand up a DPA + sub-processor list — table stakes for enterprise deals.
• Get consent right on your own funnel; respect customer instructions inside their tenant.
• Wire up rights and breach workflows before a customer audit forces it.
• Assess SDF risk — most startups are not SDFs, but high-volume consumer products can be designated (§10).

The timing is on your side. Substantive obligations commence 13 May 2027 (see the compliance timeline) — enough runway to build this in properly rather than bolt it on.

What enterprise procurement will ask you for

Once you start selling to larger Indian customers, DPDP turns into a procurement checklist you must satisfy to close deals. Expect security and privacy reviewers to ask for:

• A signed Data Processing Agreement and a current sub-processor list
• A documented breach-notification SLA back to the customer, tight enough for their 72-hour Board window
• Data-residency options — where their data is stored, and whether you can keep it in India
• Rights-assist capabilities — how you help them fulfil access, correction, and erasure for their users
• Deletion or export on offboarding, with evidence it actually happened
• Your security safeguards mapped to the Rule 6 expectations

What to do: Assemble these into a short trust pack — DPA, sub-processor list, security overview, and a one-page DPDP posture. Having it ready turns a multi-week security review into a quick attachment, and signals maturity to buyers who are themselves under DPDP pressure.

Frequently asked questions

Are we a Data Fiduciary or a Data Processor?

Almost always both. You are a Processor for the data your customers upload and control, and a Fiduciary for your own signups, marketing list, and employees. The duties differ, so classify each system before writing one blanket policy.

Do we need a DPA with every vendor?

Yes, for any sub-processor that touches personal data. The Act permits engaging a processor only under a valid contract (§8(2)), and your enterprise customers will require you to flow those terms down to your own vendors.

Can we use customer data to train our models or improve the product?

Only if your DPA with the customer permits it and they instruct or consent to that purpose. Tenant data belongs, in effect, to the Fiduciary; silently repurposing it for your own analytics or model training is not lawful processing.

Are early-stage startups exempt because we are small?

No. There is no size-based exemption from the baseline obligations. SDF designation turns on volume and risk, not headcount — most startups are not SDFs, but every Fiduciary owes notice, consent, rights, and breach duties.

How Sammati helps SaaS teams

Sammati is a consent management platform (CMP) and Data Processor — not a registered Consent Manager — that drops into a SaaS stack:

• Consent capture for your own funnel, plus an embeddable consent layer your customers can use inside their tenants
• Immutable, hash-chained consent records and an audit-ready export for customer due-diligence reviews
• Rights-request workflows (access, correction, erasure, grievance) with the 90-day grievance ceiling (Rule 14(3)) built in
• BYOC / in-VPC deployment so customer data never leaves your environment

Take the free DPDP assessment or talk to us about your SaaS architecture.