India's DPDP Rules: What They Actually Require From Your Data Platform

Last updated: August 2026

Most DPDP coverage is written for legal and privacy teams, and stops at the point where the obligation becomes an engineering problem. A data platform team reading it comes away knowing that erasure is required, without knowing what erasure means for a Snowflake account with fourteen downstream marts, a Power BI extract, three years of Parquet in object storage and a nightly copy in a vendor's system.

This is the engineering translation. The dates are from the DPDP Rules 2025, notified on 13 November 2025, which phase the Digital Personal Data Protection Act, 2023 into force over eighteen months. The engineering opinions are ours, drawn from doing this work on live platforms.

One framing point before the detail. The obligations that bite hardest are not the ones about collecting consent. They are the ones that assume you can find every copy of a person's data and act on it inside a fixed window, which is a question about lineage and architecture rather than about policy.

The three dates, and which rules attach to each

The Rules did not commence all at once. They come into force in three tranches, and the middle one is often misread as a general compliance deadline when it is narrower than that.

The engineering consequence of that layout is easy to miss. Almost everything a data platform has to build sits in the 13 May 2027 tranche, which sounds distant. It is not, because erasure and breach reporting are architectural rather than procedural, and both are slow to retrofit onto a warehouse that was not designed for them.

Rule 8 and the Third Schedule: erasure with a clock on it

Rule 8, read with section 8(7) of the Act, requires personal data to be erased once the purpose it was collected for is no longer being served. That happens when consent is withdrawn, when the purpose is fulfilled, or when the person has not engaged with the service for a defined period.

The Third Schedule then sets default retention periods for specific classes of organisation, with a threshold on user numbers.

• E-commerce entities with two crore or more registered users: data is treated as no longer needed three years after the person's last interaction, or three years from the commencement of the rule, whichever is later.
• Social media intermediaries with two crore or more registered users: the same three-year period applies.
• Online gaming intermediaries with fifty lakh or more registered users: the same three-year period applies.
• A notice obligation attaches to the erasure itself. The Rules require the person to be told at least 48 hours before their data is erased.

That 48-hour notice is the requirement most likely to be missed, because it turns erasure from a batch job into a two-stage workflow. You cannot run a quarterly sweep that deletes everything past the threshold. You need a job that identifies candidates, issues notice, waits, and only then erases, with the whole sequence evidenced.

-- Stage 1: identify candidates and record that notice was issued.
-- Runs daily. Nothing is deleted here.
INSERT INTO governance.erasure_notices (data_principal_id, basis, notice_sent_at, erase_not_before)
SELECT
    p.data_principal_id,
    'third_schedule_inactivity_3y'          AS basis,
    CURRENT_TIMESTAMP()                     AS notice_sent_at,
    DATEADD(hour, 48, CURRENT_TIMESTAMP())  AS erase_not_before
FROM governance.data_principal_activity p
WHERE p.last_interaction_at < DATEADD(year, -3, CURRENT_DATE())
  AND NOT EXISTS (
    SELECT 1 FROM governance.erasure_notices n
    WHERE n.data_principal_id = p.data_principal_id
      AND n.withdrawn_at IS NULL
  );

-- Stage 2: erase only what is past its notice window and not re-engaged.
-- The re-engagement check matters: someone who logs back in during the
-- 48 hours has restarted the clock.
SELECT n.data_principal_id
FROM governance.erasure_notices n
JOIN governance.data_principal_activity p
  ON p.data_principal_id = n.data_principal_id
WHERE n.erase_not_before <= CURRENT_TIMESTAMP()
  AND n.completed_at IS NULL
  AND p.last_interaction_at < DATEADD(year, -3, CURRENT_DATE());

Why erasure is an architecture problem, not a DELETE statement

Deleting a row from the source table is the easy part. The obligation is to erase the personal data, and in a normal analytics estate that data has been copied, aggregated, joined, exported and cached in places the source system knows nothing about.

Before the 2027 date, the useful exercise is to enumerate where a single person's data physically exists. In our experience the list is longer than the team expects, and the surprises cluster in the same places.

We recommend building the inventory from column-level lineage rather than from memory or from a spreadsheet. Lineage generated from the transformation code stays current as models change, which a manually maintained register does not.

Rule 7: breach reporting on a 72-hour clock

Rule 7 splits the obligation in two. Each affected person must be told without delay, with a description of the breach, its likely consequences, the mitigation applied, and what they can do to protect themselves. The Board must receive an initial intimation without delay, followed by a detailed report within 72 hours, extendable on request, covering the facts, the impact, the mitigation and the remedial action.

The 72-hour figure is where most platforms fail, and the reason is rarely the reporting template. It is that answering the question in the report requires facts the platform does not currently record.

• Who was affected. This needs a query that goes from a compromised table or credential to a list of data principals. If your access model cannot answer who could read a given column, it cannot answer this either.
• What data was exposed. This needs column-level classification that is attached to the data rather than recorded in a separate document.
• When it started. This needs access history retained for long enough to cover the detection gap, which is usually longer than the retention on your query logs.
• What was done about it. This needs the incident process to produce a written record as it runs, rather than reconstructing one afterwards.

The practical test is to run the exercise before you need it. Pick a table, assume it was exposed, and time how long it takes to produce the four answers above from the systems you have. Teams that have not done this before commonly find the first answer takes longer than the whole 72 hours.

-- Part 1: who holds a privilege that reaches the column today.
-- Run this before an incident, not during one.
SELECT DISTINCT grantee_name, privilege, granted_on, name
FROM snowflake.account_usage.grants_to_roles
WHERE deleted_on IS NULL
  AND name = 'CUSTOMER_PII'
  AND privilege IN ('SELECT', 'OWNERSHIP');

-- Part 2: who actually queried it, and when.
-- ACCESS_HISTORY retention decides how far back this can reach,
-- which is the number to check against your detection gap.
SELECT
    user_name,
    MIN(query_start_time) AS first_access,
    MAX(query_start_time) AS last_access,
    COUNT(*)              AS query_count
FROM snowflake.account_usage.access_history a,
     LATERAL FLATTEN(input => a.base_objects_accessed) o
WHERE o.value:objectName::string = 'PROD.PUBLIC.CUSTOMER_PII'
  AND a.query_start_time >= DATEADD(day, -90, CURRENT_TIMESTAMP())
GROUP BY user_name
ORDER BY query_count DESC;

Consent state the warehouse can join to

Rule 4 and the Consent Manager framework commence on 13 November 2026. The registration obligation sits with Consent Managers rather than with every organisation, but the downstream requirement is general: processing has to be tied to a consent that is current, and consent can be withdrawn.

Most warehouses cannot express that today. Consent is held in the application database as a current-state flag, gets copied into the warehouse nightly, and carries no history. That design answers the question of whether someone consents right now. It cannot answer whether they consented at the moment a particular processing activity ran, which is the question an audit asks.

• Model consent as an effective-dated fact rather than a flag on the customer dimension, so a historical query resolves to the state that applied at the time.
• Record the purpose alongside the consent, because withdrawal is usually purpose-specific rather than total.
• Make the join to consent state a property of the modelling layer rather than something each analyst remembers, so it holds for reports nobody has written yet.
• Keep withdrawal events with their timestamps. A withdrawal is the trigger for erasure under Rule 8, so the date it happened is part of the record.

This is the change with the longest lead time, because it touches the data model rather than a job. It is also the one that most reduces the cost of everything else, since erasure triggers, breach scoping and rights requests all resolve against the same structure.

What the penalties attach to

The headline figure is a maximum of 250 crore rupees for failure to maintain reasonable security safeguards. Penalties are assessed per contravention rather than per organisation, with separate heads for breach notification failures, obligations relating to children's data, and the additional duties of a Significant Data Fiduciary.

We are not lawyers and this is not legal advice. The engineering reading worth taking from it is about where the effort should go. The largest single penalty head is attached to security safeguards, which is an area a data platform team controls directly through access design, masking and monitoring, rather than one that depends on legal drafting.

A sequence that works backwards from May 2027

The order matters more than the start date, because each item depends on the one before it. Working through them in this sequence avoids building the same inventory three times.

• Classify first. Tag columns that hold personal data, inside the platform where policy can attach to the tag. Everything downstream depends on knowing where the data is.
• Generate lineage from code. Column-level lineage produced from your transformation models tells you where a classified column propagates to. A hand-maintained register will be wrong within a quarter.
• Fix the access model. If the platform cannot produce a current list of everyone able to read a given column, it cannot support breach scoping or an access request.
• Model consent as history. Effective-dated, purpose-aware, with withdrawal events retained.
• Build erasure as a two-stage workflow. Candidate identification, notice, wait, erase, with evidence at each step and propagation to every location the lineage identified.
• Rehearse the breach report. Time it. The result tells you whether the previous five steps were done properly.

Teams that already have classification and lineage in place will find most of this is configuration. Teams that do not will find that the classification step alone takes longer than they planned, which is the main argument for starting it well before the 13 May 2027 date rather than after the November one.