DPDP Multi-Entity Rollout Guide
Manage DPDP compliance across group companies and shared services. Document inter-company data flows and centralize privacy governance. Get expert help.
Discuss this page with an LLM
DPDP Action Sheet
Use this before your next workflow goes live. It keeps the useful parts visible and turns DPDP into checks your team can actually answer.
For DPDP Multi-Entity Rollout Guide, the DPDP question is how personal data enters the workflow, where it is stored, which tools touch it, what purpose was explained, and how deletion or withdrawal will work.
1. Lead Forms
Check:
- What data are you collecting?
- Is the purpose clear at the point of collection?
- Is marketing consent separate from service communication?
- Can the user withdraw consent later?
Common mistake: one checkbox that silently covers newsletters, sales calls, partner sharing and remarketing.
2. Email and WhatsApp
Check:
- Who is on the list?
- Where did consent come from?
- Is the list imported from a vendor, event, webinar, scrape or old CRM?
- Can you prove the source of consent?
Common mistake: treating every lead as permanently marketable.
3. Ads and Retargeting
Check:
- Are pixels or ad platforms receiving identifiable user behavior?
- Are audiences built from customer lists?
- Are lookalike or remarketing audiences using personal data?
Common mistake: assuming "the ad platform handles it" means your company has no DPDP responsibility.
4. Website Analytics
Check:
- Which tools run on the site?
- Are IP address, device identifiers, session IDs or form fields being captured?
- Is analytics used only for measurement, or also for profiling and targeting?
Common mistake: installing tools first and asking privacy questions later.
5. Vendor List
Make a quick list:
- CRM
- Email platform
- WhatsApp provider
- Analytics
- Ad pixels
- Form tool
- Landing page builder
- Webinar tool
For each vendor, answer: what data goes there, why, who can access it and how deletion works.
6. This Week's Action
Map one campaign from first click to final follow-up. Mark every place personal data is collected, enriched, shared, uploaded or used for targeting.
If your team cannot answer where the data came from and where it goes next, start with a data flow map before rewriting policy copy.
Book a DPDP clarity callWant all of this handled, end to end? Sanctum is the all-in-one DPDP compliance programme behind this site: legal position, data map, gap analysis, implementation, tooling, training, readiness opinion, and breach cover under one accountable owner. How all-in-one DPDP compliance works or see the Sanctum programme.
Defining Data Roles in Shared Services
Many group companies use one entity for HR, payroll, or IT support. This entity acts as a Data Processor for the other subsidiaries. Under DPDP, the subsidiary that owns the employee or customer relationship is the Data Fiduciary. You must sign a Data Processing Agreement between these internal companies. If the shared service center decides how to use the data, they may become a Joint Fiduciary. This increases their legal liability and requires more complex documentation.
Intra-group Data Transfers
Group companies often move customer data into a central data lake for analytics. DPDP requires a specific purpose for every data transfer. You cannot move data from a retail subsidiary to a finance subsidiary without clear consent for that transfer. Every legal entity needs its own Record of Processing Activities to track where data goes. These records must show exactly which entity sent the data and which entity received it.
Standardizing Consent Across Entities
When a customer uses multiple brands under one parent company, the consent notice must be specific. You cannot use generic terms like “all group companies” to cover data sharing. The notice should name the specific entities that will process the data. If a customer withdraws consent for one brand, your systems must ensure that the change reflects across the entire group if the data is shared.
Group Company Data Flows
| Service Area | Personal Data Involved | DPDP Risk Level |
|---|---|---|
| Shared HR Services | Aadhaar, Bank Details, Performance Reviews | High |
| Centralized IT Support | System Logs, Employee Login IDs | Medium |
| Group Marketing Pool | Customer Names, Phone Numbers, Preferences | High |
| Intra-group Finance | Director KYC, Vendor Contact Details | Medium |
| Cross-brand Loyalty | Purchase History, Reward Points | High |
The “One Group” Fallacy
A common mistake is assuming that a holding company owns all the data. Legally, every subsidiary is an independent Data Fiduciary. Consent given to a clothing brand does not automatically allow an insurance brand in the same group to use that data. You must manage consent at the entity level or create a unified consent architecture that explicitly lists every participating company.
This week
Map every data flow that moves from one legal entity to another within your group. Identify which entity provides the service and which entity owns the customer relationship. Create a template for an Intra-group Data Transfer Agreement to cover these movements.
Now think about your work. Where does personal data enter your workflows? Where does it sit? Who else touches it?
Frequently asked questions
Can one legal entity handle DPDP compliance for the whole group?
No. Every registered company is a separate Data Fiduciary. While you can use a central team for operations, each entity is legally responsible for its own data notices and consent management.
Do we need separate Data Processing Agreements (DPAs) between sister companies?
Yes. If Entity A provides HR services for Entity B, a formal DPA must define the roles. This prevents confusion about who is responsible if a data breach occurs in the shared system.
How do we handle a single customer who uses multiple group brands?
You must track which entity collected the data and what specific consent was given. If you share that data with a sister company for marketing, the customer must have agreed to that specific transfer.