Will DPDPA be another compliance burden, or can Indian businesses make it a culture?

A question that comes up at almost every DPDP conversation I have with Indian executives is some version of: “Is this just going to be another compliance burden?” The question is usually asked in a particular tone — slightly weary, slightly resigned, the tone of someone who has been through the GDPR readiness cycle, the SOX audit cycle, the ISO 27001 certification cycle, the RBI master direction cycle, and is now bracing for one more line item on the same page.

I want to take that question seriously, because the framing matters. If you walk into the DPDP work believing it's a burden, you will produce burden-shaped artifacts: a privacy notice that nobody reads, a consent banner that nobody changes, an annual e-learning module that nobody remembers, a quarterly compliance report that nobody acts on. Burden-framed compliance is real work that produces no real change. It is the worst kind of waste because it costs the same as the alternative but produces almost none of the benefit.

The other framing — the one I want to make the case for — is that DPDPA is a cultural opportunity. Not in the corporate-poster sense of “our values”, but in the operational sense of how Indian organisations make daily decisions about data. The organisations that get the cultural reframing right will outperform the ones that don't, and the gap will be visible by 2028.

Let me try to make this argument concretely.

What “culture” actually means here

I want to be careful with the word culture, because it gets used in vague ways that don't help anyone. When I say “DPDP as a culture rather than a burden”, I mean something specific. I mean five things:

1. Privacy is treated as a default in product decisions, not a check at the end. When a product manager scopes a new feature, the question “what personal data does this collect and why?” is asked at the same time as “what's the user value?”. Not after the design is locked. Not after the pilot. At the same time. The privacy work is part of the product work, not an annotation on top of it.

2. The grievance inbox is treated as a signal source, not a paperwork problem. When a Data Principal writes in to complain about how their data is being used, the response is not “close the ticket within SLA”. The response is “why did this person feel they needed to write in? What in our product or process produced that grievance? What do we change?”. The grievance becomes a product feedback loop, not a compliance metric.

3. The DPO has authority to slow down a launch. When the DPO walks into a product review and says “this can't ship in its current form because of [specific privacy concern]”, the room takes that seriously. The DPO is not overruled by the Head of Product or the Head of Marketing on volume considerations. Their voice has weight equal to the security team's voice and the legal team's voice. When the room decides to ship anyway, that decision is documented with the DPO's specific objection and the executive override, so the audit trail is honest.

4. Data minimisation becomes a product virtue, not a tax. Engineering teams take pride in collecting less data when they can. The team that figures out how to deliver the same feature with half the personal data fields is celebrated, not asked “why did you remove that — what if we need it later?”. The cultural posture is “we collect what we need and no more”, not “we collect everything in case it becomes useful”.

5. The audit trail is treated as a public document. Even though the audit trail will only be seen by the regulator (and maybe never), the team writes it as if a curious Data Principal will read it next year. Plain language. Honest decisions. Specific reasons. The instinct to write evasive, lawyer-defensive entries is replaced with the instinct to write entries that would survive being printed in a newspaper.

That's what I mean by culture. Not a values poster. Five operating habits.

Why these five habits matter

Each of those five habits, taken alone, is small. The compounding effect is enormous, and the reason is that each one closes off a class of failure modes that compliance theatre cannot.

Habit 1 — privacy as a default in product decisions — closes off the failure mode where you discover, six weeks before launch, that your beautiful new feature processes data in a way that requires fresh consent and a new privacy notice. The retrofit is always more expensive than getting it right at design time. Organisations with this habit ship slightly slower upfront and dramatically faster at the seam.

Habit 2 — grievance as signal — closes off the failure mode where you fix one grievance, ten more arrive that look the same, and you treat them all as individual incidents instead of recognising the pattern. The Data Protection Board's case docket will be full of organisations that received fifty similar grievances over a quarter, fixed each one individually, and never asked what was producing them. The organisations that read grievances as product feedback will catch the pattern after the third or fourth one.

Habit 3 — DPO with authority — closes off the failure mode where the DPO is technically present but functionally ignored. This is the failure mode I see most often in mid-sized Indian organisations. The DPO has been appointed because Section 10 (or commercial pressure) required it, but they sit two levels below the Head of Product and they have no veto power. When the launch deadline comes, the DPO's concerns are politely heard and politely overruled. By the time the regulator asks “who reviewed this?”, the DPO's name is on the document but their actual influence on the design was zero. The audit trail looks fine; the underlying decision was made without them.

Habit 4 — data minimisation as virtue — closes off the failure mode where every system in the organisation slowly accumulates more personal data fields than it actually needs, because nobody ever wants to be the person who deleted a field that turned out to be useful. After ten years of this drift, the organisation is sitting on a data trove that has no clear owner, no clear purpose, and no clear retention policy — and that data trove is the most likely thing to become a Section 8(5) penalty event when it's eventually breached.

Habit 5 — audit trail as public document — closes off the failure mode where the trail technically exists but is so evasive and lawyer-defensive that it actively hurts the organisation when a regulator reads it. I've seen audit trails that read like a defendant's deposition: vague, hedged, full of passive voice. When a regulator reads that, they conclude the organisation has something to hide, and the penalty calculation moves in the wrong direction. An honest audit trail — one that says “we considered X, we decided Y, here's why” in plain language — produces a much better outcome even if the underlying decision was the same.

The cost of doing it culturally vs. doing it as a burden

Here's the part I'm most insistent about. Doing DPDP as a culture is not more expensive than doing it as a burden. It costs roughly the same in spending, takes roughly the same number of person-hours, and requires roughly the same set of tools. The difference is entirely in posture.

Compliance theatre and cultural compliance have similar budgets. They have similar policy stacks. They have similar audit calendars. The difference is whether the people doing the work are trying to understand what good privacy looks like or trying to paper over the absence of it. That difference is invisible in the budget. It is visible everywhere else.

I'll give you a concrete example from a project I worked on last year. Two Indian fintech companies, similar size, similar customer base, similar product. Both signed up for the same DPDP readiness work in the same quarter. Both had similar starting postures (which is to say, weak). Both ended the quarter with a complete set of DPDP artifacts: privacy notices, consent records, DSR workflow, breach runbook, vendor inventory, the lot.

Six months later, they look completely different. Company A — the one that treated the work as a checkbox — now has a privacy notice that nobody is updating, a DSR workflow that handled three requests in six months, a breach runbook that hasn't been drilled, and a vendor inventory that hasn't been updated since the project ended. Their DPO sends a quarterly report that nobody reads. The whole thing has decayed quietly into a folder of old documents.

Company B — the one that treated the same work as a culture shift — has a privacy notice that has been updated four times to reflect new processing activities, a DSR workflow that handles dozens of requests per month with a 95% on-time response rate, a breach runbook that has been drilled twice (one of the drills caught a real configuration error that turned out to be exploitable), a vendor inventory that flags new vendors at procurement time, and a DPO who sits in product reviews and has actually blocked a launch. Their last quarterly report was discussed at the board level and produced two specific decisions about data minimisation in the existing product.

The two companies spent roughly the same amount on privacy work. Company A's cost per real privacy improvement was effectively infinite. Company B's cost per real privacy improvement was a fraction of the budget. The difference was not money. It was framing.

How an Indian organisation actually makes the cultural shift

I want to end with the practical part, because the abstract argument is easy and the operational shift is hard. Here is what the cultural shift looks like in practice, in the order I'd recommend doing it.

Step 1 — Name the owner publicly. Pick a person, give them the title (DPO or Privacy Lead), announce internally that this person owns DPDP, and make them report directly into the C-suite. The reporting line is the key part. If they report into the General Counsel or the CISO, they will be subordinated to the priorities of whoever they report to. If they report into the CEO or the COO, they have enough air-cover to push back.

Step 2 — Add a privacy gate to product launches. The gate is one question on the existing launch checklist: “has the DPO signed off on the data flows for this feature?”. The answer must be yes before the feature ships. This single change shifts the cultural posture from “privacy is something we deal with at the end” to “privacy is something we deal with at the start”.

Step 3 — Read every grievance, personally, for the first quarter. The DPO should personally read every grievance that comes in for the first three months. Yes, every one. The point is not to handle them — the point is to understand the texture of what Indian Data Principals are actually complaining about. After three months, you will know your organisation's privacy posture better than any consultant could ever tell you, and you will have a list of product changes that are obviously needed.

Step 4 — Run a tabletop drill. Pick a Saturday morning. Tell five people on your team that you're declaring a hypothetical breach. Run them through the 72-hour clock. See what breaks. What breaks is your work plan for the next quarter.

Step 5 — Publish your privacy posture internally. Once a quarter, send a one-page summary to the entire organisation. How many DSR requests did we receive? How many did we fulfil within SLA? How many vendors did we onboard, and how many had compliant DPAs? How many incidents did we declare? Were any close calls? The point is not the metrics themselves — the point is that the rest of the organisation sees that someone is keeping score, which makes them want to look good on the next quarterly summary.

Step 6 — Connect privacy work to a customer-facing outcome. Find one specific way in which your privacy posture has produced a customer-facing improvement. Maybe a faster DSR response time. Maybe a clearer privacy notice. Maybe a one-click consent withdrawal that previously took three steps. Whatever it is, find it, name it, and share it with the customer-facing teams. Privacy work that produces no customer-facing benefit will always feel like a tax. Privacy work that produces visible benefit becomes a source of organisational pride.

These six steps are not expensive. They are not technically complex. They do not require a new platform purchase. They require the organisation to decide that DPDP is going to be a cultural thing rather than a checkbox thing, and then to act on that decision consistently for two quarters until the new behaviour becomes the default.

After two quarters, the organisation looks different. The DPO is a real role with real authority. The grievance inbox is a signal source. Product launches include a privacy gate. The audit trail is honest and useful. The team has done a breach drill and knows what to do when the real one lands. None of that requires the regulator to be watching. All of it is voluntary, internally-driven, culturally-rooted compliance work.

The closing argument

The Indian organisations that get this right will outperform the ones that don't, and the gap will be visible by 2028. Not because the regulator will reward them — although the regulator probably will — but because the cultural shift is its own reward. Better product decisions. Faster grievance resolution. Lower breach risk. Stronger customer trust. Cleaner data inventories. Less retrofit work. Higher employee morale in the privacy function, because the work feels meaningful.

The ones that treat DPDPA as a burden will spend the same money and get none of those things. They will pay the cost of compliance and receive none of the benefit. And when the first significant enforcement action lands in their sector, they will discover that compliance theatre does not survive contact with a serious regulator.

The choice between the two paths is being made right now, in every Indian boardroom, in every compliance committee, in every quarterly budget review. The choice is not between “spend on compliance” and “don't spend on compliance”. It's between “spend with a culture mindset” and “spend with a checkbox mindset”. The first costs the same as the second and produces dramatically more value.

If you're reading this and you're the person who has to decide which path your organisation takes — whether you're a DPO, a CISO, a General Counsel, a Chief Compliance Officer, or a CEO — I want to make a small request. Pick the culture path. Not because it's noble, although it is. Pick it because it's cheaper per unit of real outcome, and because the other path is going to look very bad when the Data Protection Board shows up in three years and asks what your privacy posture actually looks like in practice.

The tools are ready. The frameworks are ready. The Act is ready. The Board is being constituted. The only thing that's still in flux is the mindset. Pick the right one.

If you want a fast, honest read on where your organisation actually sits today — not the binder version, the real version — our free DPDP assessment is built for exactly this kind of decision-making. Five minutes, 40 questions, a posture score, a prioritised gap list, no marketing chase. It will tell you whether you're on the culture path or the checkbox path, and what it would take to switch.