India’s DPDP Act: The 2026 Compliance Guide for SaaS Founders

India’s Digital Personal Data Protection (DPDP) Act is now operational, with a clock on it. The DPDP Rules, 2025 were notified in November 2025, and enforcement ramps toward full accountability by 2027. If your SaaS touches the personal data of anyone in India — wherever your company is based — this applies to you. This guide walks through what the law requires, the specifics that trip founders up, and a practical path to compliance.

This is general information for founders, not legal advice. Confirm your specific obligations with a qualified data-protection lawyer, and note the framework is still rolling out.

What is the DPDP Act?

The Digital Personal Data Protection Act, 2023 is India’s comprehensive data-privacy law — in spirit, the country’s answer to the EU’s GDPR. It governs how organisations collect, use, store and share the personal data of individuals in India, who the Act calls data principals. The operational detail lives in the DPDP Rules, 2025, notified on 13 November 2025, which spell out how consent, notices, breach reporting, retention and enforcement actually work.

Who it applies to

The Act applies to any business that processes the personal data of people in India in connection with offering goods or services there — including companies based outside India. In practice, almost every SaaS with Indian users or customers is in scope, regardless of size. There is no blanket small-startup exemption on the core obligations; the heavier duties are reserved for larger, higher-risk players.

Are you a Data Fiduciary or a Data Processor?

This distinction decides which obligations land on you, and SaaS companies are often both.

A Data Fiduciary is “any person who, alone or with others, determines the purpose and means of processing personal data” — the GDPR equivalent of a controller. For the accounts, emails and usage data of your own users, you are the Data Fiduciary, and the primary obligations are yours.

A Data Processor processes data “on behalf of and under the instructions of a Data Fiduciary.” When your B2B customers upload their users’ data into your platform, they are the Fiduciary and you are the Processor. You are then bound by your contract with them, which under the Rules must require equivalent safeguards. Map both roles across your product — they carry different duties.

The enforcement timeline

The Rules roll out in phases. The dates to plan around:

The takeaway: 2026 is the build-and-test year; 2027 is when it bites. Founders who use 2026 to get consent, notices and data handling right will not be caught out.

Consent and notice, done right

Consent is the backbone of the Act. Before you process personal data, you must obtain consent that is “free, specific, informed, unconditional and unambiguous, given by clear affirmative action” — and, explicitly, pre-ticked boxes are not valid. Consent must be as easy to withdraw as it was to give, and withdrawal must stop the associated processing.

Alongside consent you must give a notice (Rule 3) in clear, plain language, before collection, stating what personal data you will process, the purpose, and how users can exercise their rights and withdraw consent. Notices must be available in English or any of the 22 languages in the Eighth Schedule of the Constitution on request. The Rules also introduce Consent Managers — entities registered with the Data Protection Board that act as a single point of contact for users to give, manage and withdraw consent across multiple businesses. You do not have to be one, but you may need to interoperate with them.

The rights your users get — and how to honour them

Data principals have real, enforceable rights, and your product has to actually deliver them, not just promise them in a policy:

• Access — a summary of the personal data you hold and how you process it.
• Correction and completion — fix inaccurate or incomplete data.
• Erasure — delete their data; erasure requests must be actioned within 90 days (Rule 14).
• Grievance redressal — a readily available way to complain, with defined response times.
• Nomination — nominate someone to exercise their rights in the event of death or incapacity.

Practically, that means building account settings where users can view, correct, export and delete their data, backed by a reachable grievance officer whose contact details you publish.

When you don’t need consent: “legitimate uses”

Consent is not the only lawful basis. Section 7 allows processing for certain legitimate uses without separate consent — including employment purposes, responding to medical emergencies, public-health measures, compliance with legal obligations or court orders, and specified state functions. For a typical SaaS, most customer-facing processing still needs consent, but knowing the legitimate-use carve-outs helps you avoid asking for consent you do not need (for example, for basic employee-data handling).

Data retention and erasure

The Act is built on data minimisation: keep personal data only as long as the purpose requires, then delete it. You must erase personal data “as soon as the purpose for which it was collected is no longer being served” — on consent withdrawal, once the purpose is met, or after a period of user inactivity. The Rules add sector-specific retention for large platforms (for example, three years from last activity for big e-commerce, gaming and social-media services), and require access and activity logs to be kept for at least one year. Automated retention and deletion workflows are the only sane way to meet this at scale.

Cross-border data transfers

Good news for most SaaS: the DPDP Act takes a negative-list approach to cross-border transfers under Section 16 — data may flow to other countries except those the government specifically restricts. That restricted list has not yet been published, so transfers remain broadly permitted for now, which is far more permissive than laws mandating local storage. The prudent move is to map your cross-border data flows now (which sub-processors and regions hold Indian users’ data) so you can react quickly if and when restrictions appear.

Breach notification

You need to be able to detect a personal-data breach and respond fast. Under the Rules you must notify the Data Protection Board immediately on becoming aware of a breach — with a description, the categories and rough number of users affected, likely consequences, and remedial steps — and notify each affected user within 72 hours, telling them what happened, what data was exposed, what protective measures they can take, and how to reach you. Failure to notify can attract penalties of up to ₹200 crore, so logging, detection and a written incident-response plan are not optional.

Children’s data

If under-18s can sign up, the bar is higher. Processing a child’s data requires verifiable parental consent — the Rules point to methods such as verifying the parent’s identity and relationship via DigiLocker — and the Act prohibits tracking, behavioural monitoring, profiling, and targeted advertising directed at children. You must implement technical measures to detect and prevent processing without verified parental consent. Penalties here also reach up to ₹200 crore, so if minors are in your audience, age assurance is a first-class feature, not an afterthought.

Significant Data Fiduciaries

The government can designate higher-risk businesses as Significant Data Fiduciaries based on six factors under Section 10 — the volume and sensitivity of data, risk to users’ rights, and risks to India’s sovereignty, electoral democracy, security and public order. SDFs carry extra duties: a resident Data Protection Officer, an independent data auditor, and annual Data Protection Impact Assessments and algorithmic audits. Specific designations have not been published yet, and most early-stage startups are not SDFs — but sensitive data (health, finance) or a very large user base can pull you into that bracket, so know where the line is as you scale.

Penalties

Once enforcement is fully active, the Data Protection Board can levy penalties of up to ₹250 crore per major violation, with specific caps such as up to ₹200 crore for failing to report a breach or for children’s-data breaches. Penalties scale with the nature and severity of the violation, so a small startup’s realistic exposure is far lower — but the ceiling signals how seriously the framework is meant to be taken.

DPDP vs GDPR: what is different

If you already know GDPR, DPDP will feel familiar but lighter in places. Both are consent-first, both give individuals rights over their data, and both reach companies outside the country that serve residents inside it. The differences that matter for a SaaS: DPDP is narrower in scope (digital personal data, not the broader “processing” GDPR reaches), its lawful bases are simpler (consent plus the Section 7 legitimate uses, rather than GDPR’s six bases), its cross-border stance is more permissive (a negative list rather than adequacy decisions), and it adds India-specific mechanics like Consent Managers and 22-language notices. If you are already GDPR-compliant you are most of the way there — the work is mapping your existing controls onto DPDP’s specifics.

A practical compliance checklist for founders

1. Map your data and roles. List what personal data you collect, why, where it is stored, who you share it with, and whether you are the Fiduciary or a Processor for each dataset.
2. Fix consent and notices. Add a clear, plain-language notice and granular, revocable, timestamped consent — no pre-ticked boxes — with language support on request.
3. Build the rights in. Let users view, correct, export and delete their data in-product, and honour erasure within 90 days.
4. Appoint a grievance officer and publish contact details with a response process.
5. Automate retention and deletion, and keep activity logs for at least a year.
6. Prepare for breaches: detection, logging, and a plan to notify the Board immediately and users within 72 hours.
7. Handle children’s data with age assurance and verifiable parental consent if minors can sign up.
8. Map cross-border flows and check your sub-processors ahead of the restricted-country list.
9. Re-check SDF thresholds as you grow, and revisit annually.

Common DPDP mistakes founders make

The recurring ones: relying on a buried, pre-ticked consent that the Rules explicitly reject; writing a privacy policy but building no way for users to actually exercise their rights; keeping data forever “just in case” instead of deleting it when its purpose ends; having no breach-response plan, so the 72-hour clock is impossible to meet; and forgetting the processor role — collecting your B2B customers’ end-user data with no contract or safeguards behind it. None are hard to avoid if you design for them early.

Build it into the product, not around it

The cheapest time to get DPDP compliance right is while you are building — consent capture, audit logs, data-export and deletion endpoints, retention automation and breach detection are far easier to design in than to bolt onto a live product with thousands of users. It also overlaps heavily with good engineering hygiene; our SaaS security checklist covers the technical foundations DPDP readiness builds on.

If you are building or scaling a SaaS for the Indian market and want compliance designed in from the start, our SaaS MVP development service and Chennai-based team can help — talk to us about where your product stands. And do confirm the current rules and deadlines with a data-protection lawyer before relying on them, since the framework is still being implemented.