The DPDP Act for Indian SaaS: what you actually have to do

Most Indian SaaS founders meet the Digital Personal Data Protection Act the way they meet everything else in compliance: a customer's legal team asks a question they cannot answer. That is the wrong order, because unlike SOC 2 this one is not optional and not customer-driven. It is law, and it applies because of where your users are.

Who it applies to

The Act governs the processing of digital personal data where that data relates to people in India. If you have Indian users, or you process Indian personal data on behalf of a customer, you are in scope — including when your company is incorporated elsewhere and your servers are not in India.

For a B2B SaaS company the important nuance is which hat you are wearing. When you decide why and how personal data gets processed — your own signups, your marketing list, your employees — you are a Data Fiduciary and the full set of duties is yours. When you process your customer's data on their instructions, you are a Data Processor and most of the obligations sit with them, flowing to you through the contract. Enterprise buyers will ask you to confirm which one you are for their data. The answer is almost always processor, and saying so clearly is a good answer.

The duties that actually change your product

• Notice and consent — you must tell people what you are collecting and why, in clear language, and consent has to be a real affirmative act. Pre-ticked boxes and bundled consent do not survive this.
• Purpose limitation — data collected for one stated purpose cannot quietly become training data, a marketing list, or an analytics feed.
• Data principal rights — people can ask what you hold, have it corrected, and have it erased. Whatever your architecture, someone has to be able to answer those requests within a reasonable time, which means knowing where personal data actually lives.
• Erasure on withdrawal — when consent is withdrawn or the purpose is served, the data goes. This is the duty that most often collides with a system designed to never delete anything.
• Reasonable security safeguards — the Act obliges you to protect the data, and this is where the heaviest consequences sit. It does not enumerate controls, which in practice means you are measured against what a competent organisation your size would do.
• Breach notification — you notify the Data Protection Board and affected people. Note this is a separate duty from CERT-In's incident reporting, with a different recipient and a different trigger; satisfying one does not satisfy the other.

What an enterprise buyer does with it

A US or European buyer will not audit your DPDP compliance. They will do two things. First, they will map it onto their own frame — DPDP is the closest Indian analogue to the GDPR framing most vendor questionnaires are built around, so citing it is the right answer to a row asking about your privacy regime. Second, they will look for the contractual plumbing: a data-processing agreement, a named list of subprocessors, a documented breach-notification commitment, and a statement of where data is stored.

That last point causes more stalls than the law itself. Indian vendors frequently cannot answer "where does our data live and who else touches it" without a week of internal archaeology. Building the subprocessor list before someone asks is a few hours of work that pays for itself the first time.

The overlap with the work you are already doing

The reasonable-security-safeguards duty is not a separate project. Encryption in transit and at rest, access control with MFA, patching known vulnerabilities, logging, and an incident response plan are the same controls SOC 2 and ISO 27001 ask for, and the same ones sitting in your customer's questionnaire. Done once, they answer all three.

What DPDP adds on top is mostly about knowing your data rather than defending it: what personal data you hold, why, where, who you share it with, and how someone gets it deleted. That inventory is the genuinely new work, and it is worth doing deliberately rather than reconstructing it under deadline.

None of this is a reason to panic, and none of it is a reason to buy anything. It is a reason to write down what you process and to close the security gaps you already know about, before a regulator or a buyer asks you to do it on their schedule.