Which teams are accountable for making DPDP workable in production?

Who Owns DPDP Delivery Once the Legal Position Is Clear

DPDP becomes workable only when accountability is split by function but coordinated by one operating model. Legal owns interpretation and policy boundaries, security owns protection requirements and assurance, and engineering owns the product and data-path changes that make those requirements real in systems, workflows, and integrations. The CIO or equivalent technology leader is usually the only role positioned to resolve conflicts between those teams and keep the same data maps, retention rules, and access assumptions consistent across production.

That distinction matters because DPDP fails in practice when it is treated as a policy document rather than an operational design constraint. If legal and security define rules without engineering participation, the result is controls that cannot be implemented cleanly or are bypassed later. If engineering implements changes without common ownership of the underlying data model, teams end up with different interpretations of the same personal data, purpose, or retention boundary. NIST’s control model is a useful reference point for translating obligations into operational safeguards: NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many organisations discover the ownership gap only after a release, integration, or exception path has already made the privacy rule behave differently in production.

What Makes the Operating Model Actually Work in Production

Working DPDP accountability is less about naming owners and more about making their decisions converge on the same implementation artefacts. The teams need a shared view of personal-data classes, processing purposes, retention periods, consent or notice dependencies where applicable, and the systems that move data between products, vendors, and internal services. Without that shared inventory, each team optimises its own task and the organisation loses traceability across the data lifecycle.

• Legal should define the rule in terms engineering can map to system behaviour, not only in policy language.
• Security should translate the rule into enforceable controls, such as access restriction, logging, encryption, segregation, and review checkpoints.
• Engineering should embed those controls into product flows, schemas, pipelines, APIs, and change management so they survive release cycles.
• The CIO should arbitrate disagreements where business velocity and control consistency collide, because unresolved exceptions tend to become the default production state.

The practical test is whether a change to one system can be traced through to the same data classification, retention, and protection logic everywhere that data appears. If the answer is no, the organisation may have compliance language, but it does not yet have operational DPDP control. This is where a control framework helps shape execution, but the real work is in keeping the data map, product architecture, and approval path aligned enough that the rule can be enforced repeatedly, not just documented once.

Where DPDP Accountability Breaks Down Across Edge Cases

Tighter privacy accountability often increases coordination overhead, so organisations have to balance speed against consistency when data moves across many products or vendors. The weakest point is usually not the core policy but the exception path, where a one-off integration, temporary feature, or outsourced workflow quietly escapes the standard ownership model.

There is also a genuine distinction between policy ownership and implementation ownership. Legal can define what should happen, but it cannot be the sole owner of production readiness. Security can mandate technical safeguards, but it cannot compensate for a product team that never models the data correctly. Engineering can build the control, but it cannot decide the legal boundary in isolation. The consensus is clear on shared accountability, but organisations still differ on whether privacy engineering sits inside product, platform, or security. That reporting line matters less than whether the decision rights are explicit and repeatable.

Cross-border processing, vendor integrations, and data migrations are the cases that most often expose hidden assumptions because they force teams to restate what counts as the same data, the same purpose, or the same retention rule. If those definitions are inconsistent, production behaviour drifts even when governance looks intact on paper.

Practitioner Guidance

What to prioritise: Start by naming the decision owners for data classification, control design, and production change approval. If any of those are implicit, DPDP execution will drift into informal exceptions that are hard to govern.

What to verify: Check that the same data inventory is used by legal, security, and engineering. The key test is not whether each team has documentation, but whether they are referencing the same records, rules, and system boundaries when a change request lands.

What practitioners underestimate: The integration layer is often where accountability fails first. A control can look sound inside one application and still break when data is copied, transformed, or forwarded into a downstream service that no one has explicitly owned.

Practitioner takeaway: DPDP is workable in production only when accountability is operational, not ceremonial; the organisations that succeed are the ones that treat shared data definitions as a control surface, not an administrative detail.

Related resources from NHI Mgmt Group

• Why do teams need more than operational dashboards when production LLMs start making decisions for users?
• Who is accountable for making Data Act response workflows defensible across legal, privacy, and operational teams?
• How do security teams decide whether autonomous SOC workflows are accountable enough for production use?
• Who is accountable for making a practitioner event worthwhile for security teams?