Your privacy policy won’t save you. Neither will your firewall.

If the first sentence made your IT head nod and the second made your general counsel bristle, you have already found the problem. India’s compliance industry has split the Digital Personal Data Protection Act, 2023 down the middle, and each half believes it is holding the whole.

The Digital Personal Data Protection Rules, 2025 were notified in November 2025. The Data Protection Board of India is constituted. The Act’s substantive obligations on Data Fiduciaries take effect in May 2027. The runway is real, but it is shorter than most boards think, and the split between law and technology is about to become expensive.

Two camps, one blind spot

Walk into most DPDP engagements and you will meet two teams that rarely share a meeting room. The first is legal. Its instinct is to draft. The privacy policy is revised, notices are rewritten, consent clauses are tightened, and data processing agreements go out to every vendor. By the end of the quarter there is a handsome binder, and a sense that the organisation is compliant.

The second is technical. Its instinct is to deploy. The ISO/IEC 27001 certificate is renewed, multi-factor authentication is enforced, a data loss prevention tool is licensed, and endpoints are encrypted. By the end of the quarter there is a dashboard full of green, and a sense that the organisation is secure.

Both teams are competent and sincere. Both are also describing an organisation that does not quite exist.

Paper without plumbing, plumbing without purpose

Consider the policy that promises personal data will be erased once its purpose is served. It faithfully restates the Act. It is also a fiction if nobody has configured a single retention rule in the CRM, the ERP or the email archive. A promise the systems cannot keep is not a compliance artefact. It is evidence against you.

Now consider the reverse. A company encrypts everything, logs everything and clears its surveillance audit. Yet nobody can say why it still holds identity documents of candidates it rejected six years ago, or on what basis marketing is messaging a list bought from an event organiser. The encryption is protecting data the organisation should no longer hold. The firewall is guarding a warehouse no one has inventoried.

No tool answers that question. Neither does a template.

What the law is actually asking for

Read the DPDP Act as a whole and it is striking how little of it concerns documents ortechnology on their own. It is about conduct.

A notice must tell people what is being collected and why. Consent must be free, specific, informed, unconditional and unambiguous, signalled by a clear affirmative act, and as easy to withdraw as it was to give. Processing must stay within the purpose for which the data was obtained. Data must be erased when that purpose is no longer served. There must be a grievance mechanism that actually works, because a Data Principal is expected to exhaust it before approaching the Board. And the Data Fiduciary remains answerable for compliance even when a Data Processor does the work on its behalf.

Then there is the duty to take reasonable security safeguards to prevent a personal data breach. It is the provision technologists quote most often, and the one that carries the heaviest penalty in the Schedule to the Act: up to ₹250 crore. The Rules give it substance through encryption, masking or tokenisation, access controls, logging and monitoring, and the retention of logs so that a breach can be detected, investigated and remediated.

Look closely at that list. Access control is a technical setting that depends on an HR decision about roles. Log retention is an IT configuration that depends on a legal judgement about what must be kept, and for how long. Even the most technical obligation in the Act cannot be discharged by one function alone.

Where compliance actually breaks

Theory is tidy. Implementation is not. Consider a few composite scenes from real projects.

HR moves onboarding to Darwinbox. The platform is capable; the configuration is not. Every manager can see the emergency contacts and family details of an entire department. Background verification reports, shared with a vendor for a single check, sit in a shared folder indefinitely. Meanwhile HR has circulated consent forms for processing the Act already permits as a legitimate use for purposes of employment. In doing so, it has created a withdrawal right the business never needed to offer and cannot operationally honour.

Finance runs SAP. The customer and vendor masters are copied into development and test environments so an integration partner can troubleshoot. Production data, unmasked, now lives in three places, one of them accessible to a third party whose contract predates the Act and says nothing about deletion.

Marketing runs on WhatsApp. Not the Business API, but personal numbers on personal phones, with broadcast lists built from visiting cards and trade-fair scans. When a customer asks to be removed, there is no system to remove them from. There is only a phone in a salesperson’s pocket.

Freelancers and consultants work on their own laptops, outside device management. They download customer exports to finish a campaign over the weekend. When the engagement ends, the data stays behind.

Beneath all of it lies the spreadsheet: customer data spread across forty-odd Excel files, emailed between branches, renamed “final_v3_updated”, and owned by no one.

A better policy will not fix any of these problems, and neither will a better tool. Each is fixed only when a lawyer, a system administrator and a business owner sit in the same room, decide what should happen, and then make it happen.

The seventy-two-hour test

Nothing exposes the divide faster than a personal data breach.

The Rules require a Data Fiduciary to inform the Board and each affected Data Principal without delay, and to furnish a detailed report to the Board within seventy-two hours of becoming aware of the breach, or such longer period as the Board may allow. That report must explain what happened, what was done to contain it, and what will prevent a recurrence.

Think about what that demands at two o’clock in the morning. The security team can tell you which server was accessed. It usually cannot tell you whose data sat on it, in what capacity, or under which notice it was collected. The legal team can draft the intimation. It usually cannot tell you whether the logs will support a word of it. The organisation that has never rehearsed this conversation will have it for the first time under a statutory clock.

A breach response plan that has never been tested jointly by legal, IT, communications and the business is not a plan. It is a hope with a version number.

The boardroom illusion

Why does this persist? Because boards are sold compliance in the form that is easiest to buy.

A policy suite has a price and a delivery date. A consent management platform has a licence feeand a go- live date. Both give the CEO something to point to. Neither requires the uncomfortable admission that the organisation does not know where its personal data lives.

The board’s question should not be “Have we bought DPDP compliance?” It should be: “If a Data Principal asked us tomorrow what we hold about them, could we answer within the prescribed time, and could we prove it?” Most organisations cannot. An honest answer to that question is worth more than any certificate on the reception wall.

From function to capability

The way forward is not to hand privacy to legal or to IT. It is to stop treating privacy as a function at all.

Privacy has to become an organisational capability, as financial controls already are. Nobody believes accounting integrity belongs to the finance team alone. Procurement, sales and operations all touch it, and internal audit tests the whole chain. Personal data deserves the same treatment. In practice, that means:

▪ a data inventory built with business owners rather than for them;

▪ retention schedules written by lawyers and enforced in systems;

▪ vendor contracts that reflect what vendors actually do with the data;

▪ grievance handling and breach response rehearsed like a fire drill;

▪ training for the HR executive and the sales manager, not only the IT team; and

▪ a named senior executive accountable for whether it all holds together.

None of this requires an army. For a mid-sized Indian enterprise or an MSME, it requires clarity about ownership, a handful of well-configured controls, and the discipline to review them. The cost of that discipline is modest. The cost of its absence is not.

It also means lawyers learning how an API moves data, and engineers learning why purpose limitation matters. The most valuable DPDP practitioners of the next decade will be bilingual, fluent in both the statute and the stack.

The uncomfortable truth

When the Data Protection Board examines a breach, your privacy policy will not be the first thing it wants to see, and your firewall will not impress it. It will ask what happened to the data, who decided, and whether the organisation did what it said it would do.

Your privacy policy won’t save you. Neither will your firewall.

What will save you is an organisation that knows what it holds, why it holds it, and when it will let go.

- Author is the Head & Principal Consultant – Data Protection & Compliance at Silicon Comnet Private Limited, where he leads DPDP Act implementation engagements for enterprises across manufacturing, technology and services. He is an Advocate enrolled with the Bar Council of Delhi and holds the CIPP/E, DCPP, and ISO/IEC 27001, 27701 and 42001 credentials.