DPDP Consent Readiness: How Indian Enterprises Can Prepare Data Workflows Before the 2026–27 Compliance Window

DPDP readiness is not about adding one consent checkbox

Many Indian enterprises are treating the Digital Personal Data Protection Rules, 2025 as a documentation exercise. The plan usually sounds like this: 

• “We’ll update the privacy policy.”
• “We’ll add a consent popup.”
• “Legal will draft the notice.”
• “We’ll handle requests manually when they come.”

Each of these is necessary, but none is enough. A popup records a click, and a policy describes an intention. Neither shows what happens to a person’s data once the click is recorded. 

The question DPDP puts to you is closer to this: can your organization prove what data is collected, why it collected it, and what consent was given; where the data sits; who can access it; and how it handled a request from that person? This article is general information, not legal advice. Consult qualified counsel on how the DPDP Act and Rules apply to your organization.

That is a workflow question, and it is much harder to answer in a hurry.

The runway: what starts when

The Rules were notified on 13 November 2025, and commerce will be phased in. Rule 4 comes into force one year after publication, and Rule, 3, 5 to 16, 22, and 23 comes into force eighteen months after publication, in calendar terms: 

Date	What takes effect	What it means for you
13 Nov 2025	Definitions and the Data Protection Board machinery (Rules 1, 2, 17–21)	Already in force
~13 Nov 2026	Rule 4: Consent Manager registration	Concerns registered Consent Managers, not your own consent obligations
~13 May 2027	Rules 3, 5–16, 22, 23, plus the core of the Act: notice, consent, safeguards, breach intimation, retention, rights, penalties	The date most enterprises are working towards

Two notes on the table:

• Sources differ by a day on the exact dates. One tracker describes 13 November 2026 and 13 May 2027 as computed dates that remain interpretation until officially confirmed, while India Briefing gives 14 November 2026 and 14 May 2027. Treat mid-November and mid-May as your working dates and confirm with counsel. 
• The November 2026 date is the one most often misread. It is the Consent Manager regime. Your obligations to give notice and obtain consent arrive with the May 2027 group.

This actually matches the commentary from advisers, who describe Consent Manager provisions taking effect on 14th November 2026 and core obligations on consent, security, breach reporting, vendor governance, and individual rights from 14th May 2027. The exact day varies by a day between sources, depending on how the Gazette date is counted. 

One watch item. In January 2026, MeitY reportedly floated shortening the timeline from 18 months to 12 months for Significant Data Fiduciaries, with a stakeholder comment window closing on 4 February. One tracker found no amending instrument as of 6 September 2026, and reported that a constitutional challenge before the Supreme Court has not produced a stay. Sensible planning is to work towards May 2027 but treat November 2026 as your internal target for consent and record design. That is when the design and testing work needs to be done. 

The stakes justify the effort. The Act’s penalty schedule sets ceilings by category. These include ₹250 crore for security safeguard failures, ₹200 crore for failure to notify the Board of a breach, ₹200 crore for breaches of children’s data obligations, ₹150 crore for Significant Data Fiduciary non-compliance, and ₹50 crore for other violations. These are fixed-rupee ceilings, not turnover-based, and a single incident can combine a safeguards failure with a notification failure.

The real question: can you prove it?

The Act puts the burden of proof on the Data Fiduciary. Readiness means being able to answer six questions on demand: 

1. What personal data did we collect?
2. Why did we collect it, and for which specific purpose?
3. What consent did the person give, and to which notice version?
4. Where is the data stored across systems, vendors, and backups?
5. Who accessed it, and do we have a log to show it?
6. How did we handle the person’s access, correction, erasure, or withdrawal request, and how quickly?

If the honest answer to any one of these is “we’d need to ask three teams and check some spreadsheets”, you have a workflow gap, not a policy gap. Here are the seven layers where that gap usually sits. 

The seven operational layers of DPDP consent readiness 

1. The consent notice

Rule 3 is more specific than most teams expect. The notice should be understandable independently of any other information, give a fair account in plain language, include an itemized description of the personal data and specified purposes with a specific description of the goods, services, or uses, and provide a link and means to withdraw consent as easily as it was given, exercise rights, and complain to the Board. 

Where it breaks: one generic privacy policy link covering every purpose, and notices with no version control.
What proof looks like: every notice is a versioned artifact, tied to a purpose, with a publication date and an owner.

2. The consent record’

This is the layer that most enterprises underbuild. A defensible record captures who consented, to which purpose, against which notice version, through which channel, at what time, and whether the consent has since been withdrawn. 

A terminology point matters here. A consent management platform you deploy is not the same as a Consent Manager under Rule 4. Rule 4 defines a distinct, Board-registered entity. To register, it must be an Indian company with a net worth of at least ₹2 crore, and it must also keep records of consent given, denied, or withdrawn for at least seven years. Your internal DPDP consent management workflow is your own responsibility either way. 

Where it breaks: consent stored as a checkbox value in a web form database, with no link to the notice shown.
What proof looks like: a queryable consent register with a full event history per person and purpose.

3. The access request

The Act provides Data Principals with rights of access, correction, updating, erasure, grievance redressal and nomination. Rule 14 requires you to publish the means of making a request and the identifiers needed to verify the requester, and to run a grievance redressal system that responds within a period not exceeding ninety days, supported by appropriate technical and organizational measures. Rule 9 adds that you must publish contact details of the person who can answer questions about processing. 

Where it breaks: requests arrive by email, WhatsApp, the call center, and the web form, and no one owns the clock.
What proof looks like: a single intake, an assigned owner, a running SLA timer, and a closure record.

4. Correction and deletion

Correction and erasure are where consent meets your system landscape. A withdrawal or erasure request has to reach the CRM, the ERP, file shares, email archives, marketing tools, and processors. Retention is more nuanced than “delete everything”. Rule 8(3) will require personal data, associated traffic data, and logs of processing to be retained for a minimum of one year for specified purposes, and the Rules also contemplate retention where other laws require it. For certain classes, such as large e-commerce, gaming, and social media platforms, Rule 8 also requires an erasure warning to the user at least forty-eight hours before the retention period ends. 

Where it breaks: deleting in the front-end system while copies persist in exports, spreadsheets, and vendor systems.
What proof looks like: a deletion task per system, each with a named owner and a confirmation.

5. The breach workflow

Rule7 sets two tracks. Affected individuals should be told without delay, with a description of the breach, its likely consequences, and mitigation measures and safety steps they can take, and a business contact. The Board must receive a description without delay, followed by detailed information within seventy-two hours of becoming aware of the breach, unless the Board allows a longer period. 

Where it breaks: incident response lives in the security team, while the notification drafts, customer lists, and approvals sit with legal, communications, and support.
What proof looks like: a rehearsed workflow with a 72-hour clock, pre-approved templates and a cross-functional approval chain.

6. System ownership

Rule 6 sets out what “reasonable security safeguards” means at a minimum. It covers encryption, masking or tokenization, access control, logs and monitoring to detect unauthorized access, backups, one-year retention of relevant logs, and appropriate contract provisions with Data Processors. None of that works if no one is accountable for each system that holds personal data. 

Where it breaks: shadow spreadsheets, orphaned SharePoint sites, departed employees’ file shares, and vendor systems no one reviews.
What proof looks like: a data inventory listing each system, its business owner, the personal data it holds, its retention rule, and its processor contracts.

7. Reporting

Regulators, boards, clients, and auditors will not read your workflows. They will read your reporting. Without a live view of consent coverage, open requests, SLA breaches, overdue deletions, and breach drills, the workflow exists but cannot be evidenced.

What proof looks like: a compliance dashboard the DPO or privacy lead can open on any day without preparing for it.

Where SharePoint, Power Automate, Power BI and Microsoft 365 governance fit

If your organization already runs on Microsoft 365, you may have more of this capability than you realize. The stack maps to the seven layers as follows:

Layer	Microsoft 365 / Power Platform approach
Consent notice	Versioned notice library in SharePoint with approval flows and published-version history
Consent record	Consent register built on SharePoint Lists or Dataverse, fed by Power Apps or web forms; Power Automate logs every grant and withdrawal as an event
Access request	Single intake form, with Power Automate routing to owners, approvals, reminders, and SLA escalation
Correction/deletion	A flow that fans out one erasure task per system owner, with confirmation tracking and retention-hold checks
Breach workflow	An incident flow with a 72-hour timer, templated notifications, and legal/comms/IT approvals in Teams
System ownership	Data inventory in SharePoint; Microsoft Purview sensitivity and retention labels, DLP policies, Entra access reviews
Reporting	Power BI dashboards on consent coverage, request aging, SLA compliance, and retention exceptions

Three practical notes make the difference between a good design and a fragile one. 

Choose the right store for consent volume. SharePoint Lists work well for governance registers, DSR trackers, and inventories. For high-volume consumer consent (millions of events), use Dataverse or a database as the system of record, and keep SharePoint as the governance and workflow layer. 

Check your log retention against Rule 6. The Rules call for a one-year log retention period. In Microsoft Purview, Audit (Standard) keeps records for 180 days by default, while Audit (Premium) retains Entra ID, Exchange, OneDrive, and SharePoint records for one year by default. One practitioner notes that Teams and Power Platform activity still default to 180 days unless you create custom retention policies. Confirm your licensing and set retention policies deliberately, rather than discovering the gap during an investigation.

Govern the Power Platform itself. An automated consent workflow that can let citizen developers copy personal data into unmanaged environments creates the problem you are trying to solve. Use environment strategy, DLP policies for connectors, and ownership rules from the start.

This stack does not make an organization compliant on its own. The Rules do not mandate any tool, and legal interpretation stays with your counsel. But it gives you a governed, auditable place to run the workflows, on the platform your teams already use.

DPDP Compliance Checklist for Indian Companies

Use this as a working checklist for your DPDP compliance workflow, in roughly this order:

Foundation (now to Nov 2026)

• Map personal-data flows across customer, employee, vendor, and marketing systems.
• Assign a business owner to every system holding personal data
• Define purposes and their processing basis (consent or a specified legitimate use)
• Assess whether you may fall into a Significant Data Fiduciary class
• Decide your consent record architecture and system of record

Build (Nov 2026 to Feb 2027)

• Redesign notices to meet Rule 3, with version control
• Build the consent register with grant, deny, and withdraw events
• Build one intake and tracking workflow for access, correction, erasure, and grievances
• Publish the Rule 9 contact point and Rule 14 request channels
• Define retention schedules and deletion triggers per data set
• Review and update processor, cloud, and vendor contracts against Rule 6

Prove (Feb to May 2027)

• Enable and test log retention against the one-year expectation
• Run a breach tabletop with the 72-hour Board clock
• Test end-to-end withdrawal: from request to deletion confirmation across systems
• Launch the compliance dashboard and set a review rhythm
• Check children’s data flows and verifiable parental consent, if applicable
• Re-check MeitY notifications for timeline or scope changes

From Privacy Policies to Proven Workflows 

The organizations that struggle in 2027 will not be the ones with weak privacy policies. They will be the ones whose consent records, request handling, and deletion trails cannot be reproduced on demand. Building those workflows takes months, and the runway is shorter than it looks.

Map your DPDP consent and data-rights workflow. Talk to Aufait Technologies about turning consent, access, deletion, and breach obligations into governed workflows on SharePoint, Power Automate, Power BI, and Microsoft 365.

Frequently Asked Questions