You may only share personal data under the GDPR if you have a legal basis under Article 6, have settled in writing whether the recipient is a processor or a controller, and have told the people concerned about the sharing. Those three conditions cover most of what goes wrong. The main exceptions are transfers outside the European Economic Area (EEA) and high-risk processing, which bring extra requirements on top.
In the Netherlands, the Dutch Data Protection Authority (Autoriteit Persoonsgegevens, AP) enforces the GDPR together with the Dutch implementing act (Uitvoeringswet AVG, UAVG). Personal data crosses organisational boundaries all the time: to a cloud provider, a payroll bureau, a marketing agency, a debt collector or a group company abroad. Each of those flows is a separate processing operation that needs its own justification. Below we set out seven risks that recur in practice, the provisions they turn on, and what you can do about each before the AP or a claimant raises the question.
Risk 1: are you sharing data without a valid legal basis?
Every disclosure of personal data needs one of the six legal bases in Article 6(1) GDPR. A commercial reason is not one of them.
The six bases are exhaustive: consent, performance of a contract, a legal obligation, vital interests, a public task and legitimate interests. Article 5(1)(a) adds that processing must always be lawful, fair and transparent. A basis that exists on paper but was never explained to anyone still leaves a gap.
Why is legitimate interest a trap?
Legitimate interests is the basis most often used for sharing with partners and suppliers, and the one most often used incorrectly. It requires a three-step test:
- the interest must be legitimate;
- the sharing must be necessary to serve it;
- the interest must not be overridden by the rights and freedoms of the people concerned.
You must carry out and record this balancing test before the sharing starts. Article 5(2) GDPR puts the burden of showing compliance on the controller (accountability). A legitimate interests assessment written after a complaint arrives is worth very little.
What about consent and purpose limitation?
Two further traps are worth naming. Consent in an employment relationship is rarely valid, because the imbalance of power means it is not freely given. An employer that relies on it for data sharing is usually relying on nothing.
Purpose limitation under Article 5(1)(b) applies to sharing just as much as to the original collection. Data gathered to deliver a service cannot simply be passed to a partner for marketing because the commercial logic is attractive. Where the new purpose is not compatible with the original one, you need a fresh basis.
What to do: before any personal data leaves your organisation, identify the basis, write it down and check that your privacy notice already describes the sharing. If the basis is legitimate interests, the assessment belongs in the file. If it is consent, that consent must be freely given, specific, informed and unambiguous, and as easy to withdraw as it was to give.
Risk 2: have you got the controller and processor roles wrong?
A controller decides the purposes and means of processing; a processor only acts on the controller’s documented instructions (Article 4(7) and (8) GDPR). What counts is who actually decides, not what the contract calls the parties.
Misclassification creates obligations that nobody performs. The common error is to label every supplier a processor. Yet none of the following acts purely on instructions:
- a SaaS provider that uses customer data to improve its own product;
- an accountant bound by professional rules;
- a bank executing a payment;
- an advertising platform that builds its own audience profiles.
Each is a controller in its own right for at least part of the processing. Where two organisations jointly determine the purposes and means, they are joint controllers under Article 26 GDPR. They must set out their respective responsibilities in an arrangement, and the essence of that arrangement must be made available to the people concerned.
How broadly does the EU Court of Justice define joint control?
Broadly. In Fashion ID (C-40/17), the Court of Justice held that a website operator embedding a third-party social plug-in was a joint controller for the collection and transmission of visitors’ data. That was so even though it had no access to the data afterwards and did not decide what happened next. Partial influence over the purposes is enough. The practical consequence is joint liability: you can be held to account for a breach you did not cause and could not see.
What to do: map the data flows first and ask, for each flow, who decides why and how the data is processed. Record the conclusion, then document it correctly. Use a processing agreement under Article 28 for processors and a joint controller arrangement under Article 26 where both parties decide. Where two independent controllers exchange data, ordinary contract terms plus each party’s own compliance will do.
Risk 3: is your data processing agreement missing or defective?
If a processor handles personal data for you, Article 28(3) GDPR requires a written contract. Without it, you are in breach from the moment processing begins, even if nothing goes wrong.
No harm needs to have occurred and no data needs to have leaked. The absence of the agreement is itself the infringement, and it is one of the easiest for a supervisory authority to establish.
The content is prescribed by law, not left to the parties. A compliant data processing agreement must state:
- the subject matter and duration of the processing;
- its nature and purpose;
- the types of personal data and the categories of people concerned;
- the obligations and rights of the controller.
It must also bind the processor to:
- process only on documented instructions;
- impose confidentiality on its staff;
- take the security measures required by Article 32;
- help with requests from data subjects and with breach notification;
- delete or return the data at the end of the engagement;
- give the controller the information needed to demonstrate compliance, and allow audits.
Why do sub-processor clauses so often fail?
Under Article 28(2) and (4), the processor needs your prior specific or general written authorisation for any sub-processor. With a general authorisation, the processor must inform you of intended changes and give you the chance to object.
A clause that simply lets the processor engage anyone it likes does not meet that standard. It is exactly the clause that matters when a chain of suppliers turns out to reach a country nobody assessed.
What to do: work from a template that follows Article 28(3) clause by clause, and review the agreements already in place rather than assuming a supplier’s own terms will do. Long-standing relationships are the most likely to be undocumented, because the paperwork was never a priority when the relationship was young.
Risk 4: are you transferring data outside the EEA without safeguards?
A transfer outside the EEA is only allowed on the basis of an adequacy decision or appropriate safeguards, such as standard contractual clauses. The exceptions in Article 49 are for occasional situations only.
Chapter V GDPR restricts transfers of personal data to countries outside the EEA. A transfer is allowed where the European Commission has adopted an adequacy decision for the destination (Article 45). It is also allowed where appropriate safeguards are in place (Article 46), usually the Commission’s standard contractual clauses (SCCs) or binding corporate rules. The derogations in Article 49, such as explicit consent or necessity for a contract, cannot support a structural data flow.
Businesses often overlook that a transfer takes place whenever data becomes accessible from outside the EEA, not only when it is copied there. A contract with an EU entity does not help if support staff on another continent can open the database. Remote administration by a parent company abroad is a transfer, even if the servers stay in Frankfurt.
What do Schrems II and the Data Privacy Framework mean for you?
In Schrems II (C-311/18), the Court of Justice invalidated the EU-US Privacy Shield. It also held that standard contractual clauses are not enough on their own. The exporter must assess whether the law of the destination country undermines the protection the clauses promise, and add supplementary measures where it does. That transfer impact assessment (TIA) is still required for every transfer based on Article 46.
For the United States the position has changed in one respect. The Commission adopted an adequacy decision for the EU-US Data Privacy Framework (DPF) in July 2023. On 3 September 2025 the General Court of the EU dismissed an action for its annulment (Latombe, T-553/23). Transfers to a US organisation that is actually certified under the framework, for the data covered by its certification, can therefore rely on adequacy. Transfers to any other US recipient cannot. Check the certification rather than assuming it.
What to do: list the third-country transfers hidden in your supply chain, including sub-processors and support arrangements. For each one, establish whether adequacy applies. If not, put the current version of the standard contractual clauses in place, carry out and document a transfer impact assessment, and record the supplementary measures you rely on, such as strong encryption with keys held in the EEA. The AP can order a transfer to be suspended, which is often more disruptive than a fine.
Risk 5: are you skipping a data protection impact assessment?
Article 35 GDPR requires a data protection impact assessment (DPIA) where processing is likely to result in a high risk to individuals. Sharing data often crosses that threshold sooner than organisations expect.
Article 35(3) names three cases expressly:
- systematic and extensive automated evaluation of personal aspects, on which decisions with legal or similarly significant effects are based;
- large-scale processing of special categories of data or of criminal conviction data;
- systematic monitoring of a publicly accessible area on a large scale.
The AP also publishes a list of processing operations for which a DPIA is always required. That list is the first place to look before a new data-sharing project starts.
The requirement is often underestimated because organisations link DPIAs to large projects. In practice, combining datasets from different sources, sharing health or biometric data with an analytics provider, using profiling or automated decision-making, or introducing a tool that observes employees will often cross the threshold on its own.
What must a DPIA contain?
A DPIA is a structured exercise, not a form. It must describe the processing and its purposes, assess necessity and proportionality, identify the risks to the people concerned and set out the measures that address them, including safeguards and security measures.
Where the assessment shows a high residual risk that you cannot reduce, Article 36 requires prior consultation of the AP before the processing starts. Failing to carry out a required DPIA is an infringement in itself, whatever the outcome of the processing would have been.
What to do: screen every new data-sharing arrangement against the Article 35(3) criteria and the AP list. Involve the data protection officer if you have one. Keep the assessment as a living document and revisit it when the processing changes. Where the answer is genuinely unclear, carrying out the DPIA is cheaper than defending the decision not to.
Risk 6: are you telling people too little about the sharing?
Transparency is a separate obligation. You can breach it even where the sharing itself is entirely lawful.
Article 13 GDPR covers data collected from the individual; Article 14 covers data obtained from another source. Both require the controller to state the purposes and legal basis of the processing and the recipients, or categories of recipients, of the personal data.
Privacy notices fail on this point in a predictable way. A sentence saying that data “may be shared with trusted partners” identifies nothing. The notice must name the categories of recipients concretely, such as hosting providers, payroll administrators or credit reference agencies. Where the sharing is with one specific organisation, it is usually clearer to name it. Where data is transferred outside the EEA, Articles 13(1)(f) and 14(1)(f) require the notice to say so, to identify the safeguard relied on and to explain how a copy can be obtained.
What extra applies when you did not collect the data yourself?
Under Article 14 the notice must also state the categories of personal data and their source. You must provide it within a reasonable period and at the latest within one month, or at the first communication with the person if that comes sooner.
Buying a marketing list and using it without ever telling the people on it is one of the clearest breaches there is. Our guidance on drawing up a privacy policy in the Netherlands sets out in full what the notice must contain.
What to do: review the notice whenever a new recipient is added, and update it before the sharing starts, not at the next annual review. Under Article 12(1), notices must also be concise, intelligible and written in clear and plain language. Listing every conceivable recipient in a document nobody can read does not solve the problem.
Risk 7: are you treating pseudonymised data as anonymous?
Pseudonymised data is still personal data. Only true anonymisation takes data outside the GDPR.
Article 4(5) GDPR defines pseudonymisation as processing personal data so that it can no longer be linked to a specific person without additional information, which is kept separately and protected. The definition assumes that linking the data back remains possible. That is what distinguishes it from anonymisation. Recital 26 confirms that data which can still be attributed to a person using additional information stays within the scope of the GDPR.
The risk arises when pseudonymisation is treated as a licence to share freely. Replacing names with customer numbers does not remove the need for a legal basis, a processing agreement, a transfer safeguard or a privacy notice. It matters a great deal who holds the key and which other datasets the recipient has. Pseudonymised records combined with a postcode, a date of birth and a transaction history can often be re-identified. The assessment must consider the means reasonably likely to be used by the recipient, not only by you.
True anonymisation, where re-identification is no longer possible by any means reasonably likely to be used, does take data outside the GDPR. It is also hard to achieve and easy to claim. Aggregation of small groups, unique combinations of attributes and rich behavioural data all defeat it.
What to do: treat data as pseudonymised, and therefore as personal data, unless a documented and technically sound anonymisation process shows otherwise. Record the technical and organisational measures that keep the key separate. The upside is real: Article 32 lists pseudonymisation as an appropriate security measure, and it counts in your favour when a breach is assessed. It reduces the consequences of a leak, but not the obligations that apply before one.
What does enforcement look like in the Netherlands?
The AP can warn, reprimand, order compliance, ban processing, suspend transfers and impose fines of up to EUR 20 million or 4% of worldwide annual turnover. Individuals and foundations can also claim damages.
The AP supervises compliance with the GDPR and the UAVG. It can investigate on its own initiative or after a complaint. Its powers under Article 58 GDPR range from a warning and a reprimand, through an order to bring processing into compliance, to a temporary or permanent ban on processing and an order suspending data flows to a recipient in a third country. A fine is only one of the tools. For a business that depends on a particular data flow, it is rarely the most damaging one.
How high can a fine be?
Article 83 GDPR has two tiers of maximum fines. In each tier the maximum is a fixed amount or a percentage of total worldwide annual turnover in the previous financial year, whichever is higher.
- Lower tier: up to EUR 10 million or 2% of turnover, for breaches of obligations such as those in Articles 25 to 39. That includes the absence of a processing agreement or a required DPIA.
- Higher tier: up to EUR 20 million or 4% of turnover, for breaches of the basic principles, the legal bases, the rights of data subjects and the rules on international transfers.
For a group of companies, the percentage rather than the fixed amount is usually the relevant figure. Article 83(2) lists the factors that decide the amount, including the nature and duration of the infringement, whether it was intentional or negligent, the steps taken to limit the damage and the degree of cooperation with the authority.
Can individuals claim damages?
Yes. Article 82 GDPR gives anyone who has suffered material or non-material damage a right to compensation from the controller or processor.
In the Netherlands, such claims are increasingly brought collectively by foundations acting for large groups, under the Act on the settlement of mass damages in collective actions (Wet afwikkeling massaschade in collectieve actie, WAMCA). A published AP decision is a convenient starting point for such a claim.
What if unlawful sharing leads to a data breach?
A personal data breach brings its own timetable. Article 33 GDPR requires notification to the AP without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals.
Under Article 34, you must also inform the people affected without undue delay if the breach is likely to result in a high risk to them. All breaches must be documented internally, including those you do not notify, and the reasoning for not notifying is part of that record.
How do you bring your data sharing into order?
Start from your record of processing activities, and check each recipient for role, legal basis, contract, transfers and privacy notice. Then build these checks into your procurement process.
The seven risks above share one cause. Sharing is arranged operationally, by the team that needs the data to move, and documented afterwards or not at all. The remedy is equally practical:
- Start from the record. The record of processing activities under Article 30 must already exist, and it forces you to name every recipient.
- Check every recipient. For each one, establish the role, the legal basis, the contract, the transfer position and what the privacy notice says. Most organisations find two or three flows nobody can account for.
- Build it into procurement. Make sure no supplier can be onboarded without a processing agreement, a transfer analysis and a DPIA screening, and give someone the authority to stop an onboarding that fails.
- Review on change. Look again when a new sub-processor, a new purpose or a new country appears, or when an acquisition brings someone else’s data flows into the group.
Article 5(2) requires you to be able to demonstrate compliance, which is an obligation about records as much as about conduct. For contracts with IT suppliers specifically, our IT law practice explains how the data protection terms interact with the commercial ones.
In summary
- Every sharing of personal data needs a legal basis under Article 6 GDPR; a commercial reason is not enough.
- Determine for each recipient whether it is a processor, a joint controller or an independent controller, and document it accordingly.
- A processing agreement under Article 28 is mandatory for processors; without one you are in breach from day one.
- Transfers outside the EEA need adequacy (such as a DPF certification) or safeguards plus a transfer impact assessment.
- Pseudonymised data is still personal data; your privacy notice must name the recipients concretely.
Frequently asked questions
When is data sharing under the GDPR permitted?
Only if you have a valid legal basis under Article 6 GDPR: consent, performance of a contract, a legal obligation, vital interests, a public task or legitimate interests. You must also respect the principles in Article 5, such as lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality. In practice: document why you share the data, check that the purpose fits the reason you collected it, and inform the people concerned.
What’s the difference between a controller and a processor?
A controller decides the purposes and means of processing personal data. A processor processes the data on behalf of the controller and on its instructions. Controllers carry the main responsibility for GDPR compliance; processors have more limited duties, mainly security, confidentiality and following instructions. A payroll provider or cloud storage service is usually a processor. A supplier that also uses the data for its own purposes may be a controller or joint controller. Getting the roles wrong leads to gaps in accountability and can create joint liability.
When is a data processing agreement (DPA) mandatory?
Whenever you engage a processor to handle personal data on your behalf (Article 28 GDPR), whatever the size of your organisation or the volume of data. The agreement must be in writing and contain the mandatory content, such as the subject matter, duration, nature and purpose of the processing, the types of data and people concerned, and the obligations on security, breach notification and sub-processors. Without a compliant agreement you are in breach from the moment processing starts, even if nothing goes wrong.
Can I share customer data with a party outside the EU?
Yes, but only on strict conditions. Under Articles 44 to 49 GDPR you need an adequacy decision for the destination, or appropriate safeguards such as standard contractual clauses. Since Schrems II, safeguards require a transfer impact assessment to check whether local law, such as government surveillance, undermines the protection, and supplementary measures such as encryption where it does. For US recipients certified under the EU-US Data Privacy Framework, the adequacy decision applies. Unsafe transfers can lead the AP to order their suspension.
When is a DPIA required for data sharing?
When the processing is likely to result in a high risk to the rights and freedoms of individuals (Article 35 GDPR). Examples are large-scale processing of special categories of data such as health, biometric or genetic data, systematic monitoring of public areas, automated decision-making with legal or similar effects, and the use of new technologies. Combining datasets, sharing sensitive information or using data for profiling or AI analytics often triggers a DPIA. Check the AP list; if in doubt, carry one out.
What fines can companies face for breaching the GDPR?
The GDPR has two tiers. The lower tier, up to EUR 10 million or 2% of worldwide annual turnover, covers breaches such as inadequate security or a missing DPIA or processing agreement. The higher tier, up to EUR 20 million or 4% of turnover, covers breaches such as processing without a legal basis, unlawful international transfers and violations of data subjects’ rights. In both tiers the higher of the two amounts applies. The AP sets the amount based on factors such as the nature and seriousness of the breach, intent or negligence, the number of people affected and the steps you took.
Is pseudonymised data always safe to share?
No. Pseudonymisation reduces the risk but does not remove the GDPR. If the data can still be linked back to a person, for example with additional information held by you or the recipient, it remains personal data (Article 4(5) GDPR and recital 26). You still need a legal basis, must inform the people concerned and must secure the data properly. Only true anonymisation, where re-identification is no longer reasonably possible, takes data outside the GDPR, and that is difficult to achieve.
What should I do if my business has a data breach due to unlawful data sharing?
Contain the breach, assess its scope and impact, and document what happened and what you are doing about it. Notify the AP without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals (Article 33 GDPR). If the breach is likely to result in a high risk to the people affected, inform them without undue delay as well (Article 34). Failing to notify is a separate infringement that can lead to its own fine.
How can we help with data sharing and the GDPR?
Law & More advises businesses in the Netherlands on the legal side of data sharing. We determine controller and processor roles, draft and negotiate processing agreements and joint controller arrangements, assess transfers outside the EEA, carry out data protection impact assessments and update privacy notices. We also assist organisations under investigation by the AP or that must notify a data breach against a running deadline.
Are you unsure whether a particular data flow can be justified, or are you entering into an arrangement in which personal data will move between organisations? It pays to look at the position before the sharing begins. Unsure where you stand? Tell us about your situation. We will let you know your options within one working day.
