DPDPA Compliance in Practice: Obligations and  Breach Risk

Introduction

Understanding DPDPA in theory is one thing. Actually implementing it across your organisation is something else entirely.

In Part 1, we covered the foundation — what the law is, what personal data means, and how the three consent paths work. In this article, we go deeper into the parts of DPDPA that have the most direct operational impact: how consent decisions flow through your tech stack, the five legal obligations the law places on your business, your customers' enforceable rights, what a real data breach looks like, the penalty structure, and the phased roadmap you need to follow.

This is the implementation half of the guide.

Section 1: The Technical Architecture of Consent Management

Most businesses treat DPDPA as a legal problem. In practice, it is equally a technical one. A consent decision made by a user in a cookie banner must flow correctly through every layer of your technology stack in real time. If any layer fails to honour that decision even if your banner looks compliant you are non-compliant.

Layer 1 — Frontend (What Users See). This is where consent begins. The Cookie Banner (CMP Widget) must present all categories clearly, avoid pre-ticked boxes or dark patterns, and make "Reject All" as prominent as "Accept All." The Preference Centre linked in your footer is where users change or withdraw consent later. Google Tag Manager sits here too, acting as the gatekeeper that fires or blocks scripts based on live consent state.

Layer 2 — Consent API (What Stores Decisions). This layer is invisible to users but is the operational backbone of compliance. The Consent Management Database stores each user's preferences. The User Preference API writes those preferences in real time and signals changes downstream. The Consent Audit Log timestamped records of every acceptance, rejection, and withdrawal is your evidence if the DPBI investigates. The Data Retention Engine auto-deletes personal data when retention periods expire.

Layer 3 — Backend Systems (What Processes Data). Analytics tools must only fire when consent is granted. CRM platforms must have DSAR and unsubscribe flows built in. Data warehouses must enforce retention policies at the storage level. All third-party processors must have signed Data Processing Agreements.

The governing principle across all three layers: no layer can bypass the Consent API. Consent decisions must propagate downstream in real time, and every system in your stack must be configured to respect them.

How Data Flows — From Collection to Deletion

DPDPA applies at every stage of your data lifecycle. Collection begins the moment a form is submitted or a cookie fires. Consent must be captured at that point with a specific, stated purpose. Storage must be encrypted at rest and in transit, with role-based access controls. Processing must stay within the stated purpose data collected for order fulfilment cannot be used for marketing. Sharing with processors requires a DPA in place. Deletion must be automated and comprehensive not just the primary database, but backups, analytics tools, email platforms, and data warehouses.

Section 2: Consent Manager Registration — The November 2026 Deadline

One of the most significant new requirements under DPDP Rules 2025 is mandatory Consent Manager registration with the DPBI  and the deadline is November 2026. Many businesses have not yet planned for this.

A Consent Manager is a registered, DPBI-approved entity that acts as a single point of contact for users to give, manage, and withdraw consent across multiple platforms. Four requirements apply: it must be registered with the DPBI, it must be interoperable using standardised DPBI-approved protocols, it must provide users a single dashboard to view and withdraw all consents, and it must maintain complete audit trails available to the DPBI on request.

Your action plan is straightforward. Evaluate your current CMP vendor for DPBI eligibility now. Select and deploy a DPBI-eligible CMP by Q3 2026. Meet the registration deadline in November 2026. Then audit consent logs quarterly as an ongoing practice.

From November 2026, only DPBI-registered Consent Managers can legally fulfil consent obligations under DPDP Rules 2025. Operating without registration after that date is a direct violation.

Section 3: The 5 Core Legal Obligations

Every Data Fiduciary — any business that collects and processes personal data of Indian citizens has five legal obligations under DPDPA. These are not guidelines. They are requirements.

Obligation 1 — Get Clear Consent. Consent must be free, specific, and informed. "Free" means no coercion. "Specific" means you stated exactly what data you are collecting and why. "Informed" means the user had enough information to make a real decision. Pre-ticked boxes, consent buried in terms and conditions, and consent obtained as a condition of service access are all invalid.

Obligation 2 — Data Minimisation. Collect only what is genuinely necessary for the stated purpose. If you run a newsletter and collect a phone number you never use that is a violation. Every data collection form, API payload, and analytics event in your product needs to be audited for necessity.

Obligation 3 — Purpose Limitation. Data collected for one purpose cannot be used for another without fresh consent. Purchase history collected for order fulfilment cannot feed a personalisation engine without specific consent. Registration data collected for service delivery cannot build a marketing audience. Every new use requires a new specific consent.

Obligation 4 — Data Security. Section 8(5) requires "reasonable security safeguards" to prevent personal data breaches. In practice this means encryption at rest and in transit, role-based access controls, audit logging of all access events, regular vulnerability assessments, and a documented incident response plan. This provision carries the highest penalty in DPDPA ₹250 Crore and is where technical security controls have the most direct compliance value.

Obligation 5 — Data Erasure. When a purpose is fulfilled, when consent is withdrawn, or when a user requests deletion you must delete the data. Not archive it, not anonymise it. Delete it across all systems. Manual erasure processes will fail at scale. Automated retention policies and deletion pipelines are the only reliable approach.

Section 4: Your Customers' Rights Under DPDPA

DPDPA does not just place obligations on businesses. It grants six specific, enforceable rights to individuals, and you are legally required to fulfil them.

The Right to Access allows a user to ask what personal data you hold about them and why. The Right to Correction allows them to demand that inaccurate or outdated information be fixed across all systems. The Right to Erasure the "Right to be Forgotten" requires deletion across every system where that data exists, not just the primary database. The Right to Withdraw Consent must be as simple as giving consent in the first place  if acceptance required one click, withdrawal cannot require five menus. The Right to Grievance Redressal allows users to file complaints with your DPO and then directly with the DPBI no regulator needs to initiate proceedings on their behalf. The Right to Nominate allows users to appoint someone to exercise their data rights on their behalf, for example in the event of death or incapacitation. This provision has no direct equivalent in GDPR.

Operationalising these rights requires a DSAR pipeline a system for receiving requests, verifying identities, locating data across all systems, fulfilling requests within required timeframes, and logging every transaction for compliance purposes.

Section 5: Significant Data Fiduciaries and Children's Data

Not all Data Fiduciaries carry identical obligations. The Central Government can classify certain businesses as Significant Data Fiduciaries (SDFs) based on the scale or sensitivity of data they handle large volumes of personal data, sensitive categories like health or financial data, platforms with national security implications, or platforms influencing democratic discourse.

SDFs face four additional requirements: a Data Protection Officer based in India, periodic Data Protection Impact Assessments, mandatory algorithmic audits of automated decision-making systems, and stricter cross-border transfer controls. International data transfers are only permitted to countries the Central Government has notified as approved. If you use global SaaS platforms AWS, Google Cloud, Salesforce  assess whether their data residency options and contractual safeguards are adequate.

Children's data carries the strictest protections in DPDPA. Anyone under 18 is a child stricter than GDPR's threshold of 16 in most European jurisdictions. Three absolute rules apply: verifiable parental consent is required before collecting any data from a child (not a checkbox verified consent), behavioural tracking of children is prohibited entirely, and targeted advertising based on personal data directed at under-18s is explicitly prohibited. The penalty for violations involving children's data is up to ₹200 Crore. "We didn't know they were a child" is not a defence age verification is your responsibility.

Section 6: What a Data Breach Looks Like — and What It Costs

Most people picture a breach as a sophisticated cyberattack. The reality under DPDPA is more common and more preventable. A wrong email recipient — an employee accidentally sends a customer spreadsheet to the wrong person — is a breach. A vendor compromise — an analytics platform or CRM you use gets hacked and your data is exposed — is a breach and you are liable. A misconfigured database left publicly accessible for hours is a breach. A ransomware attack that exfiltrates data before you can respond is a breach.

In every scenario, you must notify both the DPBI and affected users promptly. Failure to notify is a separate violation carrying up to ₹200 Crore, on top of the original breach penalty.

DPDPA's penalty structure by violation type:

Penalties are cumulative. A single incident could attract multiple categories simultaneously.

For prioritisation: fix the absence of a cookie consent banner and privacy policy immediately — these are the first items a DPBI investigation examines. Address a missing breach response plan and absent vendor DPAs within 30 days. A missing data retention policy and DPO appointment (if you are an SDF) should be resolved within 90 days.

Section 7: Where to Implement and Your Action Roadmap

DPDPA compliance touches every function in your organisation that handles personal data. On your website: cookie consent banner, privacy policy, preference centre link in the footer, and purpose disclosure on all forms. In your mobile app: launch consent screen, push notification opt-in, location permission explanation, and in-app privacy settings. In your email and CRM: unsubscribe in every email, consent at sign-up, re-consent for new purposes, and DND registry compliance. In your backend APIs: consent check before every data write, DSAR pipeline, right-to-delete automation, and retention scheduler. In engineering: no PII in logs, encryption at rest and in transit, DPIA before new data features, and DPA requirements in processor contracts. In your organisation: appoint a DPO, run employee training, sign vendor DPAs, and build a breach response runbook before you need it.

The compliance roadmap aligns to the actual enforcement timeline:

Phase 1 — Now. The DPBI is operational. Map all personal data you collect, appoint an internal data champion, audit existing consent mechanisms, and review vendor DPAs.

Phase 2 — By November 2026. Select a DPBI-eligible CMP, deploy certified consent management across all platforms, implement withdrawal flows, and finalise all vendor DPAs.

Phase 3 — By May 2027. All substantive obligations must be fully operational. DSAR pipeline tested and live. DPO appointed if you are an SDF. Algorithmic audits completed.

Ongoing. Quarterly compliance audits. Annual DPIA refresh. Annual breach response drills. Monitor the approved country list for cross-border transfers.

Section 8: How COSGrid Helps You Meet Section 8(5)

The highest-penalty provision in DPDPA — Section 8(5)'s requirement for "reasonable security safeguards" — is fundamentally a technical problem that demands the right security infrastructure across access controls, network, and endpoints.

MicroZAccess (Zero Trust Network Access) enforces identity-verified, least-privilege access to every data system only the right person, on the right device, under the right conditions, can reach personal data. Every access is logged, creating the audit trail DPDPA requires. 83% of data breaches involve compromised credentials. MicroZAccess eliminates that as an entry point.

COSGrid Network Security (Threat Detection and Segmentation) applies network micro-segmentation so that even if one system is compromised, an attacker cannot move laterally to your customer database. Real-time detection and automated containment stop exfiltration before it completes. SOC-ready audit logs satisfy DPBI reporting requirements.

Device Management (Endpoint Data Protection) enforces encryption on all company devices, enables remote wipe for lost or stolen devices containing personal data, and applies DLP policies that prevent bulk data exfiltration. 68% of data breaches originate at endpoints this is the layer most organisations underinvest in until after an incident.

Conclusion

DPDPA compliance is not a one-time project. It is an ongoing organisational capability  the ability to collect data with genuine consent, process it within stated purposes, protect it with appropriate security controls, fulfil user rights when exercised, and respond effectively when something goes wrong.

The organisations that build this capability now will carry it as a competitive advantage not just a compliance status. In a market where data breaches are public events and consumer trust is hard to rebuild, demonstrating responsible data practices is a differentiator.

The DPBI is operational. The enforcement clock is running. Start with the critical gaps and build towards the full roadmap.