DPDP Act Compliance Checklist for SaaS (2027 Deadline)

The Rules are notified. The clock is running. If you build or run a SaaS product that touches the personal data of people in India, you've got concrete work to do before the substantive obligations kick in. The good news? Most of it is the kind of work an engineering and product team already knows how to plan. Below, the checklist is broken into the parts you actually own, so 2027 feels like a roadmap item and not a last-minute scramble.

This is general information for builders, not legal advice. Talk to a qualified Indian data-protection lawyer before you finalise notices, contracts, or your breach playbook.

The DPDP timeline you are working against

The Digital Personal Data Protection Act, 2023 became enforceable through the DPDP Rules, which the Ministry of Electronics and Information Technology notified on 13 November 2025. The Rules roll out in phases, so not everything lands on day one.

The 13 May 2027 deadline is the one most SaaS teams should plan around. That is when notice requirements, security safeguards, breach notification, and data-principal rights all become live obligations. You can read the official notification on PIB, and the broader Act on the MeitY site.

The trap, especially for startups, is treating 2027 as far away. It isn't. The engineering changes below touch your data model, your consent flows, your logging, and your vendor contracts, and all of those are slow to change once a product is in production. Start now, ship calmly. Start in 2027, ship under pressure.

Before you write a line of code, get your role straight. Decide why and how personal data is processed? You're a Data Fiduciary. Only process data on someone else's instructions? You're a Data Processor. The obligations differ, and the rest of your compliance work depends on which one you are, so read data fiduciary vs data processor first.

Consent capture done right

Consent under DPDP isn't a checkbox you bury at the bottom of a signup form. It has to be free, specific, informed, unconditional, and unambiguous, and it has to be tied to a clear notice. That notice tells the person what data you collect, why, how to withdraw consent, and how to file a complaint.

What this means in product terms:

• One purpose per consent. Do not bundle "marketing emails" with "run the service". Each purpose gets its own opt-in.
• Withdrawal is as easy as granting. If a user gave consent in two taps, they must be able to withdraw in roughly the same effort.
• Notice is available in English and the languages in the Eighth Schedule of the Constitution. Plan your copy and translation pipeline accordingly.
• You can prove consent later. Store what was shown, when, and what the user chose.

That last point is where most teams underestimate the work. "We have a consent checkbox" is a long way from "we can reconstruct, for any user, the exact notice version they saw and the moment they agreed." You need a versioned record.

So store consent as an immutable event, not a mutable boolean on the user row. A boolean tells you the current state. An event log tells you the history, which is exactly what a regulator or a data principal will ask for.

{
  "event": "consent.granted",
  "user_id": "usr_9f2c...",
  "purpose": "service_login",
  "notice_version": "2026-04-11",
  "scope": ["email", "phone"],
  "ip": "203.0.113.7",
  "occurred_at": "2026-06-21T09:14:32Z"
}

The consent manager framework, registrable from 13 November 2026, adds a layer where users can manage consent across fiduciaries through a registered intermediary. Relevant to your product? Read our DPDP consent manager framework breakdown. For most SaaS products the near-term job is simpler: capture clean, purpose-scoped consent and keep an auditable record of it.

NamoID is built to make this concrete at the identity layer. Every provider connection and verification records consent with timestamp, IP, and scope, written as an event, so the proof is a byproduct of the flow rather than a separate system you have to remember to update.

Wiring data-principal rights

A data principal is the person whose data you hold. DPDP gives them rights, and Rule 14 sets out the process for exercising them. Your product has to be able to honour these without a human manually querying a database every time.

The core rights you must support:

• Right to access (Section 11). A summary of what personal data you process about them and what you do with it.
• Right to correction and erasure (Section 12). Fix wrong data, update stale data, delete data you no longer need a lawful basis to keep.
• Right to grievance redressal (Section 13). A clear channel to raise a complaint, with a published contact.
• Right to nominate. Someone who can act on the data principal's behalf in case of death or incapacity.

Two timing details to design around. Requests for access, correction, updating, and erasure should be answered within a defined window, and the published practical reading of the Rules points to a ninety-day outer limit for handling these requests. Separately, before you erase data, the Rules contemplate giving the data principal advance notice. Build these timers into your workflow, not into a runbook that a busy on-call engineer has to remember.

The engineering shape of this:

Notice the tension in erasure. You must delete the person's data, but you must also keep proof that you deleted it and keep your audit trail intact. The clean answer is a soft-delete that removes or masks the personal fields while leaving an immutable tombstone event behind. NamoID is built this way: a deletion cascades a soft-delete plus a tombstone event, and the DSAR export endpoint returns a user's full event history plus their connected providers in one call. That is the access right and the erasure right satisfied from the same append-only log.

Breach process and reporting

This is the part that catches teams off guard. The timeline is tight, and the clock starts the moment you become aware, not when you finish investigating.

Under the DPDP Rules, on becoming aware of a personal data breach a Data Fiduciary must notify the Data Protection Board without delay, and then provide a detailed report to the Board within 72 hours (the Board can allow longer on a written request). You must also notify affected data principals in plain language, telling them what happened, what data was involved, what they can do to protect themselves, and how to reach you. Failure to report can draw penalties up to ₹200 crore per the Act's schedule. The MediaNama breakdown walks through the two-stage timeline in detail.

Seventy-two hours is not long once an incident is real. To hit it you need three things ready in advance:

1. Detection. Logging and alerting that surface anomalies fast. You cannot report a breach you did not notice.
2. A decision tree. Who declares an incident, who drafts the Board report, who signs off on the user notice. Decide this now, not at 2am.
3. Pre-written templates. A skeleton Board report and a plain-language user notice you fill in, rather than draft from scratch under pressure.

We go deep on the mechanics, including what the report must contain, in DPDP breach notification in 72 hours. Bookmark it for your incident runbook.

Vendor and processor contracts

Your DPDP posture is only as strong as the processors you hand data to. A vendor leaks data? You, as the fiduciary, are still on the hook to the data principal and the Board. There's no passing the buck.

The checklist here is contractual and operational:

• A written contract with every processor that binds them to process data only on your instructions, for your stated purposes.
• Breach flow-through. Your processor must tell you fast enough that you can still meet your own 72-hour Board report. A vendor that learns of a breach and sits on it for a week has broken your timeline.
• Sub-processor visibility. Know who your vendors hand data to. Keep the list current.
• Deletion on termination. When the contract ends, the processor deletes or returns the data.
• Residency alignment. Your vendor's storage choices must not undercut your own residency commitments.

Auth and identity are a prime example. If you outsource login, MFA, and verification, that vendor sees a lot of personal data. Pick one whose contracts, breach process, and residency match your obligations. If you are weighing this, our build vs buy auth in India post frames the tradeoff, and the role split in data fiduciary vs data processor tells you which obligations stay with you regardless.

Audit trail and residency

Two foundations sit under everything above: a trustworthy record of what happened, and clarity on where data lives.

Audit trail. Most DPDP obligations resolve to one question a regulator can ask: "show me." Show me the consent. Show me when access was granted. Show me that you deleted the data. Show me the breach timeline. If your system can only show current state, you cannot answer. If it keeps an append-only event log, every answer is a query.

Design the log to be immutable and complete. Every state change appends an event: registration, login, MFA enrolment, provider connection, consent grant and withdrawal, token issuance, deletion. Do not allow updates or deletes on the log itself. Our DPDP audit trail requirements post covers the data model and retention questions in depth.

NamoID is built around exactly this primitive. The events table is append-only, every state-changing operation writes to it, and the DSAR export reads from it. The audit trail is not a feature bolted on for compliance. It is how the system records its own work.

Residency. The Rules give the government power to restrict transfers of certain personal data outside India, and Significant Data Fiduciaries face tighter localisation expectations. Even where the law does not yet force your hand, many Indian customers will ask where their data sits. Design so you can keep India data in India per organisation. We cover the legal contours in data localization under DPDP Rule 15. NamoID is built with a per-organisation data-residency hint so you can honour an India-resident commitment without re-architecting later.

The full checklist

Here is the consolidated DPDP compliance checklist. Treat it as a backlog, not a one-time audit.

Foundations

• Confirm whether you are a Data Fiduciary, a Data Processor, or both.
• Map your personal data: what you collect, why, where it lives, who you share it with.
• Identify whether you might be a Significant Data Fiduciary, which carries extra duties.

Consent and notice

• One purpose per consent, no bundling.
• Withdrawal as easy as granting.
• Versioned notice in English plus required Indian languages.
• Immutable consent records: who, what notice version, what scope, when.

Data-principal rights

• Access endpoint returning the user's data and processing history.
• Self-serve correction plus audited admin override.
• Soft-delete erasure with a tombstone, advance notice before erasing, no audit-trail destruction.
• Published grievance contact with a tracked SLA.
• Handle requests within the ninety-day outer window.

Breach readiness

• Detection and alerting that catch incidents quickly.
• Named owners for declaring incidents and signing notices.
• Pre-written Board report and plain-language user notice.
• Process to file the detailed Board report within 72 hours.

Vendors and processors

• Written processor contracts binding instructions and purpose.
• Breach flow-through fast enough to meet your own deadline.
• Current sub-processor list.
• Deletion or return on contract end.

Audit and residency

• Append-only event log for every state change.
• Export tooling that reads the log for DSAR requests.
• Per-organisation residency control to keep India data in India.

If you want the identity slice of this checklist handled by one issuer URL, that is what NamoID is being built to do. A single OIDC issuer that carries OAuth 2.1 with PKCE, passkeys and MFA, India verification rails like DigiLocker and Aadhaar offline KYC, and the audit, consent, and residency primitives above. See how that consolidates in one OIDC issuer for auth plus India rails plus DPDP.

FAQ

When does the DPDP Act actually become enforceable for my SaaS?

The DPDP Rules, 2025 were notified on 13 November 2025 and phase in over eighteen months. The substantive obligations that affect most SaaS products, including notice, security safeguards, breach reporting, and data-principal rights, take effect on 13 May 2027. The consent manager framework turns on earlier, on 13 November 2026.

Does DPDP apply to a small startup or only to large companies?

It applies based on whether you process personal data of people in India, not on your size. DPDP for startups is real. The main relief for smaller players is that the heaviest duties, such as appointing a Data Protection Officer and running data protection impact assessments, attach to Significant Data Fiduciaries, a category the government designates based on volume and sensitivity of data.

What is the DPDP breach notification timeline?

On becoming aware of a personal data breach you must notify the Data Protection Board without delay, then file a detailed report within 72 hours, and notify affected data principals in plain language. The 72-hour clock starts at awareness, not at the end of your investigation. We cover the detail in DPDP breach notification in 72 hours.

Do I have to store Indian users' data inside India?

The Rules let the government restrict transfers of certain personal data outside India, and Significant Data Fiduciaries face stricter localisation expectations. Even where the law does not mandate it, many Indian customers will require it. Designing for per-organisation residency now avoids a painful migration later. See data localization under DPDP Rule 15.

Bring identity and India compliance under one roof

DPDP work is broad, but a large share of it lives at the identity and verification layer: consent, audit trail, deletion, breach-relevant logging, and residency. NamoID is built to handle that slice behind a single OIDC issuer so you are not stitching it together across four vendors before the 2027 deadline.

If that fits your roadmap, book a 30-minute demo and we will walk through your flows, or email us at hello@namoid.in. The product ships soon, and we are happy to map your DPDP timeline against ours.