DPDP Rules 2025 for engineers: what you actually have to change in your codebase

The Digital Personal Data Protection Act 2023 received presidential assent in August 2023. The DPDP Rules 2025 gave it operational specificity: defined consent mechanics, data principal rights, breach notification timelines, and a phased enforcement schedule. Phase I went live in November 2025 with the constitution of the Data Protection Board of India. Phase II, which activates consent management, breach notification, and the data principal rights framework, arrives in November 2026. Full enforcement follows in May 2027.

Most DPDP guides published in the past year were written for DPOs and compliance officers. They map sections of the Act to business obligations. What they skip is what each obligation requires from a backend engineer: which tables need new columns, which APIs need new endpoints, which pipelines need new automations. This article covers the six technical obligations the Rules create, organised by what they require from your codebase and when.

Consent is now infrastructure

The DPDP Rules require that consent be informed, free, specific, and unambiguous. The first two conditions rule out pre-ticked checkboxes and dark patterns. The last two conditions, specific and unambiguous, require separate consent for each distinct processing purpose. A single 'I agree to the terms' toggle does not clear the bar.

The harder requirement is demonstrability. If the Data Protection Board asks for evidence that a user gave consent for a specific purpose on a specific date, you need to produce it. That means a consent_records table (or its equivalent) with at minimum: principal identifier, purpose category, timestamp, consent version, collection channel (web, app, IVR), and a revocation timestamp when applicable.

The Rules introduce Consent Managers: registered third-party intermediaries that manage consent on behalf of users and communicate it to data fiduciaries via standardised APIs. This becomes mandatory in November 2026. Data fiduciaries will need to accept consent signals from registered Consent Managers, propagate withdrawals to all downstream systems within a defined SLA, and respond to consent queries: what has this user consented to, and what have they revoked.

Minimum viable implementation: the consent_records table, an inbound API to receive consent events, and an asynchronous revocation pipeline that fans out to every system holding the user's data. The revocation pipeline is the part most teams underestimate. A withdrawal that deletes the consent row but leaves the user's data in an email marketing tool is non-compliant.

Purpose limitation is a schema constraint

The Act permits processing only data 'necessary for the specified purpose.' Two words carry weight: necessary and specified. Necessary means you cannot collect more than the task requires. Specified means the purpose must be declared at collection; you cannot later use data for a different purpose without fresh consent.

This creates specific problems in common product architectures:

• If you collect date of birth for age verification, you cannot reuse it for birthday-based personalisation without a separate consent for that purpose.
• If your analytics pipeline copies PII from your production database into a data warehouse 'for future analysis', each category of data in that warehouse needs a documented purpose.
• Fields collected at onboarding but only consumed months later need either a declared purpose at collection or to stop being collected.

The practical starting point is a data inventory: map every field you collect to the purpose declared at collection and every downstream system the field reaches. Fields with no documented purpose are your first compliance gap. Fields flowing to systems with no legitimate processing need are your second. This inventory is also the prerequisite for the data erasure obligation covered in the final section.

Data principal rights: the backend you need to build

The DPDP Act grants individuals six rights: access to their personal data in a readable format, correction of inaccurate data, erasure when the purpose is fulfilled or consent withdrawn, grievance redressal through a designated contact, the right to nominate someone to exercise rights after death or incapacity, and the right to withdraw consent. The last right is covered under consent infrastructure; the other five require dedicated backend support.

Rights 1 through 4 require backend endpoints. The standard pattern is a data subject request (DSR) pipeline:

GET  /api/privacy/export      # queue a full personal-data export
POST /api/privacy/correct     # submit a correction request
POST /api/privacy/erase       # initiate an erasure workflow
POST /api/privacy/nominate    # store nominee details
POST /api/privacy/grievance   # log a grievance and route to the response team

The export endpoint is the simplest to specify and hardest to implement correctly. A proper export requires joining across every table holding the user's PII and producing structured output, either JSON or CSV, within a defined window. Regulatory guidance points to something in the 30-day range for access requests. The challenge is not the JOIN; it's knowing which tables to include. This is another reason the data inventory matters.

The erasure endpoint is where most implementations fall short. Deleting a user from your users table does not reach their records in backup archives, the analytics warehouse, email send logs, third-party marketing tools, or the support ticket system. The Rules provide an exemption for data held under a legal obligation (GST records, financial audit trails, court-ordered retention), but everything outside those exemptions is in scope. The erasure pipeline needs to reach all of it, with documented confirmation that each system was cleared.

The nomination right has no near-term enforcement urgency and no obvious analogue in most product databases. A user_nominees table with nominee name, relationship, and contact information is sufficient to meet the obligation for now.

Breach notification: 72 hours means an automated pipeline

The DPDP Rules require Data Fiduciaries to notify the Data Protection Board within 72 hours of becoming aware of a personal data breach. 'Becoming aware' starts the clock. The countdown begins when you know, not when the incident occurred.

What the notification pipeline needs:

• Automated detection that pages on-call immediately. A misconfigured S3 bucket made public, an exposed database port, or leaked credentials should trigger an alert within minutes, not be found in the next morning's log review.
• A triage template a first responder can complete within 24 hours: what data was affected, how many data principals are impacted, which sensitivity categories are involved (health, financial, children's data), and whether the breach is ongoing.
• A designated contact at the company who is authorised to file with the Data Protection Board and who knows where the filing portal is before the incident happens.

Significant Data Fiduciaries (SDFs) are organisations processing data for large numbers of users or in sensitive categories. They face additional requirements: a Data Protection Officer who reports directly to the board, annual Data Protection Impact Assessments, and mandatory security audits. The Board has not published its SDF classification criteria. Any Indian SaaS processing data for more than a few million users, or handling health, financial, or children's data, should plan for SDF obligations as a precaution.

Cross-border transfers: map your processor stack first

The DPDP Rules take an allowlist approach to cross-border data transfers. The Central Government will publish a list of countries to which personal data may be transferred freely. Transfers continue under interim provisions until that list is published, but planning needs to happen now, because the list may exclude regions you are currently using.

The work is a processor inventory. For every third-party service that receives personal data from your users, record what personal data they receive, where they store it, and whether they offer an India data residency option:

• Cloud providers (AWS, GCP, Azure): regional selection determines where data sits. Major regions are likely to make the allowlist, but confirmation requires waiting for the Government's notification.
• Analytics platforms (Mixpanel, Segment, Amplitude, PostHog): most US-based analytics services default to US storage. Several offer EU or India residency options; check their data processing agreements.
• CRM and support tools (Salesforce, HubSpot, Zendesk): data residency addendums are available for enterprise tiers. Worth confirming now rather than at audit time.
• Transactional email (SendGrid, Postmark, Amazon SES): these receive email addresses and, in some cases, personalisation data. Check their DPAs.

For Significant Data Fiduciaries, the Rules reserve a 'critical personal data' category (not yet fully defined) that must be processed only in India. Once defined, it may require selecting India-region deployments or migrating specific data categories. Having the processor inventory ready means you can respond quickly when that definition lands.

Data erasure when the purpose ends

The Act requires that personal data be erased when 'the purpose for which it was collected has been fulfilled', unless a legal obligation requires retention. You cannot hold user data indefinitely because deleting it is operationally inconvenient. A defined retention schedule is a legal requirement.

Three things this requires from your data layer:

• A data_retention_expiry column or equivalent on records containing PII, calculated from last meaningful activity or end of the stated processing purpose.
• A scheduled job that runs erasure workflows on expired records, typically a soft-delete pass followed by a hard-delete or anonymisation pass after a grace period, with confirmation logging.
• Clear categorisation of which data must be retained for statutory reasons (GST-mandated records, financial audit trails, court-ordered retention) and which should be erased on schedule.

The data inventory from the purpose-limitation work feeds directly into this. Without a map of what you hold, where, and why, you cannot build a retention schedule that holds up to scrutiny.

DPDP Rules 2025 enforcement timeline: what to build and when

Two obligations have the shortest runway: consent infrastructure and breach notification both activate in Phase II, November 2026. Neither is quick to build. The consent system needs to integrate with registered Consent Managers (an external API dependency), and breach notification needs to be wired into your monitoring stack with a tested triage process. Starting in mid-2026 is too late.

Start with the data inventory regardless of which obligation you prioritise first. It is the prerequisite for erasure, data principal rights, purpose limitation compliance, and the cross-border transfer assessment. It will also surface the gaps you didn't know existed: data in systems that have no documented reason to hold it, fields collected without a clear purpose, third-party processors not listed in your privacy notice.

The DPDP Rules are the first time Indian data protection law has created obligations specific enough to drive engineering decisions. The maximum penalty for failing to implement reasonable security safeguards is INR 250 crore. Getting the engineering work done is not just compliance; it is risk management that your investors, auditors, and enterprise customers will all eventually ask about.