The DPDP Act in 2026: A Practical Compliance Guide for Indian Websites and SaaS

If you run a website or a SaaS product in India, you have probably heard that a big data protection law is coming and that the fines run into hundreds of crores. Both halves of that sentence are true, but the timing and the practical reality are more nuanced than the panic posts on LinkedIn suggest. This is the honest version, written by developers who build and ship Indian products, not a law firm memo and not a compliance-vendor sales pitch.

Here is the short story. The Digital Personal Data Protection Act, 2023 (the DPDP Act) got Presidential assent back in August 2023, but it sat dormant for two years because the government had not written the Rules that make it work. Those Rules were finally notified in November 2025. So as of mid-2026, the law is real and final, but the obligations most businesses actually care about are not enforceable yet. They switch on in stages, with the main deadline landing around mid-May 2027. You are in the preparation window, not the panic window.

We think that is genuinely good news, because it means you have time to do this properly instead of bolting on a cookie banner the night before an audit. Below we walk through what the Act is, whether it applies to your business (spoiler: almost certainly yes), the core duties in plain English, how you actually build the technical bits, the penalties, and a realistic plan for what to do this quarter. One disclaimer up front: this is practical guidance to help you get oriented and start work, not legal advice. For a binding opinion on your specific setup, talk to a data protection lawyer.

What the DPDP Act actually is, and where it stands in 2026

The DPDP Act is India's first proper, standalone data protection law. Before it, the only thing governing personal data online was the Information Technology Act, 2000 and its 2011 SPDI Rules, which are thin and outdated. The DPDP Act replaces that patchy regime with something closer in spirit to the EU's GDPR, though it is leaner and built differently (more on the differences later).

The law works on a simple pair of roles. If you decide why and how personal data gets processed, you are a Data Fiduciary (GDPR calls this a controller). The person whose data it is, your user, is the Data Principal. Anyone who processes data on your behalf, like your cloud host or your email tool, is a Data Processor. Personal data is defined broadly as any data about an individual who is identifiable from it. Importantly, the Act only covers digital personal data: data collected in digital form, or collected on paper and later digitised. A paper register that never gets typed up is outside the Act, though in practice almost everything ends up digital anyway.

On status, be precise, because a lot of online write-ups get this wrong. MeitY notified the Digital Personal Data Protection Rules, 2025 in mid-November 2025 (most sources say 13 November, with Gazette publication on 14 November). That notification did not switch everything on at once. Commencement is deliberately phased into three tranches:

1. Phase 1 (immediate, from November 2025): the definitions and the provisions that set up the Data Protection Board of India. These are live now.
2. Phase 2 (around November 2026): the Consent Manager registration regime, roughly 12 months after notification.
3. Phase 3 (around mid-May 2027): the substantive duties that matter most to you, notice and consent, security safeguards, breach reporting, retention and erasure, children's data, Significant Data Fiduciary duties, cross-border transfer, and Data Principal rights. This is roughly 18 months after notification.

So as of 5 July 2026, only Phase 1 is in force. The core compliance duties are not yet enforceable. Until they are, the old IT Act and 2011 SPDI Rules still technically govern data protection in the interim. One more honest caveat: the Data Protection Board, the body that will actually adjudicate complaints and hand out penalties, was still being constituted through mid-2026. MeitY only invited applications for its Chairperson and Members in May 2026. So even the enforcement machinery is being built out as we write this. Treat mid-May 2027 as your working deadline, not a date that has already passed.

Does this apply to my small business?

Almost certainly yes, and this is the single most common myth we need to kill. There is no small-business, MSME, turnover, or user-count exemption in the DPDP Act. If you collect an email address for a newsletter, store customer phone numbers, run a login system, or drop an analytics cookie that captures an IP address, you are processing digital personal data and you are a Data Fiduciary. A two-person startup in Noida is in scope exactly like a large e-commerce platform.

There is one wrinkle worth being honest about. Section 17(3) of the Act gives the government the power to exempt certain classes of Data Fiduciary, and it specifically names startups, from some duties like the notice requirement and parts of the erasure and access obligations. But that is only an enabling power. As of mid-2026, the government has not actually issued any such notification. So you cannot plan around a startup exemption that does not exist yet. It may arrive before May 2027, or it may not. Build for full compliance and treat any future relaxation as a bonus.

The reach is also wider than you might expect. The Act applies to processing inside India, and it applies extra-territorially to businesses outside India that process the data of people in India in connection with offering them goods or services. So a foreign SaaS serving Indian users is squarely covered. If you are an Indian agency or product company serving Indian customers, there is no doubt at all: this is your law.

The core obligations in plain English

Strip away the legalese and the DPDP Act asks you to do a handful of sensible things. Here they are the way we would explain them to a founder over coffee.

Consent and notice. The default lawful basis for processing is consent, and consent has to be free, specific, informed, unconditional, and unambiguous, given by a clear affirmative action. In plain terms: no pre-ticked boxes, no burying agreement inside a giant terms-and-conditions blob, no bundling ten unrelated purposes into one "I agree". Every consent request must be preceded or accompanied by a notice that tells the user what data you are collecting, why, how to exercise their rights, and how to complain to the Data Protection Board. The notice has to be a standalone document in clear, plain language, and you must offer it in English or any of the 22 languages in the Eighth Schedule of the Constitution. And withdrawing consent must be as easy as giving it.

Purpose limitation and minimisation. You can only collect the data you actually need for the stated purpose, and you can only use it for that purpose. Want to use the same data for something new? Fresh notice, fresh consent.

Security safeguards. You must protect personal data with reasonable security measures. The Rules spell out a floor: encryption or masking or tokenisation, access controls, logging and monitoring, backups, and one year of retained logs. Failing this is the single most expensive thing you can get wrong under the Act, so it is worth doing well.

Retention and erasure. Delete personal data once the purpose is done or the user withdraws consent, unless a law requires you to keep it. For a few very large classes (big e-commerce, gaming, and social media platforms above specified user thresholds), the Rules add a hard three-year auto-delete clock for inactive users, with 48 hours' advance notice before deletion.

Breach notification. If you have a personal data breach, you must tell every affected user without delay, and give the Data Protection Board an initial intimation followed by a detailed report within 72 hours. There is no "it was minor so we skipped it" exemption. Unlike GDPR, DPDP has no harm threshold: any breach triggers the duty.

Grievance redressal and a contact point. You must publish the business contact of a person (or Data Protection Officer, where applicable) who can answer questions about your processing, and run an effective grievance mechanism that responds within a published timeline of no more than 90 days. Users have to exhaust your grievance process before they can go to the Board.

What actually changes for developers

This is the part we care about most, because DPDP compliance is at least half an engineering problem. Here is how the duties above translate into things you build.

Treat consent as versioned data, not a boolean. A single agreed = true column will not cut it. You need a consent object keyed to purpose, so a user can agree to "process my email for order updates" without agreeing to "send me marketing". And you need an audit-grade record of each consent event: the exact notice text or version shown, the purposes chosen, the timestamp, and the affirmative action taken, plus any later withdrawal. Think of it as an append-only consent ledger. If the Board ever asks, you need to reconstruct exactly what a given user saw and chose on a given date.

Build a real privacy notice, not a wall of text. Replace the single "Privacy Policy" link at signup with a purpose-specific, itemised notice: what fields, what purpose, and clickable links to withdraw consent, exercise rights, and complain to the Board. Multilingual delivery is expected, so architect your notice content so it can be served in more than just English.

Do not forget your existing users. For data you already hold, you do not need fresh opt-in. Section 5(2) lets you send a one-time notice to your legacy base covering what you hold and why, and you can keep processing until they withdraw. Practically, that is a one-off email, SMS, WhatsApp, or in-app campaign with embedded withdraw and rights links, and you should log delivery. Plan that campaign now; it is a clean, contained piece of work.

Build self-serve rights flows (DSAR). Users get rights to access a summary of their data, to correct it, and to erase it, plus grievance redressal and a right to nominate someone to act on their behalf if they die or become incapacitated. In code, that means authenticated endpoints for access/export, correction, and deletion, an identity-verification step, an SLA timer or ticketing workflow, and crucially, cascade deletion that propagates to your processors and backups. If you run a multi-tenant product, get this right at the tenant-isolation level; our multi-tenant SaaS architecture guide covers the data-boundary patterns that make per-user erasure actually tractable.

Nail the security baseline. The Rule 6 floor is concrete: encrypt personal data at rest and in transit, enforce least-privilege access with audit logging retained at least 12 months, run monitoring to detect unauthorised access, keep tested backups, and bind your processors contractually to the same standards. If you want a ground-up walkthrough of the fundamentals, we wrote website security basics for Indian businesses, and moving your users off shared passwords onto passkeys and passwordless auth is one of the highest-leverage things you can do to shrink breach risk. If your infra is a mess, our cloud and DevOps team does exactly this kind of hardening.

Draw a data map. DPDP has no explicit GDPR-style "record of processing" requirement, but you cannot satisfy retention, erasure, breach-scoping, or audits without knowing what personal data you hold, where it lives, which processor touches it, and what purpose and retention clock each field carries. So build the inventory anyway. It is the backbone artefact everything else hangs off.

Put processor contracts in place. You can only use a processor under a valid contract, and you stay fully liable for their compliance. So every sub-processor (cloud, analytics, email, payments) needs a data processing agreement that flows down security obligations, breach cooperation to meet your 72-hour clock, help with user requests, and deletion on termination or consent withdrawal. If you handle payments, the same discipline that makes your Razorpay webhooks idempotent and reconciled is the mindset you want across every processor boundary.

Children's data and Significant Data Fiduciary duties

Two areas carry heavier duties, and both are worth flagging early because they are hard to retrofit.

Children. Under the DPDP Act a "child" is anyone under 18, which is a much higher bar than GDPR's 13 to 16. Before processing a child's data you need verifiable consent from a parent or lawful guardian, and you have to verify that the consenting adult really is an identifiable adult, using details you already hold, details they provide, or a virtual token tied to verified age and identity from an authorised entity (think a DigiLocker-type credential). On top of that, you are barred from tracking, behavioural monitoring, or targeted advertising directed at children. This is genuinely difficult to implement at scale, partly because robust age verification pushes against data minimisation (you may end up collecting more identity data to prove age), and partly because the authorised-token infrastructure was not widely deployed as of mid-2026. There are carve-outs for specific contexts like healthcare, education, childcare, and safety-related location tracking, but a general website or SaaS gets no relief. The same verifiable-guardian regime extends to persons with disabilities who cannot make legally binding decisions.

Significant Data Fiduciaries (SDFs). This is not automatic. The government designates an entity as an SDF by notification, based on factors like data volume, sensitivity, and risk to individuals or to the state. Once designated, you carry extra duties: appoint an India-based Data Protection Officer answerable to your board, appoint an independent data auditor, run a Data Protection Impact Assessment and an audit at least every 12 months, do due diligence that your algorithms do not pose risks to users' rights, and comply with any government order to keep specified data inside India. As of mid-2026 no public list of designated SDFs had been confirmed, so unless you are notified, these duties do not apply to you yet. But if your product is scaling fast, keep this on your radar.

How DPDP differs from GDPR, and the cookie-banner myth

If you have GDPR muscle memory, do not just copy-paste it. The two laws share a philosophy but differ in ways that matter operationally.

• Lawful bases. GDPR gives you six, including the flexible "legitimate interests" and "contractual necessity". DPDP gives you effectively two: consent, or a closed, fixed list of "legitimate uses" (things like data a person voluntarily gave you, state functions, legal compliance, medical emergencies, and certain employment purposes). There is no open-ended legitimate-interest ground and no balancing test for private firms. So most private-sector processing in India must be consent-based, which raises the bar on your consent capture.
• No sensitive-data category. GDPR singles out health, biometric, religious, and other special categories for extra protection. DPDP has one uniform standard for all personal data. It layers extra duties by entity (the SDF mechanism) rather than by data type.
• Cross-border transfers. GDPR uses a whitelist (transfer is banned unless the destination is approved). DPDP inverts this: transfer is allowed by default, except to countries the government specifically blacklists. As of mid-2026 no such blacklist had been notified. Sectoral rules like RBI's payment-data localisation still apply independently, and the government can restrict specified data categories, so "free by default" is the headline but not absolute.
• Scope. DPDP covers only digital personal data. GDPR also covers structured paper filing systems.

Now the cookie question, because it is the most misunderstood. DPDP never mentions the word "cookie" and it imposes no EU ePrivacy-style banner mandate. That does not mean cookies are unregulated. Where a cookie or tracker collects personal data (an IP, a device ID, behavioural data) on a consent basis, the general DPDP notice-and-consent machinery applies. Strictly necessary cookies (session, auth, cart) can plausibly ride the "legitimate uses" exception and may not need explicit consent. Analytics, advertising, and behavioural-tracking cookies do need consent. One real difference from the EU: GDPR effectively expects granular, per-vendor toggles, while under DPDP granular consent is best practice but not strictly required, so an all-or-nothing accept/decline is currently acceptable. Cookie walls and coercive designs are out, because consent must be free. Honest caveat: this area is the least settled, drawn mostly from law-firm commentary rather than any Board ruling, and the Board could push toward GDPR-style granularity later. So build for flexibility.

The penalties, without the scaremongering

Yes, the numbers are large. The Act's Schedule sets tiered maximum penalties per breach category:

• Up to ₹250 crore for failing to take reasonable security safeguards. This is the headline figure and the single most expensive thing to get wrong.
• Up to ₹200 crore for failing to notify a personal data breach.
• Up to ₹200 crore for breaching the children's-data obligations.
• Up to ₹150 crore for a Significant Data Fiduciary breaching its extra duties.
• Up to ₹50 crore as a residual catch-all for any other contravention.
• Up to ₹10,000 on a Data Principal who abuses the system (files false or frivolous complaints, or supplies fake information).

Two things to keep in perspective. First, these are maximums per breach, not a fixed fine and not a single aggregate cap, and one incident could in theory trigger more than one head. When the Board sets the actual amount, it weighs the nature, gravity, and duration of the breach, the type of data, whether you took mitigating action, and proportionality. A tiny startup that made a good-faith mistake is not going to be treated like a negligent giant. Second, and this is the calming part: these penalties are not live yet. The Data Protection Board was still being constituted through mid-2026 and no penalty orders had been reported. The enforceable date for the substantive duties is around mid-May 2027. Notably, penalties go to the Consolidated Fund of India; the Act does not give affected individuals a right to compensation, so the remedy runs through the Board, not through damages suits.

If you get an adverse order later, you can appeal to TDSAT (the Telecom Disputes Settlement and Appellate Tribunal) within 60 days, and the bare Act does not require you to pre-deposit any part of the penalty to appeal. Ignore any blog claiming a 50% pre-deposit rule; that is not in the law.

What to actually do this quarter

You have until roughly mid-May 2027 for the main duties, and Consent Manager registration lands around November 2026. That is enough runway to do this calmly if you start now. Here is a realistic order of work for an Indian SMB or startup:

1. Map your data. List every place you collect personal data, what fields, why, where it is stored, which processor touches it, and how long you keep it. Nothing else works without this.
2. Audit your security against the Rule 6 floor. Encryption at rest and in transit, access controls, logging with 12-month retention, monitoring, backups. Fix the gaps here first, because this carries the biggest penalty.
3. Redesign your signup consent. Kill pre-ticked boxes and bundled agreement. Build a purpose-keyed consent record and a plain-language, itemised notice with withdraw and rights links.
4. Build the withdraw and rights flows. A self-serve way to withdraw consent, plus access, correction, and erasure endpoints with cascade deletion to processors and backups.
5. Plan your legacy-user notice. Draft the one-time Section 5(2) notice campaign for your existing database and log delivery.
6. Sign processor DPAs. Get data processing agreements in place with your cloud, email, analytics, and payment vendors, flowing down security and deletion duties.
7. Set up breach and grievance processes. A breach-detection and 72-hour reporting playbook, and a published grievance contact with a response timeline under 90 days.
8. If you touch children's data, address age-gating early. It is the hardest piece, so do not leave it to the end.
9. Write it down. Keep a simple internal record of what you did and when. If the Board ever asks, demonstrable good-faith effort matters.

That is not a weekend job, but it is also not a crisis. Most of it is good engineering hygiene you would want anyway. If your team is stretched, this is the kind of retrofit our Node.js development team does regularly: consent ledgers, DSAR endpoints, and security hardening baked into an existing product without tearing it apart.

Common questions about the DPDP Act

Is the DPDP Act in force in 2026?

Partly. The Act is enacted and the DPDP Rules, 2025 were notified in mid-November 2025, so it is final law. But enforcement is phased. As of mid-2026 only Phase 1 is live (the Data Protection Board framework and definitions). Consent Manager registration comes around November 2026, and the core duties, notice, consent, security, breach reporting, retention, children's data, and Data Principal rights, become enforceable around mid-May 2027. So the substantive obligations are not yet enforceable, but you should be preparing for them now.

Does the DPDP Act apply to my small business or startup?

Yes. There is no size, turnover, or user-count exemption. Any business that processes digital personal data, even just customer emails or login details, is a Data Fiduciary. The Act does let the government carve out startups from some duties in future, but no such exemption had been notified as of mid-2026, so plan for full compliance.

Do I need a GDPR-style cookie banner for a DPDP website?

Not exactly. DPDP does not mention cookies and has no ePrivacy-style banner mandate. But if your cookies collect personal data on a consent basis (analytics, advertising, behavioural tracking), you need a DPDP-compliant notice and consent flow, which is similar in spirit but different in form from an EU banner. Strictly necessary cookies can often rely on the legitimate-uses exception. Granular per-vendor toggles are best practice but not strictly required under DPDP as it stands.

What are the penalties under the DPDP Act?

The Schedule sets maximums per breach: up to ₹250 crore for weak security safeguards, up to ₹200 crore each for breach-notification failures and children's-data violations, up to ₹150 crore for Significant Data Fiduciary failures, and up to ₹50 crore as a catch-all. These are ceilings, not fixed fines; the Board weighs gravity, data type, and mitigation. They are also not being actively enforced yet, since the main duties commence around mid-May 2027 and the Board was still being set up in mid-2026.

What is the deadline to become DPDP compliant?

Treat around mid-May 2027 as your working deadline for the core Data Fiduciary duties, roughly 18 months after the November 2025 notification. Consent Manager obligations arrive earlier, around November 2026. Dates shift by a day depending on whether you count from the 13 November signing or the 14 November Gazette publication, so read it as mid-May 2027 rather than a single settled date.

The honest summary

The DPDP Act is real, final, and it applies to almost every Indian website and SaaS, including small ones. But as of mid-2026 the duties that carry the scary penalties are not enforceable yet, and the Board that would enforce them is still being staffed. That combination is a gift: you have a genuine runway to mid-2027, and most of the work (know your data, secure it, get consent honestly, let people withdraw and delete) is stuff a well-run product should do anyway. Do not panic, do not buy a fear-driven compliance package, and do not believe anyone who tells you it is already fully in force or that startups are automatically exempt. Both are wrong. Start with your data map and your security baseline this quarter, and work through the rest in order.

A last honest note: this guide is meant to orient you and get engineering moving, not to serve as legal advice. Section and rule numbers and exact dates in the public commentary vary slightly, and the wording that binds you is the official MeitY-published Act and Rules. For a formal opinion on your specific business, work with a data protection lawyer. If you want a hand translating any of this into actual code and infrastructure, that is our day job, and we are happy to do a quick DPDP-readiness look at your site or app. You can message us on WhatsApp or send us the details and we will tell you honestly where you stand and what is worth doing first.

Want a straight, no-jargon read on how DPDP-ready your website or SaaS is? We will map your data flows, check your consent and security setup against the Rules, and give you a prioritised fix list with flat INR quotes and GST invoices. No fear-selling, just what actually needs doing before mid-2027. → Get a DPDP-readiness review of your site or app