A Cybersecurity Consulting Perspective on the Gap Between Buying Software and Building Compliance
Walk into any procurement conversation about the Digital Personal Data Protection Act, 2023 today, and you'll notice a pattern. Data loss prevention platforms are being pitched as DPDP solutions. Consent management software is marketed as compliance-in-a-box. Data discovery tools promise to "make you DPDP-ready" in weeks. The market has quietly reframed a legal and governance obligation as a procurement decision.
It isn't one. DPDP is a governance and legal obligation before it is anything else — and tools, however sophisticated, support compliance. They do not create it. An organization can deploy every category of privacy technology on the market and still have no valid lawful basis for the data it holds, no signed Data Processing Agreements with its vendors, and no functioning process to respond when a customer asks to have their data deleted. That gap — not the absence of software — is where most DPDP exposure actually lives.
Why the "Buy a Tool" Narrative Took Hold
This isn't a conspiracy; it's a natural consequence of how markets respond to regulation. IT vendors describe new laws in the language they already sell in, and a data protection statute understandably gets translated into a DLP opportunity, a consent-platform opportunity, a data-discovery opportunity. None of this is dishonest. But it creates a category error that leadership teams are absorbing at scale: the belief that compliance is something you purchase rather than something you build.
KPMG's own national leadership has flagged this exact gap publicly. Akhilesh Tuteja, speaking on India's DPDP readiness, observed that while large corporations may be technically prepared for the new rules, the wider ecosystem of partners, vendors, and suppliers often is not — and that this represents one of the most significant holes in the country's overall readiness. That's a governance and relationship problem, not a licensing shortfall. No dashboard fixes an ecosystem that hasn't yet understood what the law requires of it.
What Tools Can Actually Do
To be fair to the vendors in this space, the tools themselves solve real problems. Data discovery platforms genuinely help organizations locate personal data scattered across systems — a foundational step, since you cannot govern what you cannot find. Consent management platforms can capture and log consent efficiently, at scale, in a way manual processes cannot. DLP tools can flag and block unauthorized data movement in real time.
These are legitimate enablers of execution. What they are not is a source of legal legitimacy. A consent platform can record that a checkbox was ticked — it cannot determine whether the purpose behind that data collection was lawful, proportionate, or properly disclosed in the first place. That determination is a legal and governance judgment, made by people, before any technology touches it.
The Governance Layer No Tool Can Substitute For
According to KPMG's published breakdown of the DPDP Act and Rules, 2025, organizational readiness rests on four core pillars — and none of them can be purchased off a shelf:
* A governance framework — a formal structure for oversight, control, escalation, and reporting, owned by leadership rather than embedded in a system configuration.
* A privacy team — a cross-functional group spanning legal, IT, and HR/security, coordinating implementation across the organization rather than sitting inside a single department.
* A Data Protection Officer — a mandatory, independent function for Significant Data Fiduciaries under the Rules. A DPO is a role with accountability, not a feature toggle.
* Updated policies — privacy, retention, and breach-response policies that must be legally sound and operationally enforced, not auto-generated by a platform and left unread.
Each of these pillars requires human judgment, legal interpretation, and organizational buy-in. A platform can help operationalize a retention policy once it exists. It cannot write that policy, decide what "purpose fulfilled" means for a given data category, or negotiate a Data Processing Agreement with a vendor. That work sits squarely in the governance layer — the layer most "DPDP-ready" software quietly assumes someone else has already built.
The Ecosystem Problem Makes This Worse, Not Better
DPDP accountability doesn't stop at an organization's own walls. Under the Act, fiduciaries remain accountable for how their processors and vendors handle personal data on their behalf — which means an organization's compliance posture is only as strong as the weakest partner in its data supply chain.
This is precisely the gap KPMG's leadership pointed to: large enterprises may have the budget and internal maturity to build governance frameworks, but the smaller partners, suppliers, and vendors they depend on frequently haven't started at all. Educating and contractually binding an entire ecosystem to DPDP-consistent obligations takes months of sustained legal and relationship work — reviewing contracts, negotiating DPA clauses, training partner teams on what "purpose limitation" actually means in practice. No enterprise software license accelerates that timeline. It is, fundamentally, a governance and change-management exercise conducted one vendor relationship at a time.
A Familiar Illusion, Wearing a Different Disguise
Picture an organization that has done everything the market told it to do. It has licensed a leading consent management platform. It has deployed a data discovery tool that maps personal data across its systems. Its compliance dashboard shows green across the board.
Now ask three questions. Has the organization mapped a lawful basis for every category of personal data it processes? Has it appointed a Data Protection Officer, where required, with real authority and independence? Has it signed Data Processing Agreements with every vendor and processor that touches that data?
If the answer to any of these is no, the organization is not DPDP-compliant — regardless of how advanced its technology stack looks. This is the same underlying lesson that surfaces whenever compliance gets treated as an infrastructure purchase rather than an accountability structure: sophisticated tooling can create the appearance of readiness while the legal foundation underneath remains unbuilt.
What Getting This Right Actually Looks Like
The correct sequence reverses what most vendors are currently selling. Governance comes first. Technology comes second, as an accelerant — not a substitute.
In practice, that means: establishing the governance structure and assigning real ownership — a privacy team, a DPO where the Act requires one — before evaluating any platform. Mapping lawful basis and consent requirements across every category of data the organization holds, which is a legal and business exercise, not a technical one. Building retention and breach-response policies as living governance documents, reviewed and owned by leadership rather than generated once and forgotten. Extending accountability contractually to every vendor and processor in the data supply chain through properly negotiated DPAs. Only once this foundation exists does it make sense to select tools — and at that point, the right tools genuinely accelerate and scale a governance model that already works, rather than papering over one that doesn't.
Closing Thought
None of this is an argument against the technology itself. Data discovery, consent management, and DLP platforms are valuable, and organizations that eventually deploy them well will move faster and more reliably than those that don't. The risk isn't the tool. It's the sequencing — buying the software before doing the governance work it was built to support.
DPDP was written as a law about accountability, not architecture. Organizations that internalize that distinction early will build compliance that actually holds up under scrutiny. Those that don't will discover, likely at the worst possible moment, that a fully licensed platform and a fully compliant organization are not the same thing.
