Sharing Employee Data Within a Corporate Group: When a DPA Is Not Enough

Sharing Employee Data Within a Corporate Group: When a DPA Is Not Enough

“Add the parent company to the system—we already have a DPA.”

For a business operating in Poland, that request may sound routine. But an existing data processing agreement (DPA) does not necessarily authorize the access. If the parent company wants to review pay data to calculate its own margins, monitor costs, or oversee remuneration, it is not acting on the system operator’s instructions. For that activity, it acts as a separate controller. That calls for a different document, a separate assessment of the legal basis, and a narrower view of the data it needs.

Confusing controllers, processors, and joint controllers is a recurring problem in intra-group GDPR documentation. Decisions of Poland’s data protection authority—the President of the Personal Data Protection Office (PUODO)—document repeated Article 28 GDPR failures, including missing written processing agreements, incomplete descriptions of data categories, and documentation put in place only after an incident (UODO: several GDPR infringements result in a fine).

The practical starting point is one question: Whose purpose is the access serving? The answer guides the choice of agreement, the scope of access, transparency notices, retention periods, and system configuration.

Start with the parties’ actual roles

GDPR roles depend on what each entity actually decides and does—not on the title of an agreement or the fact that the entities belong to the same group.

In its decisions, the Polish authority refers to EDPB Guidelines 07/2020 and notes that an entity need not have physical access to data to be its controller (UODO: which entity should be regarded as the controller).

A DPA is an Article 28 data processing agreement. It governs processing by a processor on a controller’s instructions. A controller-to-controller data-sharing agreement addresses disclosure between separate controllers that process the data for their respective purposes.

Ask “whose purpose is it?” before granting access

Shareholder oversight, margin analysis, cost allocation, and review of employment terms are purposes of the parent company when it undertakes them for itself. They are not converted into the system operator’s purposes by a broadly drafted DPA.

Joint controllership is not an automatic alternative. In Fashion ID (C-40/17, 29 July 2019), the Court of Justice of the European Union confirmed that joint controllership can be limited to a distinct stage of processing; it does not extend to operations whose purposes or means an entity does not determine (EUR-Lex link cited for the judgment). Group membership, a shared brand, or use of the same system does not, by itself, make companies joint controllers.

Why the group’s existing DPA may not cover the system

A “mutual” group DPA may describe the data as “contact and basic details of the parties’ personnel and customers.” A recruitment and personnel-records system may expose much more:

1. Candidates’ CVs, which may include special category data under Article 9 GDPR
2. Hourly rates and availability
3. Subcontracting information
4. LinkedIn profiles and activity history

Retrieve the signed DPA and compare its stated categories with what a user can actually see. If it covers “contact details” but the system exposes CVs and rates, its description does not cover that access. And if the recipient uses the data for its own purposes, expanding the DPA’s wording will not resolve the underlying role mismatch.

What goes wrong when roles are misclassified

Treating a separate controller as a processor can create several GDPR risks at once. An infringement of Article 6(1) GDPR falls within Article 83(5)(a), which provides for a maximum fine of EUR 20 million or 4% of total worldwide annual turnover (GDPR, Article 83).

No appropriate legal basis

A DPA does not itself provide the parent company with a legal basis to process data for its own purposes. If access is granted under a DPA but used for the parent’s own oversight or analysis, the Article 6(1) basis must be assessed separately. PUODO has used both reprimands and substantial fines for processing without a legal basis. In 2025, it fined Poland’s postal operator, Poczta Polska, PLN 27 million for such processing (UODO notice).

Excessive access

Giving the parent a full system view “for convenience” can breach the data minimization principle in Article 5(1)(c) GDPR. A finance team may need to know who worked for which client and at what rate. It does not follow that it needs a candidate’s address, bank account number, employment history, or entire CV.

Unclear retention

“Permanent access” or “access until revoked” may describe how long an arrangement remains in force. It cannot stand in for a retention period for reports containing personal data. Article 5(1)(e) GDPR requires storage for no longer than necessary for the processing purposes (GDPR, Article 5).

Notices that do not match practice

If employees or consultants are told that only Company A sees their data, while Company B can also access it, the discrepancy creates a transparency problem and may prompt complaints.

An eight-step plan for intra-group access

1. Determine roles separately for each processing activity

One DPA “for everything” is not enough. For each proposed use, establish:

1. Who determined the processing purpose?
2. Was that purpose decided jointly?
3. Who decides the essential means of processing?
4. Is one company acting solely on the other’s instructions?

Teach the IT, HR, and administrative staff who grant access to ask “whose purpose is it?” before adding a user. This simple check can prevent wrongly executed group DPAs.

2. Select the document that matches those roles

The document should reflect the actual activity, not be used to assign a convenient label to it.

3. Reduce the data to what the purpose needs

Instead of sending full employment contracts, request an individual-level report. A complete contract can contain remuneration, a bank account number, an address, and potentially special category data under Article 9 GDPR. Sending the whole document for a narrower financial purpose breaches the data minimization principle.

A report for the stated oversight purpose could contain:

• Position
• Remuneration amount
• Start and end dates
• Hourly rate, if applicable
• Monthly amount

Remove information that is not needed, including bank account numbers, home addresses, and data that may be special category data. Do not include CVs as a default: they may carry Article 9 data and require a separate route if there is a distinct purpose.

Check the proposed report against the actual system with IT. Confirm both that it excludes unnecessary fields and that it includes the fields needed for the calculation. In the situations described in the source, several fields needed to calculate margins were missing from the system controller’s proposed field list.

4. Assess any reliance on legitimate interests

A legitimate interest under Article 6(1)(f) GDPR may provide a basis for sharing data for shareholder oversight. Recital 48 recognizes that group companies may have a legitimate interest in transmitting personal data within the group for internal administrative purposes. It is interpretive guidance, not a standalone legal basis (GDPR, Recitals 47–48).

Carry out a legitimate interests assessment (LIA) for each activity:

A broader disclosure is harder to justify. A narrow, purpose-built report helps support an Article 6(1)(f) assessment; minimization is not an obstacle to useful oversight.

Assess named pay data case by case. No published PUODO or EDPB position has been identified that directly addresses disclosure of a subsidiary’s employees’ named remuneration data to its parent. PUODO states that shareholder oversight is not the same as control over processing under the GDPR and does not automatically confer access to employee data (UODO: data protection in the workplace).

5. Align privacy notices before access begins

Before launching the arrangement:

1. Provide a privacy notice to affected employees and consultants.
2. Update the disclosing company’s privacy statement so it reflects actual system access.
3. Verify that the system’s functionality matches what individuals have been told.

Where the new controller did not obtain data directly from the individual, Article 14(1) GDPR applies. Its own notice should address, among other matters, its identity, purpose, legal basis, data categories, source, recipients, retention period, and individuals’ rights. The deadline is generally one month after obtaining the data (GDPR, Article 14).

The first company’s notice does not replace the second controller’s transparency obligation. The source’s practical recommendation is to address notices before access goes live, rather than use the Article 14 deadline as a reason to postpone planning.

6. Set retention periods for the reports

For Polish entities, Article 74 of the Polish Accounting Act distinguishes between approved annual financial statements, retained permanently, and accounting books and accounting records, generally retained for five years (Polish Accounting Act, Journal of Laws 2023, item 120).

But “shareholder report” and “financial monitoring report” are not document categories defined by that Act. Do not apply a five-year period to every management report simply because it concerns finances. The source treats that period as defensible where the document forms part of accounting books or accounting records.

Put a specific report retention period in the agreement. A provision allowing access “until revoked” concerns the arrangement’s duration, not indefinite storage of its outputs.

7. Configure the report-sharing tool

Article 32 GDPR compliance depends on configuration, not the product name. SharePoint, for example, is neither inherently compliant nor inherently noncompliant (UODO: data security and Article 32).

For a report repository, check that it has:

• A dedicated library rather than a folder in a general area
• No inherited organization-wide permissions
• No “anyone with the link” sharing
• Permissions assigned by role, not to an entire organization
• TLS encryption in transit and encryption at rest
• Audit logging enabled, with logs retained
• A defined and documented group of recipients
• A library retention rule consistent with the agreement

Confirm where both the source system and report repository are hosted. The absence of transfers outside the European Economic Area (EEA) must be verified, not assumed. If anything is located outside the EEA, assess that separately and put an appropriate transfer mechanism in place under Article 46 GDPR.

8. Document individual access and confidentiality

Before granting access:

1. Issue named data-processing authorizations for each person who will have access.
2. Obtain confidentiality undertakings.
3. Limit recipients to those who can be identified by role and purpose: who needs access, and why?
4. Document the controller’s instructions or relevant appendix.

Record each authorization’s scope and purpose. It should be capable of withdrawal when responsibilities change or the relationship ends.

Why BCRs and a general group agreement are not enough

Binding corporate rules (BCRs) under Articles 46(2)(b) and 47 GDPR are an approved mechanism for transfers to third countries within a corporate group (UODO: binding corporate rules). They do not replace an Article 28 DPA or an Article 26 joint-controller arrangement.

BCRs are not required for a relationship entirely within the EEA. The companies still need documentation appropriate to their roles, such as a DPA for processing on instructions or a controller-to-controller data-sharing agreement for disclosure to a separate controller. Calling a document an “intra-group agreement” does not make it approved BCRs: it must meet Article 47’s requirements and receive supervisory-authority approval.

Check party names as well. If a framework agreement or DPA was signed under an outdated company name after a name change or restructuring, verify continuity against the relevant company-register extracts and sign an amendment confirming it.

Putting the legal and operational work together

This is not just an amendment to a contract. A workable review compares the roles assigned for each activity with the data people can actually see, then aligns the agreement, notices, report design, permissions, and retention rules.

We support group companies—particularly Polish entities with foreign owners—at three levels:

Finance may need the figures to calculate margins, not permission to read CVs. The aim is documentation and system access that enable the legitimate task without opening unrelated records. Contact us if you need to review intra-group agreements, map access, or prepare a data-sharing arrangement.

Key points before adding a group company to a system

Ask “whose purpose is it?” before granting access. The answer determines whether you need a DPA, a controller-to-controller data-sharing agreement, or a joint-controller arrangement.

Then limit the data—an individual-level report rather than full employment contracts may meet the business need. Document the legal-basis assessment, set a report retention period, align both companies’ privacy information, and configure access and security measures to match the agreed scope. Data minimization need not prevent shareholder oversight; it can make a proposed disclosure more defensible.

Frequently asked questions

We have a DPA covering the whole group. Doesn’t it cover every system access?

No. An Article 28 DPA covers processing on a controller’s instructions. If a group company accesses data for its own oversight, financial monitoring, or cost-allocation purposes, it acts as a separate controller for that activity, and a controller-to-controller data-sharing agreement is the appropriate document. Also compare the DPA’s stated data categories with what the system actually displays.

As a majority shareholder, why can’t we simply see what the subsidiary pays people?

The GDPR does not prohibit access to that information as such, but the disclosure must be assessed and limited to its purpose. A full employment contract may reveal a bank account number, address, or potentially special category data alongside pay. An individual-level report containing position, remuneration, dates, and any necessary rate is a narrower option. No identified PUODO position expressly permits or prohibits disclosure of named pay data to a parent company; assess the particular case.

Can the agreement say access is “permanent” or “until revoked”?

That wording may describe the arrangement’s duration, including its connection to an ownership relationship. It does not define how long reports are kept. Set a concrete, purpose-based retention period—for example, the current financial year plus a settlement period. The Polish Accounting Act’s five-year period may apply to documents forming part of accounting books or accounting records; it should not automatically be applied to all management reports.

Can we use SharePoint to exchange remuneration reports?

Possibly. Article 32 compliance depends on configuration: use a dedicated library, remove inherited broad permissions, disable “anyone with the link” sharing, assign role-based access, retain audit logs, and apply a retention rule consistent with the agreement. Confirm the repository’s hosting location too.

The parent company is in another EU country. Is this a third-country transfer?

If both companies and the relevant systems are within the EEA, no third-country transfer mechanism under Chapter V GDPR is needed. Verify the system and repository locations rather than relying on the parent company’s registered office. The source emphasizes server location in making that check.

Who should implement the arrangement—Legal, HR, or IT?

All three. Legal assesses roles and prepares the documents. HR updates and distributes notices to employees and consultants. IT builds the report, restricts permissions, and implements retention rules. The documents must match what the system actually does.