Imagine the Data Protection Board of India has received a complaint. An individual claims your organisation collected their personal data without clear consent, used it beyond the stated purpose, and did not respond when they asked for it to be deleted.
The Board's investigators are not interested in your intentions. They are interested in your evidence. Your consent records. Your data processing logs. Your rights request an audit trail. Your vendor contracts. Your breach response documentation.
Can your organisation produce any of it — accurately, completely, and immediately?
For most Indian businesses, the honest answer is no. And that answer, when given to a regulator, carries a penalty of up to INR 250 crore per violation. The DPDP Act does not grade on effort. It grades on outcomes.
Here is what your organisation needs to have in place — not eventually, but now.
The Invisible Data Problem
Every organisation collects personal data. Very few organisations truly know what they have collected, where it currently lives, who can access it, and why it was originally gathered.
Personal data in most Indian organisations is not in one place. It is distributed across CRM systems, marketing platforms, HR databases, cloud storage, email threads, WhatsApp groups used for customer communication, spreadsheets maintained by individual teams, and dozens of third-party applications that were integrated into operations without a formal data review. Each of these is a separate compliance exposure point. Each represents data that the DPDP Act now governs.
The Act requires that personal data be processed only for the purpose for which consent was obtained, retained only as long as necessary to fulfil that purpose, and deleted once the purpose has been served. None of these obligations can be met without first knowing what data exists, where it is, and why it is there.
This is what a data inventory is — and it is the single most important exercise any organisation can complete before any other compliance work begins. Without it, consent notices are incomplete. Rights requests cannot be fulfilled accurately. Breach notifications cannot identify what was affected. Vendor contracts cannot specify what is being processed. The data inventory is not one item on a compliance checklist. It is the foundation on which every other item depends.
Section 8(3) of the DPDP Act requires that personal data be erased as soon as it is reasonable to assume the purpose has been served. Without a mapped inventory, an organisation cannot know when that moment arrives — or demonstrate to a regulator that it acted on it.
Consent That Cannot Be Proved Is Consent That Does Not Exist
The DPDP Act places consent at the centre of every data processing relationship. But consent, under the Act, is not a moment — it is a record. It must be specific to each processing purpose, documented with a verifiable timestamp, linked to the exact notice the individual received at the time, and withdrawable at any point through a mechanism that is as simple as the original consent request.
This is where the gap between what most organisations believe they have and what the Act actually requires becomes stark.
A pre-ticked box is not consent. A bundled "I agree to our terms and privacy policy" is not consent. A verbal agreement over a customer service call that was never recorded is not consent. Under the DPDP Act, these are not minor procedural failures. They are the absence of a lawful basis for processing — which means every subsequent use of that data, however well-intentioned, is a violation.
Every organisation that collects personal data is a Data Fiduciary — and the consent obligations that come with that designation are more demanding than most have prepared for. Consent must be collected separately for each processing purpose, documented with a verifiable timestamp, linked to the exact notice the individual received, and withdrawable at any point through a mechanism as simple as the original consent request. That withdrawal must be acted upon — promptly, completely, and across every system where that individual's data exists. A consent record that cannot be produced on demand is legally equivalent to no consent at all.
For organisations collecting data across multiple touchpoints — websites, apps, offline forms digitised later, customer service interactions — building a consent architecture that is accurate, auditable, and operationally maintainable is not a legal formality. It is a technical and governance infrastructure project that must be treated as one.
Treating consent as a legal formality handled once at the point of registration and never revisited is the single most common compliance misconception in the market today. Consent is a living record that your organisation must maintain, update, and be able to present on demand.
Your Vendors Are Your Liability
One of the least discussed — and most significant — provisions of the DPDP Act concerns third-party processors.
Under Section 8(2) of the Act, a Data Fiduciary may engage a Data Processor only under a valid contract. Rule 6 of the DPDP Rules 2025 specifies that this contract must mandate equivalent security safeguards to those the Fiduciary itself applies. A standard Master Service Agreement or vendor onboarding contract does not satisfy this requirement. A Data Processing Agreement — specific, comprehensive, and legally aligned with the DPDP Act — must exist for every vendor that touches personal data on your organisation's behalf.
Consider how many vendors that includes in a typical Indian business. The cloud provider hosting your application. The payroll platform processing employee data. The CRM tool your sales team uses. The analytics service tracking user behaviour on your website. The email marketing platform managing your customer communications. The customer support software handling grievance requests. Each of these is a Data Processor under the Act. Each requires a valid, DPDP-compliant Data Processing Agreement. Each represents a liability that sits with your organisation — not with the vendor — if something goes wrong.
Under the DPDP Act, responsibility cannot be transferred to vendors. It remains with the organisation that originally collected the data. A breach at a processor's end, without a valid DPA in place, leaves the Data Fiduciary with no contractual recourse and full statutory penalty exposure. Enterprise clients — particularly those in regulated sectors like BFSI and healthcare — are already beginning to require DPDP-compliant DPAs as a condition of vendor onboarding. Compliance with this provision is rapidly becoming a commercial requirement, not only a regulatory one.
Rights Are Not Requests — They Are Obligations
When an individual exercises their rights under the DPDP Act, your organisation does not have the option of deciding whether to respond. The right to access personal data, the right to correction, the right to erasure, the right to grievance redressal, and the right to nominate a representative are legally enforceable entitlements. Non-response, delayed response, or inadequate response each carries regulatory consequence.
The operational requirements behind rights fulfilment are more demanding than most organisations have planned for. Erasure requests must be completed within seven days — across every system, database, backup, and third-party integration where the individual's data exists. A grievance officer must be publicly designated and reachable — their contact details published on your platform. If a grievance is not resolved to the individual's satisfaction, they have the right to escalate directly to the Data Protection Board. The Board then investigates — and your organisation must be able to demonstrate both that the request was received and that it was handled correctly.
Organisations that treat rights requests as a customer service function — managed informally by whoever is available — will find that informal management produces inconsistent outcomes that cannot withstand regulatory scrutiny. Rights management is a compliance function. It requires a defined intake process, documented response timelines, a clear escalation path, and an audit trail that proves every request was handled within the required window.
Privacy Without Ownership Is Policy Without Practice
Every compliance program that has failed, has failed for the same reason: it belonged to everyone in principle and to no one in practice.
The DPDP Act does not name a single function as the owner of data privacy. It holds the organisation — as a Data Fiduciary — accountable as a whole. But accountability without designated ownership is an aspiration, not a governance structure. Marketing determines how consent is obtained. HR manages employee personal data with its own compliance requirements. Procurement negotiates vendor contracts that must now contain DPDP-specific clauses. Product teams build the systems through which data flows. IT manages the infrastructure where data is stored. Each of these functions generates compliance obligations daily — and none of them can meet those obligations without understanding what the Act requires of them specifically.
For Significant Data Fiduciaries — entities that will be designated by the Central Government based on data volume, sensitivity, and systemic risk — a Data Protection Officer must be appointed, India-based, reporting directly to the Board of Directors. Non-appointment where required carries a penalty of up to INR 150 crore. For all other organisations, a publicly accessible grievance officer is mandatory — making designated privacy ownership a universal requirement under the Act.
The organisations building genuine compliance are those where privacy ownership has been assigned, resourced, and connected across functions. Where the legal team, the IT team, the product team, and the business leadership are working from the same compliance roadmap. Where privacy is not reviewed annually in a policy document but managed continuously as an operational discipline.
The Window Is Defined. The Work Is Not Optional.
Three dates govern the DPDP compliance timeline, and each carries distinct operational requirements.
November 13, 2025 — the Data Protection Board was constituted and the penalty framework became legally active. November 13, 2026 — the Consent Manager framework activates, requiring all consumer-facing platforms to be API-compatible with registered Consent Managers. May 13, 2027 — full substantive enforcement of every obligation under the Act begins, with no grace period.
Between now and May 2027, the work that must be completed includes a comprehensive data inventory, a rebuilt consent architecture, DPDP-compliant Data Processing Agreements with every relevant vendor, operational rights management workflows, a tested breach response protocol, and designated privacy ownership with clear cross-functional accountability.
That is not a small programme. It is not a legal project that can be delegated and forgotten. It is an organisational transformation that touches every team, every system, and every external relationship involving personal data.
The regulator is not waiting for your organisation to be ready. It is waiting for the enforcement clock to reach the date that has already been set.
The question is not whether your organisation will be compliant by May 2027. The question is whether the work you start today leaves enough time to make compliance real — rather than documented, presented, and ultimately insufficient when the knock on the door arrives.
