The statute is law. The operating posture — what enterprise buyers actually ask for — is a separate and more demanding thing. Here's the field manual.
The DPDPA came into force in mid-2024. By early 2026 its operational reality — what enterprise buyers actually ask for and what the Data Protection Board actually expects — is no longer theoretical. India's AI teams shipping into the Indian market have three real, recurring problems: (1) a compliance-documentation muscle that their eng org hasn't built yet, (2) enterprise DPOs asking questions the EU AI Act taught them to ask, and (3) a clock that starts the day a PII-touching incident occurs and expires 72 hours later.
Most of what follows is not law. It is the operating posture we've watched land enterprise deals and the things that when missing, have killed them. Treat this as a 12-step field manual, not a legal memo.
§ 01
A named DPO path — before procurement asks
By the time an enterprise prospect's DPO emails you asking for your Data Protection Officer, you have about 48 hours before deal-stall. Name someone. Publish the name on a /privacy or /dpo page with a direct mailbox (we use grievance@ and privacy@ as split addresses). The DPO does not need to be full-time. They need to be named, reachable, and able to answer a structured question in writing within seven working days. That last bit is statutory — DPDPA §8(9) treats a grievance-officer response path as a basic right.
§ 02
Data residency — write it down, then mean it
DPDPA does not mandate localisation for most classes. It mandates disclosure. The failure mode we see: the product runs on AWS in ap-south-1, but the LLM API call goes to us-east-1 because that's where the vendor's primary region is. The product team knows this; the DPA the prospect signs does not mention this. When the DPO finds out (and they find out), the deal pauses. Fix: explicit residency statement per data class, per vendor, per region. Published on /privacy, referenced in every DPA, and audited quarterly against actual network logs. A 10-row table beats a 3-page narrative.
§ 03
Consent flows you can actually audit
DPDPA consent is statute; it also has to be reversible on request. The hard part is not collection (every team nails the checkbox). The hard part is the erasure request arriving six months later and someone having to grep five systems to confirm that user X has been removed from training data, evaluation data, logs, backups, and the vendor's cache. Fix: log consent state as an event stream with a per-user consent ID that flows through to every downstream system. When the erasure request arrives, the answer is a one-query lookup plus a 24-hour downstream-propagation SLA. Do not wait for the first erasure request to design this. Design for it before shipping.
“Compliance is a lagging indicator of discipline. If your eval set and audit trail are clean, DPDPA is a six-hour paperwork exercise. If they’re not, no amount of DPA redlining will save you.”
§ 04
Bias probes as CI, not annual audits
The EU AI Act taught Indian enterprise DPOs to ask for ‘documented bias probe results across protected attributes’. DPDPA does not explicitly require them. But procurement does, and that is the effective regulator. A bias probe you can produce evidence for costs about two weeks of engineering setup and then runs automatically on every model change. A bias probe you improvise under procurement pressure costs three to five weeks of deal delay. Do it once; reuse forever. Same probe dataset on every production model; same report template for every DPO.
§ 05
A 72-hour incident-response runbook you have actually practised
On day-zero of a PII incident, three things must happen in parallel: (1) contain — cut the exposed surface, (2) preserve — snapshot logs before they roll over, (3) notify — the template email to the DPO, the prospect DPOs you have active deals with, and (within 72 hours in most classifications) the Data Protection Board. You cannot write the template email at 02:00 on the morning of the incident. Pre-write it. Drill once per quarter. Name who the incident-commander is.
§ 06
Vendor contracts with exit clauses that match statute
Most vendor MSAs assume the vendor is winding up. DPDPA reality is that the consuming firm (you) may need to exit mid-contract because of a statutory change or a customer compliance requirement. Negotiate contract termination for compliance reason, data-return format, and data-destruction attestation as part of the initial MSA. Not as an amendment six months in. This is one of the items where the right conversation at signing costs nothing and the wrong conversation in year two costs the relationship.
§ 07
Model cards on every shipped model
Anthropic does model cards well; so do DeepMind and a handful of the open-source ecosystem. Indian SaaS teams rarely ship them. They should. A one-page model card (training data scope, intended use, known limitations, eval results, bias-probe results, intended out-of-scope uses) is the single most efficient piece of trust-theater you can produce. Enterprise DPOs accept them as evidence. Regulators will eventually require them. Ship one per model. Keep it current.
§ 08
What to do next
If you have an enterprise DPO in your pipeline right now: Shield — three weeks, ₹12L, produces every document in this list — is the engagement shape. The 28-page technical annex is the document your prospect actually reads.
If you have six months of runway before your next enterprise cycle: set up the compliance-ops rhythm. One hour a month with a named owner. It is the cheapest insurance you will ever buy.