If your company operates within a corporate group, sooner or later someone will make a request along the lines of: “add us to the system, we already have a DPA”. It sounds reasonable. But in most cases, it is not true. If the parent company accesses the data to calculate its own margins, control costs or oversee remuneration, it is not acting on your instructions. It is acting as a separate controller. And that means an entirely different document, a different legal basis and a different scope of data.
Incorrect classification of roles — controller, processor, joint controller — is one of the most common recurring errors in GDPR documentation within corporate groups. Decisions by the President of the Personal Data Protection Office (PUODO) document repeated infringements of Article 28 GDPR: no written data processing agreement, incomplete specification of data categories, and documentation being put in place only after an incident (UODO — several GDPR infringements result in a fine).
In this article, I will show you how to use one question — “whose purpose is it?” — to classify roles correctly. We will cover how to choose the right instrument (a DPA or a data-sharing agreement), narrow the scope of data, comply with transparency obligations, define retention periods and configure tools. No theory — just specific steps you can implement.
Key concepts before you begin
Before we move on to the details, it is worth clarifying three concepts that determine which document you need to prepare.
| Concept | What it means | When it applies |
|---|---|---|
| Controller (Article 4(7) GDPR) | An entity that independently determines the purposes and means of processing personal data | The parent company analyses remuneration data for its own controlling purposes |
| Processor (Article 4(8) GDPR) | An entity that processes data solely on the controller’s instructions | An external IT provider operates an HR system on behalf of the company |
| Joint controller (Article 26(1) GDPR) | Two or more entities that jointly determine the purposes and means of processing | Two companies jointly conduct a recruitment process and decide together how it will operate |
Each of these concepts is functional in nature — it is determined by what the entities actually do with the data, not by the title of the agreement they have signed. In its decisions, UODO refers to EDPB Guidelines 07/2020, confirming that an entity does not even need to have physical access to data to be its controller (UODO — Which entity should be regarded as the controller).
DPA (Data Processing Agreement) — a data processing agreement under Article 28 GDPR. It governs only situations in which a processor processes data on the controller’s instructions.
Data-sharing agreement — a document governing the transfer of data between two separate controllers, each of which processes it for its own purposes.
The one question that determines which document to use
Before granting anyone access to another group company’s system, answer one question: “whose purpose is it?”
The answer determines everything:
| Answer | Recipient’s role | Required document |
|---|---|---|
| The recipient accesses the data on the instructions of the system controller, pursuing that controller’s purpose | Processor | Data Processing Agreement (DPA) under Article 28 GDPR |
| The recipient accesses the data for its own purposes (oversight, controlling, settlements) | Separate controller | Controller-to-controller data-sharing agreement |
| Both entities jointly determine the purposes and means of processing | Joint controllers | Arrangement under Article 26 GDPR |
Shareholder oversight, margin control, cost allocation and verification of employment terms are the purposes of the parent company. They are not the purposes of the company that operates the system. A DPA governs only processing carried out on instructions. If the parent company reviews data for its own purposes, a DPA is the wrong instrument, regardless of how broadly it is drafted.
The CJEU judgment in the Fashion ID case (C-40/17, 29 July 2019) confirms that joint controllership may cover only a distinct stage of the processing chain and does not extend to operations whose purposes or means an entity does not actually determine (EUR-Lex — CJEU judgment C-40/17). Mere membership of the same corporate group, use of a common brand or technical use of the same system does not automatically create joint controllership.
Why an existing DPA is usually not enough
A typical “mutual” DPA within a corporate group describes the scope of data as “contact and basic details of the parties’ personnel and customers”. Meanwhile, a recruitment and records management system contains:
- Candidates’ CVs (often including special category data under Article 9 GDPR)
- Hourly rates and availability information
- Subcontracting data
- LinkedIn profiles and activity history
This scope goes far beyond the literal wording of a standard DPA. Retrieve the DPA currently in force and compare its description of data categories with what is actually visible in the system. If the agreement refers to “contact details” while the system contains CVs and rates, the agreement does not cover them.
Risks of incorrectly classifying roles within a corporate group
Incorrectly classifying a recipient as a processor rather than a separate controller may trigger several GDPR infringements at the same time. An infringement of Article 6(1) GDPR is subject to Article 83(5)(a) GDPR — the maximum fine is up to EUR 20,000,000 or up to 4% of total worldwide annual turnover (GDPR — Article 83).
a) Legal risk: no legal basis
If the parent company obtains access to data under a DPA but actually processes it for its own purposes, there is no appropriate legal basis under Article 6(1) GDPR. PUODO has imposed both reprimands and substantial financial penalties for such infringements. In 2025, PUODO fined Poczta Polska PLN 27 million for processing without a legal basis (UODO — notice on penalties).
b) Operational risk: excessive access
Granting access to the entire system view — including CVs and the candidate database — “for organisational convenience” violates the data minimisation principle (Article 5(1)(c) GDPR). The company needs three pieces of information: who, for which client and at what rate. Instead, it receives the candidate’s entire profile, including their address, bank account number and employment history.
c) Retention risk
Including “permanent access / until revoked” in the agreement may refer to the term of the arrangement. But the retention period for reports cannot be indefinite — Article 5(1)(e) GDPR requires data to be kept no longer than necessary for the purposes of processing (GDPR — Article 5).
d) Reputational and organisational risk
A discrepancy between the Privacy Statement and what the system actually allows may prompt complaints from employees and consultants. If you have told people that only Company A can see their data while Company B can actually see it too, you have a transparency problem.
| Type of risk | Source | Possible consequence |
|---|---|---|
| No legal basis | Incorrect role classification | Fine of up to EUR 20 million / 4% of turnover |
| Breach of data minimisation | Excessive scope of data | Order to restrict processing |
| Indefinite retention | No defined retention period | Challenge by the supervisory authority or data subject |
| Inconsistent information | Discrepancy between the privacy notice and actual practice | Complaints, PUODO proceedings |
| Business delay | Disorganised documentation | Margin and cost monitoring blocked |
How to share data correctly within a corporate group — step by step
Step 1: determine each party’s role for each process
One DPA “for everything” is not enough. For each processing activity, you must determine separately:
- Who determined the purpose of the processing
- Whether the decision on the purpose was made jointly
- Who decides on the essential means of processing
- Whether one company acts solely on the instructions of the other
Training the people who grant access (IT, HR, administrators) to use the simple “whose purpose is it?” test eliminates most incorrectly executed DPAs within a group.
Step 2: choose the right instrument
Based on the answers from step 1:
| Situation | Instrument |
|---|---|
| Company A operates the system and Company B accesses the data on A’s instructions | DPA (Article 28 GDPR) — update the existing one |
| Company B accesses the data for its own purposes (controlling, oversight) | Controller-to-controller data-sharing agreement |
| Both companies jointly decide on the purposes and means | Joint controller arrangement (Article 26 GDPR) |
Step 3: limit the scope of data to the minimum
Instead of sending full employment contracts, request a report for each individual. A full employment contract contains remuneration, a bank account number, an address and often special category data (Article 9 GDPR). Sending it in full violates the data minimisation principle.
What the report should contain:
- Position
- Remuneration (amount)
- Start and end date
- Hourly rate (if applicable)
- Monthly amount
What to remove:
- Bank account number
- Home address
- Data that may constitute special category data
- CV (a source of Article 9 data — a separate process if there is a distinct purpose)
Check with IT whether the report actually extracts from the system the fields you listed in the data scope appendix. In the cases described, several fields needed to calculate margins were not included in the list of fields provided by the system controller.
Step 4: conduct a Legitimate Interests Assessment (LIA)
The legal basis for sharing data for shareholder oversight may be a legitimate interest (Article 6(1)(f) GDPR). Recital 48 GDPR indicates that undertakings belonging to a group may have a legitimate interest in transmitting personal data within the group for internal administrative purposes (GDPR — Recitals 47–48). However, Recital 48 is an interpretive guideline, not a standalone legal basis.
For each process, conduct a three-stage assessment:
| Stage | Question | Example |
|---|---|---|
| 1. Interest | Is the interest specific and genuine? | Monitoring margins and employment costs at a subsidiary |
| 2. Necessity | Is the processing necessary? Are there alternatives? | A report containing 5 fields instead of full access to the system |
| 3. Balancing | Is the interest overridden by the rights of individuals? | Narrow scope of data, limited group of recipients, technical safeguards |
The broader the scope of the data shared, the higher the required threshold for the legal basis. Data sharing based on Article 6(1)(f) is defensible precisely because of its narrow scope. Data minimisation is not an obstacle — it is an argument that will help justify the data sharing before the supervisory authority.
Note: no published position has been identified from PUODO or the EDPB that directly addresses the transfer of named remuneration data concerning a subsidiary’s employees to its parent company. UODO states that shareholder oversight is not the same as control over processing within the meaning of the GDPR and does not automatically grant access to employee data (UODO — Data protection in the workplace). The permissibility of such a transfer must be assessed on a case-by-case basis.
Step 5: comply with transparency obligations before launch
The following conditions must be met before data sharing begins:
- Provide a privacy notice to the consultants and employees whose data will be seen by the new recipient
- Update the disclosing party’s Privacy Statement so that it reflects how the system actually operates
- Verify that the system’s functionality is consistent with what you communicate to individuals
Article 14(1) GDPR applies where data has not been obtained directly from the individual. The new controller should provide its own privacy notice covering, among other things, the controller’s identity, purpose, legal basis, data categories, source, recipients, retention period and the individual’s rights. The deadline is generally one month after obtaining the data (GDPR — Article 14).
A privacy notice provided to an individual by the first entity does not replace the second controller’s transparency obligations.
Step 6: define the report retention period
Article 74 of the Polish Accounting Act distinguishes between different retention periods: approved annual financial statements — permanently; accounting books and accounting records — generally for 5 years (Accounting Act — Journal of Laws 2023, item 120).
However, “shareholder reports” and “controlling reports” are not categories defined in the Accounting Act. A five-year period is defensible only for documents that form part of accounting books or accounting records.
| Document category | Retention period | Legal basis |
|---|---|---|
| Approved annual financial statements | Permanently | Article 74 of the Accounting Act |
| Accounting books, accounting records | 5 years | Article 74 of the Accounting Act |
| Management / controlling reports | To be determined — e.g. current financial year + settlement period | Article 5(1)(e) GDPR |
| Working copies, dashboards | Delete after use | Data minimisation principle |
Specify a concrete period in the agreement. “Permanent access / until revoked” may refer to the term of the arrangement, but not to data retention.
Step 7: configure the report-sharing tool
Compliance with Article 32 GDPR does not result from the choice of tool — it depends on how the tool is configured. SharePoint is not inherently compliant or non-compliant (UODO — data security, Article 32).
Report repository configuration checklist:
- Dedicated library — not a folder in the general structure
- No inheritance of permissions from the organisation
- Disable “anyone with the link” links
- Permissions assigned by role, not by organisation
- TLS encryption in transit and encryption at rest
- Audit log enabled and retained
- Closed and documented group of recipients
- Retention rule for the library consistent with the period specified in the agreement
Confirm the hosting location of the system and repository. The absence of transfers outside the EEA is something to be confirmed, not assumed by default. If anything is located outside the EEA, this is a separate issue requiring a separate transfer mechanism (Article 46 GDPR).
Step 8: issue authorisations and confidentiality undertakings
Before granting access:
- Issue individual data processing authorisations to every person with access
- Obtain confidentiality undertakings
- Limit the group of recipients to the minimum — with an answer to the question “who exactly and for what purpose”
- Document the controller’s instructions or appendix
An authorisation defines the scope and purpose, is documented and may be withdrawn if responsibilities change or the relationship ends.
When BCRs will not replace a separate agreement
Corporate groups are often tempted to think: “we have BCRs / an intra-group agreement, so that covers all access”. It does not.
BCRs (Article 46(2)(b) and Article 47 GDPR) are a transfer instrument — they are used to transfer data to third countries within a group and require approval from a supervisory authority (UODO — binding corporate rules). BCRs do not replace a Data Processing Agreement (Article 28) or a joint controller arrangement (Article 26).
BCRs are not required for relationships located entirely within the EEA. The appropriate instrument is a Data Processing Agreement or a data-sharing agreement, depending on how the roles are classified.
A document merely called an “intra-group agreement” is not a set of BCRs if it does not meet the requirements of Article 47 and has not been approved by a supervisory authority.
An additional formality that is easy to overlook: if the framework agreement and DPA were signed using outdated entity names following a name change or restructuring, verify the details using extracts from the relevant register and sign an amendment confirming continuity.
We can help you
Putting roles and documentation within a corporate group in order is not a one-off amendment to an agreement. It requires a review covering the classification of roles for each process, comparison of existing DPAs with the actual scope of data in systems, preparation of the appropriate instrument and updates to privacy notices.
We support companies within corporate groups — especially Polish entities with foreign owners — through three service options:
| Option | Scope | Who it is for |
|---|---|---|
| Role classification audit | Review of existing DPAs and access maps, identification of gaps | Companies that want to understand their current position |
| Agreement + privacy notices | Preparation of a data-sharing agreement, updated privacy notices and a data scope appendix | Companies that need a specific document |
| Comprehensive solution | Audit + agreement + tool configuration checklist (Article 32) + retention policy + training for people who grant access | Companies that want to address the issue from start to finish |
We combine GDPR compliance with business context — we understand that the finance department needs data to calculate margins, not to read CVs. We design documentation to enable access, not block it.
Data sharing within a corporate group — key takeaways
Before adding anyone to a group system, answer the question “whose purpose is it”. The answer determines which document to use: a DPA, a data-sharing agreement or a joint controller arrangement.
Limit the scope of data to the minimum — use a report for each individual instead of full employment contracts. Define a report retention period. Update the privacy notice before data sharing begins. Configure the tool in accordance with the Article 32 checklist.
Data minimisation does not prevent shareholder oversight. On the contrary — it gives the data sharing a stronger legal basis.
If you need a review of intra-group agreements, an access map or assistance in preparing a data-sharing agreement, contact us.
Frequently asked questions
We have signed a DPA covering the entire group — doesn’t that cover all access to our systems?
No. A DPA (a Data Processing Agreement under Article 28 GDPR) governs only situations in which a processor processes data on the controller’s instructions. If a group company accesses a system for its own purposes — oversight, controlling or cost allocation — it acts as a separate controller. A data-sharing agreement is required, not a DPA. You should also check whether the literal description of data categories in the DPA covers what is actually visible in the system.
As the majority shareholder, I have the right to know how much we pay people at the subsidiary. Why does the GDPR complicate this?
The GDPR does not prohibit access to this information — it requires the scope of access to be proportionate to the purpose. A full employment contract includes remuneration, but also a bank account number, an address and potentially special category data. Instead of sending complete agreements, prepare a report for each individual containing their position, remuneration, dates and rate. This is sufficient for oversight while also complying with the data minimisation principle. No PUODO position has been identified that explicitly permits or prohibits the transfer of named remuneration data to a parent company — each case requires an individual assessment.
Can I state in the agreement that access is “permanent / until revoked”?
Such a provision may refer to the term of the arrangement (e.g. for as long as the ownership relationship continues). However, the retention period for reports must be specified precisely — Article 5(1)(e) GDPR does not permit indefinite retention of personal data. Consider using the following formula: the current financial year plus the settlement period. Documents forming part of the accounting books may be retained for 5 years under Article 74 of the Accounting Act.
Is SharePoint sufficient for exchanging reports containing remuneration data?
It may be — but compliance with Article 32 GDPR does not result from the choice of tool; it depends on how it is configured. You need a dedicated library with no permission inheritance, no “anyone with the link” links, role-based permissions, an enabled audit log and a retention rule consistent with the agreement. You should also confirm where the repository is hosted — if it is outside the EEA, this is a separate issue requiring a transfer mechanism.
The parent company is based in another EU country — is that a data transfer?
If both companies and the systems are located within the EEA, there is no transfer of data to a third country and you do not need any additional mechanisms under Chapter V GDPR. However, this must be confirmed: check where the system and report repository are hosted. The location of the server, not the company’s registered office, determines whether a transfer takes place.
Who should implement this within the company: Legal, HR or IT?
All three. Legal classifies the roles and prepares the documents. HR updates the privacy notices and provides them to employees and consultants. IT configures system permissions, prepares the report with the correct fields and implements retention rules. Without cooperation between these three departments, the documentation will not be consistent with what actually happens in the system — and that consistency is precisely what the supervisory authority checks.
