Introduction 

For large businesses, sharing personal data with an affiliate is often treated as an internal movement of information. A company may use a group entity for payroll, place customer information on a common CRM, run cybersecurity through a regional centre, or combine data from different subsidiaries for analytics and marketing. Operationally, these systems may function as one group environment. 

The Digital Personal Data Protection Act, 2023 (DPDP Act), however, does not treat a corporate group as a single privacy unit. It does not define an “affiliate” or create a general exception for sharing personal data between group companies. Instead, it looks at what each entity does with the data. A person determining the purpose and means of processing is a Data Fiduciary, while a person processing data on its behalf is a Data Processor. Importantly, the statutory definition of processing itself includes sharing and disclosure. 

This creates the real affiliate-sharing question under the DPDP Act: not whether two companies belong to the same group, but why the data is moving between them and what the recipient is permitted to do with it.With most substantive obligations becoming enforceable from 13 May 2027, corporate groups should use the transition period to answer that question for already operational data flows. 

One Group Can Contain Several Different Privacy Relationships 

The same affiliate can play different roles depending on the activity. Take a group company that runs payroll for several Indian subsidiaries. If it receives employee information only to calculate salaries and acts on instructions from each employer, the arrangement resembles processor activity. Section 8(2) requires a Data Fiduciary engaging a Data Processor to do so under a valid contract, while responsibility for processing undertaken on its behalf remains with the Data Fiduciary. 

Now consider the same group company receiving employee information and deciding to use it independently to develop a group-wide recruitment product. Its role has changed because it is now determining an additional purpose for the data. 

A third situation arises where two affiliates jointly design a common loyalty programme, decide what customer data will be collected, and determine how it will be used across both businesses. Section 2(i) recognises that the purpose and means of processing may be determined by a person “alone or in conjunction with other persons”. The Act does not provide a detailed joint-fiduciary mechanism comparable to the GDPR, so the parties should document their respective responsibilities rather than assuming one entity carries the entire compliance burden. 

The practical mistake is therefore to label an affiliate “our processor” or “our Data Fiduciary” at the entity level. The classification should follow the processing activity. 

A Group-Sharing Clause Is Not a Standalone Legal Basis 

Role classification only answers who is responsible. It does not answer whether the sharing itself is permitted. 

Section 4 requires processing to be for a lawful purpose and to rest either on consent or one of the “certain legitimate uses” specified in Section 7. Where consent is used, Section 6 requires it to be specific and informed and linked to the specified purpose. 

This matters particularly for privacy notices that say personal data “may be shared with affiliates and group companies”. Such language may help tell the individual that intra-group sharing occurs, but it does not by itself create a legal ground for every subsequent use of the data. 

Consider a customer who gives an e-commerce company her address and phone number to purchase and receive a product. Sharing those details with a group company operating the delivery infrastructure is connected to that transaction. Using the same information to allow an unrelated financial-services affiliate to independently market loans raise a different question because the purpose has changed. 

A similar issue arises with centralised data lakes. A group may technically be able to combine customer records from several subsidiaries in one platform, but technical consolidation does not mean that each subsidiary can automatically use every record for its own analytics, profiling or marketing. 

The safer approach is to assess purpose before recipient: what was the data collected for, why does the affiliate need it, and does the existing ground for processing cover that use? 

Employee Data May Be Easier to Share, but Not Without Limits 

Employee information is one area where the DPDP Act provides greater operational flexibility. 

Section 7 recognises processing for employment purposes and purposes connected with safeguarding an employer from loss or liability. This can support genuine employment-related activities within a group, such as payroll administration, employee benefits, internal HR systems, confidentiality controls and certain workplace security functions. 

For example, an Indian subsidiary may use a regional group HR centre to administer salaries and employee benefits. The arrangement should still identify the purpose, the recipient's role, the data being accessed and the controls placed around that access.

The employment ground should not, however, be treated as permission to circulate employee information across the entire corporate group. If the same employee database is later repurposed for an activity unrelated to employment, the organisation should separately determine what permits that processing. 

The distinction is especially important for multinational employers operating global HR platforms, where a single employee record may be visible to several group entities even though only some of them require that information for an employment function. 

Centralised Systems Create a Second Problem: Accountability 

Affiliate sharing is not only a consent issue. It also creates practical questions around accuracy, access, security and deletion. 

Where personal data is likely to be disclosed to another Data Fiduciary, Section 8(3) requires the Data Fiduciary processing that information to ensure its completeness, accuracy and consistency. A business feeding customer information into a group-wide CRM therefore needs more than permission to share it. It should also have a process for correcting information across the systems into which it has flowed. 

Section 11 creates another operational challenge. Where the provision applies, a Data Principal can request the identities of other Data Fiduciaries and Data Processors with whom personal data has been shared, together with a description of the data shared. A company that merely records “group affiliates” in its internal documentation may struggle to answer such a request if the information has passed through several shared systems. 

Retention creates the same problem in reverse. Section 8(7) requires personal data to be erased when the statutory conditions for erasure are met and requires the Data Fiduciary to cause its processors to erase data made available to them, subject to applicable retention requirements. Deleting a customer from the originating entity's database is therefore not enough if copies remain in a group analytics platform, shared CRM or affiliate-operated service system. 

The DPDP Rules add security requirements, including access controls, logging, technical safeguards and contractual security provisions for processing undertaken through Data Processors. Affiliate access should therefore be governed with the same discipline as access given to an external vendor. 

Overseas Affiliates Are Not Just Another Internal Transfer 

Section 16 permits the Central Government to restrict transfers to specified countries or territories. Rule 15 also allows the Government to impose requirements concerning the availability of transferred personal data to foreign States or entities under their control. Significant Data Fiduciaries may face additional restrictions for categories of data specified by the Government. 

Corporate groups must also look beyond the DPDP Act. Section 16 expressly preserves Indian laws that impose a higher degree of protection or restriction. This is particularly relevant in regulated sectors. RBI directions, for example, require payment system data to be stored in India subject to specified exceptions, even where processing involves service providers or other entities in the payment ecosystem. 

A multinational group should therefore not record a transfer simply as “shared with global parent”. It should know which country receives the data, whether the affiliate acts independently or on instructions, which systems can access it, whether further group entities receive it, and whether sector-specific localisation or outsourcing requirements apply. 

What Should Organisations Do Instead? 

Rather than drafting one broad data-sharing agreement and treating the exercise as complete, organisations should build the arrangement around individual data flows:

• Map the actual flows: Identify the sending entity, receiving affiliate, categories of data, systems involved, processing location and any onward sharing. 

  
  

• Classify the recipient by activity: Determine whether the affiliate acts on instructions, independently determines a purpose, or determines the purpose and means together with another entity. 

  
  

• Identify the purpose: Record why each category of personal data needs to move. Do not treat “group use” or “internal business purposes” as the purpose itself. 

  
  

• Check the processing ground: Determine whether the use rests on consent or a specific ground under Section 7. Treat a new affiliate purpose as a separate compliance question. 

  
  

• Review shared platforms: Test common CRMs, HR systems, data lakes and analytics platforms to determine which entities can actually view or use the information. 

  
  

• Put processor relationships under contract: Where an affiliate acts as a Data Processor, ensure the agreement addresses instructions, security, breach escalation, assistance with rights requests and deletion. 

  
  

• Build a recipient register: Maintain enough information to identify the affiliates and processors that received a particular individual's data and what was shared with them. 

  
  

• Synchronise correction and deletion: Ensure updates, withdrawals and erasure instructions can flow through group systems rather than stopping at the original database. 

  
  

• Separate overseas transfers: Record the jurisdiction, remote-access arrangements and applicable sectoral restrictions for every foreign affiliate. 

Conclusion 

The DPDP Act does not provide a special answer for affiliate sharing because the corporate relationship is not the decisive factor. Two companies may sit within the same group and still have entirely different responsibilities depending on what they do with personal data. 

For businesses, the better question is therefore not, “Can we share this with an affiliate?” It is: what will that affiliate do with the data once it receives it? 

Answering that question exposes the issues that matter under the DPDP framework: role, purpose, legal basis, accountability, security, retention and cross-border access. Groups that map those elements now will be in a much better position than those relying on a broad “group companies” clause when the substantive obligations become enforceable. 

Want to Stay Ahead 

Reach out to experts at GoTrust today.