Who is accountable when a privacy notice covers both a parent company and a subsidiary operating as the controller?

Accountability sits with the entity that determines the purposes and means of processing for the relevant activity. If a parent company processes data for its own legal or operational purposes, it may act as controller alongside a subsidiary. Organisations should make entity roles explicit, especially for transfers, rights requests, and cross-group administration.

Why This Matters for Security Teams

When a privacy notice names both a parent and a subsidiary, the real risk is not wording alone but misassigned accountability across the processing chain. Under GDPR-aligned practice, controller status follows who determines the purposes and means of processing, so the answer may be one entity, both entities, or different entities for different activities. That distinction matters for notices, rights handling, data sharing, and breach response.

Security and privacy teams often assume corporate structure decides accountability, but regulators look at operational control instead. In group environments, the same dataset may support payroll, marketing, security logging, or vendor administration, with each activity carrying a different controller analysis. The privacy notice must reflect those roles clearly, or it becomes difficult to prove who owns subject access requests, transfer safeguards, and retention decisions. The legal baseline is reinforced by the EU General Data Protection Regulation (GDPR), while NIST control thinking emphasizes accountable governance over shared data handling in NIST SP 800-53 Rev 5 Security and Privacy Controls.

For NHI-heavy environments, this is not abstract. Shared service accounts, cross-group API access, and centralised identity platforms often create the same ambiguity at machine scale that legal teams see with controller relationships. NHI Mgmt Group has shown how weak visibility into non-human identities amplifies governance failure, including the Ultimate Guide to NHIs and the related Ultimate Guide to NHIs — Standards. In practice, many security teams discover controller confusion only after a rights request, transfer review, or incident has already exposed the gap.

How It Works in Practice

The practical test is simple: identify who decides why the data is processed and who decides how that processing is carried out. A parent company can be a controller for group-wide HR analytics, central fraud monitoring, or consolidated security logging, while a subsidiary remains the controller for local customer operations. In some cases, both are joint controllers, but joint control should be treated as a documented legal and operational arrangement rather than an assumption.

To make the notice defensible, map each processing purpose to a named legal entity and confirm the operational owner of that activity. That mapping should cover:

• the entity receiving the data subject request
• the entity deciding retention and deletion
• the entity authorising cross-border transfers
• the entity controlling shared platforms, logging, and support access

Where a parent runs central identity, finance, or security tooling, it may act as controller for those functions even if the subsidiary remains the primary customer-facing business. This is why the privacy notice should mirror the actual decision chain, not just the org chart. The same pattern appears in incident handling: NHI misuse frequently spreads across business units when ownership is unclear, as illustrated in NHIMG research such as the IOS app secrets leakage report and the Schneider Electric credentials breach.

Current guidance suggests aligning privacy notices, RoPA entries, and intra-group agreements so that each entity can demonstrate its role during audits, rights requests, and breach triage. These controls tend to break down when shared platforms are run centrally but local teams still make the substantive processing decisions.

Common Variations and Edge Cases

Tighter role allocation often increases administrative overhead, requiring organisations to balance clarity against the cost of maintaining separate records, notices, and escalation paths. That tradeoff is unavoidable in groups with overlapping IT and legal functions, especially where the same dataset supports several purposes.

One common edge case is a parent that provides infrastructure only. If it hosts systems but does not determine the purpose of processing, it may be a processor rather than a controller for that activity. Another is a subsidiary that operates locally but relies on group governance for security monitoring or global HR, which can create partial controller status for specific functions. There is no universal standard for every group structure, so the analysis must be activity-specific.

Mixed controller and processor roles are also common when group companies share an identity platform. In that case, the privacy notice should not overstate one entity’s authority or hide joint responsibility behind generic language. The safest approach is to document the decision basis per processing purpose, then ensure contracts, transfer language, and internal workflows reflect that split. That is especially important where support teams, system administrators, or central IAM groups can access records across entities.

In practice, the hardest failures appear when the notice says one entity is accountable but operational reality shows another entity is making the decisions. That mismatch surfaces first in rights handling, then in audits, and finally in incident response.

Related resources from NHI Mgmt Group

• Who is accountable when sensitive data is detected but privacy response is delayed?
• Who is accountable when fraud shifts into fulfilment, returns, or dispute workflows?
• Who is accountable when a red team compromise exposes both endpoint and cloud identity gaps?
• Who is accountable when AD confusion leads to domain compromise?