DPDP compliance is becoming a runtime data governance problem

At a glance

What this is: LEVO argues that India’s DPDP regime turns privacy into a runtime governance problem because enterprises must prove how personal data moves and is controlled in live systems.

Why it matters: This matters to IAM and security teams because data access, third-party sharing, and rights handling now need continuous evidence across applications, APIs, and vendor paths.

Context

The Digital Personal Data Protection Act, 2023 shifts privacy from a policy exercise to an operational control problem. Enterprises can no longer rely on static data maps, annual reviews, or vendor promises when personal data flows through cloud apps, APIs, SaaS tools, and integrations.

The article’s core point is that DPDP compliance depends on runtime visibility, purpose limitation, consent enforcement, and proof that real system behaviour matches declared policy. That creates a direct governance intersection with IAM, NHI, and third-party access because data movement is often mediated by service accounts, application identities, tokens, and API connections.

For global businesses that process personal data in India, the starting position described here is typical: policies exist, but live evidence is often fragmented. The compliance gap is therefore less about wording and more about control, telemetry, and accountability.

Key questions

Q: What breaks when DPDP controls exist only in policy documents?

A: Runtime behaviour becomes the failure point. If consent, purpose limitation, and retention rules are not enforced in APIs and downstream systems, the organisation may still process personal data incorrectly even with good documentation. The practical risk is policy-to-production drift, where the approved rule set and the live data path diverge.

Q: Why does DPDP compliance depend on third-party and API governance?

A: Because most personal data now moves through integrations rather than isolated databases. Each API, SaaS tool, or processor can copy, transform, or expose data outside the intended purpose. If those paths are not governed, the enterprise cannot prove who touched the data, why it moved, or whether the transfer stayed within consent and contractual limits.

Q: What are the signs that runtime privacy controls are failing?

A: Common signs include mismatched data maps and live behaviour, over-shared fields in API responses, manual handling of deletion requests, and vendor tools receiving more data than they need. If teams cannot answer where a record flowed within minutes, the control environment is too fragmented for DPDP-grade assurance.

Q: Who is accountable for DPDP compliance when multiple teams handle personal data?

A: Accountability should sit with clear owners across business, legal, security, and engineering, led by a responsible privacy function or privacy leader. DPDP expects decision rights, escalation paths, and enforceable controls, not informal coordination. If ownership is diffuse, organisations struggle to prove who approved data use, who monitors controls, and who responds when a breach or rights request occurs.

Technical breakdown

Why DPDP pushes privacy into runtime control

DPDP matters at runtime because personal data is not governed by documents alone. It moves through APIs, queues, microservices, SaaS platforms, and partner integrations, often outside the visibility of traditional audit cycles. A static privacy notice can say one thing while application behaviour does another. The operational challenge is to connect policy intent, consent state, and actual data handling in production so that the enterprise can prove purpose limitation and minimization when questioned. In practice, this requires control points where data is requested, transformed, shared, and retained, not just where it is stored.

Practical implication: teams need enforcement where data moves, not only periodic reviews of where it is stored.

How consent and data rights become system design problems

Consent, correction, access, and erasure only work at scale when they are encoded into application and integration design. If one system honors a deletion request but downstream analytics, support, or marketing tools keep the same record, the control has failed even if the policy is correct. This is where identity and data governance intersect: the enterprise must know which user, customer, or principal triggered the request and then propagate that decision across every connected system. The hard part is not the request form, but consistent execution across distributed services.

Practical implication: build rights workflows that propagate decisions across every connected system, including third-party services.

Why third-party integrations expand DPDP risk

Third-party processors and cloud services widen the compliance boundary because data can be copied, enriched, or exposed outside the core platform in ways that are hard to see. Vendor contracts matter, but they do not prove what a live integration actually sends. That is a governance gap, not just a procurement gap. Where service accounts, API keys, and delegated access are used to move personal data, identity controls become part of privacy control. The enterprise must understand not only who has access, but which machine identities are moving personal data and under what conditions.

Practical implication: inventory delegated access paths and tie every third-party data flow to a named owner and purpose.

Threat narrative

Attacker objective: The objective is to exploit weak data governance and opaque integrations so personal data can be over-shared, misused, or exposed without clear accountability.

1. Entry occurs through ordinary business integrations, where APIs, SaaS tools, and vendor connections are allowed to exchange personal data across the environment.
2. Credentialed access then widens the blast radius because service accounts, tokens, and delegated integrations can move data without the same scrutiny applied to human users.
3. Impact follows when over-shared or poorly governed data can no longer be proven, constrained, or quickly scoped during an audit or breach inquiry.

Breaches seen in the wild

• Indian government breach 2021: Sakura Samurai found exposed .git and .env files across Indian government sites, leaking 35 credential pairs, private keys and personal data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime data governance is the real control plane for DPDP. The law’s practical burden is not legal interpretation but operational evidence. If an enterprise cannot show what personal data flowed, where it went, and under which authorization path, compliance is already weakened. For identity teams, this means the control surface includes application identities, service accounts, and delegated access, not just human users. The practitioner conclusion is that privacy governance now depends on continuous runtime visibility.

DPDP exposes a verification gap between policy intent and production behaviour. Many organisations can describe consent, purpose limitation, and retention rules, but far fewer can prove that downstream systems obey them after the first API call. This is a governance failure mode, not a documentation issue. The named concept here is policy-to-production drift: the distance between what the enterprise says should happen and what its systems actually do. The practitioner conclusion is to measure control drift as a core privacy risk.

Third-party data paths are now privacy controls, not just vendor relationships. Once personal data moves through cloud services, analytics platforms, and outsourced workflows, the compliance boundary extends to machine identities and integration credentials. That makes offboarding, rotation, and access scoping part of privacy governance. The practitioner conclusion is to treat vendor connectivity as a live control surface, especially where NHIs move regulated data.

DPDP will reward enterprises that can prove control, not merely assert compliance. The organisations that do best will not be the ones with the longest policy documents, but the ones with the clearest data-flow telemetry, rights propagation, and incident scoping. That changes the market signal for CIOs and CISOs alike. The practitioner conclusion is to build evidence as a capability, not as an afterthought.

The strongest DPDP programmes will converge privacy, security, and identity governance. Data protection cannot be sustained if IAM, application teams, and legal operate from different maps of the same environment. Personal data governance now depends on shared inventories, consistent authorization, and defensible audit trails. The practitioner conclusion is to align control ownership across those functions before the next product launch or vendor integration.

What this signals

Policy-to-production drift is the central DPDP risk. If legal intent and live system behaviour are not aligned, the enterprise is already operating with hidden compliance debt. Runtime data governance gives security and privacy teams a shared way to close that gap before it becomes a breach, audit, or customer trust problem.

For identity and security leaders, the practical shift is toward evidence-first governance. That means mapping machine identities, integration credentials, and third-party access paths as part of the privacy control surface, then keeping those paths under continuous review.

The strongest programmes will treat data-flow telemetry, rights propagation, and access scoping as one operating model. That is the difference between writing privacy policy and proving privacy control in production.

For practitioners

• Build a live personal data inventory Track where personal data enters, moves through, and exits applications, APIs, SaaS tools, and third-party integrations. Include service accounts, tokens, and vendor connections in the same inventory so the control view matches production behaviour.
• Bind consent logic to runtime enforcement Implement consent checks and purpose limits in APIs and downstream workflows so approved use is enforced at the point of processing, not only in policy documents.
• Propagate rights requests across connected systems Design access, correction, and erasure workflows so the same decision reaches customer portals, support tools, analytics platforms, and external processors without manual rework.
• Treat vendor integrations as governed data paths Assign ownership, approved purpose, and offboarding rules to every third-party integration that touches personal data, including machine identities used for data exchange.
• Prepare evidence for breach and audit questions Retain logs and lineage records that show what data was accessed, which identity or integration used it, and how far it propagated so the organisation can answer regulators quickly.

Key takeaways

• DPDP changes privacy from a documentation exercise into a runtime governance problem because the real control failure is often in live APIs, integrations, and vendor paths.
• The article’s core warning is that policy-to-production drift creates a gap between what enterprises say should happen and what their systems actually do with personal data.
• Practitioners need continuous visibility, rights propagation, and third-party access control if they want to prove accountability under DPDP.

Key terms

• Runtime Data Governance: Runtime data governance is the enforcement of policy over data while it is being created, accessed, and transmitted in a live session. In the browser, this means controlling which scripts, agents, and page elements can interact with sensitive information, rather than depending only on backend controls or static consent settings.
• Policy-to-Production Drift: Policy-to-production drift is the gap between what an organisation says its data controls do and what systems actually do in live environments. It often appears when APIs, SaaS tools, and integrations evolve faster than governance, leaving privacy and access decisions inconsistently enforced.
• Purpose limitation: The rule that data should be used only for the specific business purpose allowed by policy and context. In AI environments, this means a dataset may be technically accessible but still inappropriate for a given model, assistant, or agent if the use case exceeds the approved scope.
• Data Principal rights workflow: A Data Principal rights workflow is the end-to-end process for access, correction, erasure, or withdrawal requests across all systems holding a person’s data. It is not complete until the enterprise can coordinate changes in the primary identity store and every downstream repository with consistent results.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in the context of real enterprise control problems. It is designed for practitioners who need to connect identity discipline to broader security and governance work.