Managing DPDP Compliance Across a Multi-Entity Corporate Group

The DPDP Act's obligations attach to whichever entity is acting as Data Fiduciary or Data Processor for a given processing activity, not to the corporate group as an abstract whole. In a multi-entity structure, that means each entity that determines the purpose and means of processing needs its own answer to notice, consent, and security obligations, even where a parent company sets group-wide policy.

This matters most where one entity in the group holds itself out as an SDF under Section 10 while others don't meet the threshold — the additional duties like a resident DPO and periodic DPIA apply to the entity that meets the threshold, not automatically to affiliates that don't.

Shared services — a group-wide HR system, a central customer support platform, a common marketing database — create intra-group data flows that need the same discipline as external vendor relationships. If one entity processes another entity's customer data on its behalf, that's a processor relationship requiring the same kind of contractual clarity Section 8(2) expects of any Data Processor arrangement.

Map these intra-group flows explicitly rather than assuming that data sharing within one corporate family is automatically low risk. The obligations don't relax just because the counterparties share a parent company.

A fully centralized model — one group-wide privacy function setting policy and running controls for every entity — works well when entities share systems and data flows closely, but it can miss entity-specific nuances, such as one subsidiary handling children's data under Section 9 where others don't.

A fully federated model, where each entity runs its own program, avoids that blind spot but risks duplicated effort and inconsistent baselines. Most groups land on a hybrid: central policy, templates, and tooling, with a named privacy owner in each entity responsible for local application and escalation.

Maintain a single data flow map that spans entity boundaries, tagging which legal entity is the fiduciary and which is acting as processor for each flow. Without this, a group-wide breach or a regulator inquiry forces a scramble to reconstruct which entity actually held which obligation.

Revisit the mapping whenever the corporate structure changes — new subsidiaries, restructured shared services, or entities being wound down all shift where obligations sit and need to be reflected promptly.

The Data Flow Mapper supports mapping across multiple entities within one view, and the Applicability Checker is worth re-running per entity whenever the group structure changes, since applicability and SDF thresholds are assessed at the entity level.