DPDP Rules are live. Here is what your backend actually has to change.

The DPDP Rules were notified on 14 November 2025. If you build or operate a product that touches personal data of Indian users, you now have a set of specific, operational requirements that did not exist before. The overall framework is not new: the DPDP Act passed in 2023, but the Rules are what turn principles into obligations — what the consent notice must say, how many hours you have after a breach before notifying the Data Protection Board, how long access logs must be retained.

Most of the coverage since November has been aimed at legal and compliance teams. The business-level summaries explain what the rules mean compared to GDPR; the legal analyses parse the penalty structure. Almost nothing answers the question an engineer needs to answer: what do I build, by when, and in what order?

This maps the five engineering changes the DPDP Rules require, in rough priority order for a product team at an Indian SaaS company. The headline deadline is May 2027, but several decisions, especially around consent architecture, need to happen before that or become expensive to undo.

Three dates, and why May 2027 is not the whole story

MeitY structured enforcement in three phases:

Eleven months looks comfortable. It is not, for two reasons. The engineering work is substantial: a correct consent system is a data model, a set of APIs, a notice-delivery mechanism, and a withdrawal flow. Not a modal with a single checkbox. Getting that right in an existing product without touching unrelated parts of the codebase takes time.

The November 2026 date also matters more than it appears. Consent Managers (registered third-party entities that manage consent on users' behalf across multiple data fiduciaries) become available then. If your consent architecture is tightly coupled to your own UI flows when that happens, you will retrofit it under active regulatory supervision rather than before it.

Consent is now a data model, not a checkbox

Rules 3 and 4 specify that consent must be purpose-specific, meaning you cannot bundle "analytics, marketing emails, and feature updates" into a single acceptance. Each distinct purpose is a separate consent item. The notice accompanying each consent request must state, without reference to any other document, what data is being collected, why, how to withdraw, and how to file a complaint.

Consent must also be withdrawable at any time, and withdrawal must be as accessible as the original consent flow. The consent event itself (when it was given, which notice version was shown, through which channel) must be recorded.

Most existing SaaS products store consent as a boolean column on the user row, or in a generic settings object. That will not satisfy the Rules. The data model needs to change:

-- Purpose-specific consent, one row per user-purpose pair
CREATE TABLE user_consents (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id         UUID NOT NULL REFERENCES users(id),
    purpose_code    TEXT NOT NULL,        -- e.g. 'marketing_email', 'analytics', 'third_party_sharing'
    granted_at      TIMESTAMPTZ,          -- NULL if never granted or withdrawn before first grant
    withdrawn_at    TIMESTAMPTZ,          -- SET when withdrawn; cleared if re-granted
    notice_version  TEXT NOT NULL,        -- pin to the exact notice shown at time of consent
    channel         TEXT NOT NULL,        -- 'web_ui', 'mobile_app', 'api', 'consent_manager'
    UNIQUE (user_id, purpose_code)
);

-- Index for "does this user have active consent for X?"
CREATE INDEX idx_consents_active
    ON user_consents (user_id, purpose_code)
    WHERE granted_at IS NOT NULL AND withdrawn_at IS NULL;

The notice_version field is more important than it looks. When you materially change the notice for a given purpose (new data category, new third-party recipient), existing consents for that purpose need renewal. Without versioning pinned to each consent row, you have no way to know which users saw which version.

The withdrawal API is a first-class requirement, not a support ticket flow. A user who has authenticated should be able to withdraw consent for any specific purpose through the product's own interface. Log the withdrawal event; check consent status before every use of personal data for that purpose.

The erasure endpoint: a 90-day SLA with a 48-hour delay built in

Data principals can request erasure of their personal data. The Rules set a 90-day window from receipt of the request. There is a specific procedural requirement inside that window: the data fiduciary must notify the user at least 48 hours before completing the erasure, giving them a chance to reconsider.

Erasure does not necessarily mean hard deletion from every table and backup. Anonymising identifying fields, including name, email, phone, and other directly identifying values, satisfies the requirement if the data is genuinely de-identified and is retained for legal or audit purposes. What is not permissible is retaining data that can be associated with the individual after a valid erasure request.

Backups require specific attention. If you take daily or weekly snapshots, personal data present in those snapshots should be flagged for deletion on next rotation or through a targeted backup-level deletion process, depending on your backup technology.

The engineering surface for erasure handling:

• An intake mechanism (email address, in-app form, or both) that writes a timestamped record on receipt
• A queue or scheduler that triggers the 48-hour pre-deletion notice to the user
• The deletion or anonymization job, scoped per user ID, covering all tables that hold identifying data
• A way to surface unfulfilled requests in a dashboard or report so the SLA is visible to whoever owns compliance

Breach notification: 72 hours from when you know, not when you finish investigating

This is the provision with the largest gap between what most engineering teams currently do and what the Rules require. Under Rule 7, a data fiduciary must:

• Notify the Data Protection Board of India without delay, providing nature, extent, timing, location, and likely impact of the breach
• Submit a detailed report within 72 hours of becoming aware, or a longer period if the Board grants an extension
• Notify affected data principals within 72 hours of the Board notification

The penalty for missing this: up to ₹200 crore per incident.

The engineering changes here are partly alerting infrastructure and partly process:

• Security alerting that routes probable breach signals to a named responder, not just a generic on-call queue
• A written runbook, accessible to whoever receives the alert, covering: assess, decide if reportable, notify DPBI, notify users, with role owners at each step
• A breach register that logs detection time (which starts the official clock), assessment notes, and notification timestamps

The notification to the DPBI will go through the Board's own portal once it is operational; the technical mechanism is not the hard part. The hard part is compressing your internal assessment-and-escalation path from "days" to "hours."

Rule 6: security safeguards that are now required, not recommended

Rule 6 specifies the minimum technical safeguards for any entity processing personal data:

• Encryption of personal data at rest (AES-256 or equivalent) and in transit (TLS)
• Access controls restricting personal data access to authorised personnel only
• Data masking and anonymization capability, specifically for non-production environments
• Monitoring logs of who accessed personal data, retained for one year

The common gaps in Indian SaaS products:

Column-level encryption on an existing PostgreSQL schema is the most time-consuming item on this list. If you encrypt a column that you also filter or sort on, you need application-level decryption before those operations, which has query implications. Audit the schema first, identify which columns require encryption versus which only need access controls, and plan the migration with realistic timelines.

The consent manager question: what to decide before November 2026

Consent Managers become available in November 2026. A registered Consent Manager, incorporated in India and required to demonstrate a minimum ₹2 crore net worth, can hold and manage user consent across multiple data fiduciaries on the user's behalf. From the user's perspective, it is a permission broker: they can set consent preferences in one place and have them propagate across the products they use.

For most Indian SaaS companies, the decision is not whether to become a Consent Manager (you are not the target for that role) but whether your consent system can accept signals from one. When a user presents a consent signal originating from a registered Consent Manager, your system should be able to ingest it.

This is mostly an API design decision. If the consent model you build in the earlier step records `channel` as a free-text field and purpose codes as first-class identifiers, adding `consent_manager_id` as an optional source field later is straightforward. If your consent logic is tightly coupled to your own UI flows, retrofitting external-signal support is a larger change.

The practical approach for most teams: build the internal consent system well and source-agnostically now; revisit the Consent Manager integration point when registered providers actually appear in the market. The decision you need to make before November 2026 is architectural, not operational.

A realistic build order

If you are planning the work, a reasonable sequence:

For a team where DPDP compliance is one workstream among several, 4 to 5 months of elapsed time is realistic to get items 1 through 4 done without cutting corners. Work starting in January 2027 for a May deadline will be rushed. Work starting now will not.

The Rules are not designed to put product companies out of business — the compliance bar is achievable. The engineering requirements are not unusual compared to SOC 2 or ISO 27001; many of the safeguards in Rule 6 will already be partially in place. What is genuinely new is the consent architecture and the erasure SLA, and those are worth treating as product features rather than compliance overhead, because users who can see and control what data you hold and why will eventually trust the product more for it.