DPDP for SaaS: When Processor Becomes Fiduciary (2026)

DPDP for SaaS: The Moment You Train a Model on Customer Data, You Stop Being a Processor

By Yatin Chaudhary, SEO Specialist at ProtectComply · Reviewed by Dinkar Singh, Chief Data Privacy Officer & Co-Founder · Last updated 13 August 2026 · 13 min read

Quick answer

Every DPDP guide for SaaS tells you the same thing: you're a Data Fiduciary for your own data — signups, billing, your employees — and a Data Processor for the data your customers put into your product.

That's right, and it's the easy half.

The problem is that the role isn't stable. It changes based on what you do with the data, not on whose account it sits in. And three things almost every Indian SaaS company now does silently convert them from Processor to Fiduciary for data they believe they're merely hosting:

1. Training or fine-tuning models on customer data — including to improve your own product
2. Cross-tenant benchmarking — "you're in the top 20% of teams using this feature"
3. Product analytics on customer-uploaded content, as opposed to on usage telemetry

In each case you are determining the purpose. That is the Fiduciary test. And your standard DPA almost certainly doesn't cover it.

The second problem nobody writes about: executing an erasure request across a multi-tenant architecture — production database, read replicas, backups, application logs, the analytics warehouse, and the vector store you built last quarter.

Below: both, plus the sub-processor problem that engineering creates faster than legal can document.

The role test is about purpose, not custody

Section 8(1) is the sentence that matters: a Data Fiduciary is responsible for complying with the Act for processing it undertakes or that is undertaken on its behalf by a Processor — irrespective of any agreement to the contrary.

You cannot contract your way out of the role you actually occupy. Which means the DPA doesn't determine your status; your behaviour does. The DPA documents it.

Processor: you hold and process customer data strictly on their instruction, for their stated purposes.

Fiduciary: you decide what the data is used for.

Now apply that honestly.

Model training. You fine-tune a classification model on support tickets your customers' end-users wrote. Your customer instructed you to store and display those tickets. Did they instruct you to train on them? If the purpose is your product improvement, you determined it. You are the Fiduciary for that processing.

Benchmarking. You aggregate across tenants to show a customer how they compare to peers. Aggregation may anonymise the output, but the processing that produces it operates on identifiable data across accounts, for a purpose your customer did not set.

Product analytics on content. Telemetry on how someone uses your UI is arguably yours. Analysis of what they uploaded is a different thing.

The distinction that matters: processing to deliver the service the customer bought is processor activity. Processing to improve your product, build new features, or generate insights you sell is fiduciary activity — regardless of where the data sits.

What to do:

Audit every pipeline that reads customer-tenant data and ask what purpose it serves. For each, decide: is this delivering the contracted service, or is it ours?

Anything in the second bucket needs a lawful basis of its own, which for most of it means consent — and consent flowing from your customer's end-users, obtained through your customer, for a purpose you have to specify.

Then fix the DPA. A DPA that says you process "only on documented instructions" while your ML pipeline reads the same tables is a contract you're already breaching.

The erasure problem

This is the hardest engineering problem in SaaS privacy and the SERP is silent on it.

Your customer's end-user exercises the right to erasure. Your customer, as Fiduciary, instructs you to delete. Now find every copy.

Production database. Straightforward — unless the record is referenced by foreign keys across a multi-tenant schema.

Read replicas. Propagates automatically. Verify it does.

Backups. Here it breaks. Backups are immutable by design — that's the point of them. You cannot surgically delete one person's record from a 90-day snapshot chain without destroying the integrity of the backup.

The workable position: document that backups are held for a defined retention period, that deleted records are not restored to production if a backup is used, and that the backup itself expires on schedule. That's a defensible operational answer, but it needs to be written down before someone asks — not improvised during an inquiry.

Application logs. Personal data leaks into logs constantly — email addresses in error traces, names in request payloads, identifiers in debug output. Most SaaS companies have no idea what personal data their logs contain, and log retention is often set to "forever" because storage is cheap.

The analytics warehouse. Data flows from production into BigQuery, Snowflake or Redshift for reporting. Does your erasure workflow reach it? For most teams, no.

Vector stores and embeddings. The 2026 addition. If you've built retrieval-augmented search over customer content, that content now exists as embeddings. Deleting the source row does not delete the embedding. And embeddings are not reliably anonymous — text can often be reconstructed from them.

What to build:

A deletion pipeline that fans out to every store, with confirmation logged per store. Log scrubbing or aggressive log retention limits. A documented backup position. And for embeddings, a re-indexing process rather than a hope.

Then record the whole thing. When a customer's compliance team asks how you handle erasure — and enterprise buyers now do — a documented multi-store deletion workflow is a sales asset, not just a compliance one.

Sub-processor sprawl

Every third-party service that touches customer personal data is a sub-processor: cloud hosting, email delivery, error monitoring, analytics, support tooling, payment processing, and now every AI API you call.

Two obligations follow. You must disclose them, and you must flow your DPA obligations down to them.

The structural problem: engineering adds sub-processors faster than legal documents them. A developer wires in a new error-monitoring tool on a Tuesday afternoon. That tool now receives stack traces containing personal data. Nobody told legal, the public sub-processor list is now inaccurate, and the DPA commitment to notify customers before adding sub-processors has been silently broken.

The AI API version is worse. Calling a third-party LLM with customer content sends that content outside your infrastructure. Whether the provider trains on it, how long they retain it, and where it's processed are now your compliance problem — and your customer's.

What to build:

• A public sub-processor list at a stable URL, kept current
• Advance notice to customers before adding one, with the notice period in your DPA
• A CI check. Add a step that fails the build when a new outbound domain appears in dependencies or config without a corresponding sub-processor registry entry. This is the only control that actually keeps pace with engineering.

That last one is the difference between a policy and a control.

Multi-tenancy is a compliance boundary

Tenant isolation is normally framed as a security concern. Under DPDP it is also a compliance one.

A cross-tenant leak means Customer A's end-user data was disclosed to Customer B. Both customers are Fiduciaries for their own data principals. Both must notify. You caused it, and you're contractually exposed to both.

The obligations that follow:

Isolation must be demonstrable, not assumed. Row-level security, tenant-scoped queries, and tests that actually attempt cross-tenant access.

Internal access is a disclosure. Your support engineer viewing a customer's data is processing. Is it within your DPA scope? Is it logged? Can you produce the log?

Shared infrastructure needs documented boundaries — shared caches, shared search indices, shared job queues. Each is a potential leak path and each should appear in your processing register.

Breach notification runs through your customer

As a Processor, you generally do not notify the Board directly. You notify your customer — the Fiduciary — who notifies the Board and the affected individuals.

That sounds simpler. It is operationally harder.

Your customer's DPDP clock starts when they become aware. Your delay is their delay. The Board's requirement is intimation without delay on becoming aware, followed by detailed particulars within 72 hours. If you take 48 hours to tell your customer, you've consumed most of their window.

And CERT-In's six-hour reporting obligation for cyber incidents applies to you directly.

What your DPA should specify: a notification SLA to customers measured in hours, not "promptly." What information accompanies the notification. Who drafts the end-user communication. And who bears the cost if notification is required at scale.

The free-tier gap

Trial and freemium users sign up without a contract. There is no DPA, no customer instructing you.

For those users, you are the Fiduciary — full obligations, direct exposure. That includes abandoned trials sitting in your database years later, still holding personal data, with no retention rule and no purpose.

Audit your free tier separately. It's frequently the least governed data in the company.

What enterprise buyers now ask

The commercial deadline arrives before the statutory one. Indian enterprise procurement increasingly includes DPDP readiness questions, and the answers are becoming deal gates.

What you'll be asked for:

• A DPDP-aligned DPA template you can execute
• A current public sub-processor list
• Data residency: where Indian personal data physically sits
• Your erasure workflow, across all stores
• Breach notification SLA
• Security safeguards documentation
• Increasingly, SOC 2 or ISO 27001 alongside DPDP

Having these ready is a sales advantage now, not just a compliance position for May 2027.

The SaaS checklist

1. Audit every pipeline reading customer-tenant data. Classify each as service delivery or your own purpose.
2. Fix your DPA to reflect what you actually do — especially any AI or analytics processing.
3. Build the multi-store erasure pipeline, with per-store confirmation.
4. Document the backup position before someone asks.
5. Scrub logs, or cap log retention hard.
6. Publish a sub-processor list and add a CI check to keep it accurate.
7. Prove tenant isolation with tests, not architecture diagrams.
8. Set a breach notification SLA to customers in hours.
9. Govern the free tier — you're the Fiduciary there.
10. Build the buyer-questionnaire pack before the deals demand it.

Frequently asked questions

Is a SaaS company a Data Fiduciary or a Data Processor?

Both, and the split is by purpose rather than by dataset. You're a Fiduciary for data whose purpose you determine — your signups, billing, employees, marketing contacts, and any processing of customer data for your own purposes. You're a Processor for customer data you handle purely on their instructions.

Does training AI on customer data make us a Data Fiduciary?

If the purpose is your own product improvement rather than delivering the contracted service, yes — you're determining the purpose, which is the Fiduciary test. That processing needs its own lawful basis, and your standard DPA likely doesn't authorise it. Review both the pipeline and the contract.

How do we handle erasure requests across backups?

You generally can't surgically delete from immutable backups. The workable position is a documented, limited backup retention period, a commitment that deleted records aren't restored to production, and confirmation that backups expire on schedule. Document it before you're asked.

Do we need a DPA with every customer?

Yes, where you process personal data on their behalf. Section 8(2) permits engaging a processor only under a valid contract, which makes the DPA a legal requirement rather than a commercial formality.

Who notifies the Data Protection Board if we have a breach?

Generally your customer, as the Fiduciary. You notify them, and your delay eats their statutory window — so set a notification SLA in hours. CERT-In's six-hour cyber incident obligation applies to you directly and separately.

Are our free-tier users our responsibility?

Yes. No customer contract exists, so you're the Fiduciary with full obligations. Abandoned trial data is commonly the least governed personal data in a SaaS company.

Does SOC 2 or ISO 27001 cover DPDP?

No. Those cover security controls and help with the safeguards obligation. Neither addresses consent, Data Principal rights, grievance redressal or records of processing. They're complementary, not substitutes.

When is the deadline?

Full compliance by 13 May 2027, per the DPDP Rules timeline. Penalty provisions become operative 13 November 2026, with penalties reaching ₹250 crore for security safeguard failures, assessed per contravention.

Where to start

Map before you buy. A gap analysis scoped to SaaS tells you which pipelines have silently moved you into Fiduciary territory — which for most companies shipping AI features is more than they expect.

For the platform question, see our comparison of DPDP platforms in India and the selection guide.

ProtectComply runs discovery → RoPA → DPIA end to end, with each processing activity linked to its purpose, lawful basis and processor registry entry — which is what makes the Fiduciary-versus-Processor question answerable per pipeline rather than per contract.

Book a SaaS walkthrough

About this guide

About the authorYatin Chaudhary is an SEO Specialist at ProtectComply, where he writes about India's data protection framework and how organisations operationalise it.

Reviewed byDinkar Singh, Chief Data Privacy Officer & Co-Founder, ProtectComply.

Written against the DPDP Act, 2023 and the DPDP Rules, 2025 as notified, plus ProtectComply's own implementation experience with SaaS data estates.

Corrections: write to [corrections email] and we will review and update.

Sources

• The Digital Personal Data Protection Act, 2023 — Sections 2, 6, 8, and the penalty schedule
• Digital Personal Data Protection Rules, 2025 — gazette notification G.S.R. 846(E), 13 November 2025
• CERT-In directions on cyber incident reporting, 2022