7 GDPR რისკები პერსონალური მონაცემების მესამე მხარეებთან გაზიარებისას

Sharing personal data under the GDPR is lawful only where the organisation that discloses the data can point to a legal basis under Article 6, has settled in writing whether the recipient is a processor or a controller, and has told the individuals concerned that the sharing takes place. Those three conditions cover most of what goes wrong. The Dutch supervisory authority, the Autoriteit Persoonsgegevens (AP), enforces the GDPR alongside the Dutch implementing act, the Uitvoeringswet AVG (UAVG), and Article 83 GDPR sets the maximum fines at the higher of a fixed ceiling or a percentage of worldwide annual turnover.

Personal data crosses organisational boundaries constantly: to a cloud provider, a payroll bureau, a marketing agency, a debt collector, a group company abroad. Each of those flows is a separate processing operation that has to be justified on its own terms. This article sets out seven risks that recur in practice, the provisions they turn on, and what a business in the Netherlands can do about each one before the AP or a claimant raises the question.

Sharing without a valid legal basis

Every disclosure of personal data requires a legal basis under Article 6(1) GDPR, and 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 in any event be lawful, fair and transparent, so a basis that exists on paper but was never explained to anyone still leaves a gap.

Legitimate interests is the basis most often invoked for sharing with partners and suppliers, and it is the one most often invoked incorrectly. It requires a three-stage assessment: the interest must be legitimate, the processing must be necessary to serve it, and the interest must not be overridden by the rights and freedoms of the individuals concerned. That balancing exercise has to be carried out before the sharing starts and recorded, because Article 5(2) puts the burden of demonstrating compliance on the controller. A legitimate interests assessment written after a complaint arrives is worth very little.

Two further traps are worth naming. Consent obtained in an employment relationship is rarely valid, because the imbalance of power means it is not freely given, and an employer that relies on it for data sharing is usually relying on nothing. And purpose limitation under Article 5(1)(b) applies to the sharing 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, a fresh basis is needed.

Before any personal data leaves the organisation, identify the basis, write it down, and check that the privacy notice already describes the sharing. If the basis is legitimate interests, the assessment belongs in the file. If it is consent, the consent must be freely given, specific, informed and unambiguous, and it must be as easy to withdraw as it was to give.

Getting the controller and processor roles wrong

A controller determines the purposes and means of processing; a processor acts only on the controller’s documented instructions (Article 4(7) and (8) GDPR). The roles are not a matter of what the contract calls the parties but of who actually decides, and misclassification produces obligations that nobody performs.

The common error is to label every supplier a processor. 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: none of these acts purely on instructions, and 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 and must set out their respective responsibilities in an arrangement whose essence is made available to data subjects.

The Court of Justice has drawn the line broadly. In Fashion ID (C-40/17) it held that a website operator embedding a third-party social plug-in was a joint controller for the collection and transmission of visitors’ data, 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: an organisation can answer for a breach it did not cause and could not see.

Map the data flows first and ask, for each one, who decides why the data is processed and how. Record the conclusion, then paper it correctly: a processing agreement under Article 28 for processors, a joint controller arrangement under Article 26 where both parties decide, and nothing more than ordinary contractual terms plus each party’s own compliance where two independent controllers exchange data.

A missing or defective data processing agreement

Where a processor handles personal data on your behalf, Article 28(3) GDPR requires a written contract, and the breach is complete from the moment processing begins without one. 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 rather than left to the parties. A compliant მონაცემთა დამუშავების ხელშეკრულება must state the subject matter and duration of the processing, its nature and purpose, the types of personal data and the categories of data subjects, and the obligations and rights of the controller. It must bind the processor to process only on documented instructions, to impose confidentiality on its staff, to take the security measures required by Article 32, to assist with data subject rights and with breach notification, and to delete or return the data at the end of the engagement. It must also give the controller the information needed to demonstrate compliance and allow audits.

Sub-processing is where standard templates most often fail. Article 28(2) and (4) require the controller’s prior specific or general written authorisation for any sub-processor, and where a general authorisation is given the processor must inform the controller of intended changes and give it the opportunity to object. A clause that simply permits the processor to engage anyone it likes does not meet that standard, and it is precisely the clause that matters when a chain of suppliers turns out to reach a country nobody assessed.

Work from a template that tracks Article 28(3) clause by clause, and review the agreements already in place rather than assuming that 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.

Transferring data outside the EEA without safeguards

Chapter V GDPR restricts transfers of personal data to countries outside the European Economic Area. A transfer is permitted where the European Commission has adopted an adequacy decision for the destination (Article 45), or where appropriate safeguards are in place (Article 46), typically the Commission’s standard contractual clauses or binding corporate rules. The derogations in Article 49, such as explicit consent or necessity for a contract, are for occasional situations and cannot carry a structural data flow.

Businesses commonly overlook that a transfer occurs 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 in another continent can open the database, and remote administration by a parent company abroad is a transfer even when the servers stay in Frankfurt.

The Schrems II judgment (C-311/18) invalidated the EU-US Privacy Shield and held that standard contractual clauses are not sufficient on their own: the exporter must assess whether the law of the destination country undermines the protection the clauses promise, and must add supplementary measures where it does. That transfer impact assessment remains a requirement for every transfer that rests on Article 46. For the United States the position has since changed in one respect: the Commission adopted an adequacy decision for the EU-US Data Privacy Framework in July 2023, and the General Court dismissed an action for its annulment in September 2025. Transfers to a US organisation that is actually certified under the framework, for the categories of data covered by its certification, can therefore rely on adequacy. Transfers to any other US recipient cannot, and the certification has to be checked rather than assumed.

Inventory the third-country transfers hidden in the supply chain, including sub-processors and support arrangements. For each, 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 relied on, such as strong encryption with keys held in the EEA. The AP can order a transfer to be suspended, which is a more disruptive outcome than a fine.

Skipping a data protection impact assessment

Article 35 GDPR makes a data protection impact assessment (DPIA) mandatory where a processing operation is likely to result in a high risk to the rights and freedoms of individuals. 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, and systematic monitoring of a publicly accessible area on a large scale. The AP publishes a list of processing operations for which it considers a DPIA compulsory, and that list is the first place to look before a new data-sharing project starts.

The requirement is routinely underestimated because organisations associate DPIAs with large projects. In practice, combining datasets from different sources, sharing health or biometric data with an analytics provider, deploying profiling or automated decision-making, or introducing a tool that observes employees will often cross the threshold on its own.

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 data subjects and set out the measures that address them, including safeguards and security measures. Where the assessment shows a high residual risk that the controller cannot mitigate, 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.

Screen every new data-sharing arrangement against the Article 35(3) criteria and the AP list, involve the data protection officer where one has been appointed, and keep the assessment as a living document that is revisited when the processing changes. Where the answer is genuinely unclear, carrying out the DPIA is cheaper than defending the decision not to.

Telling data subjects too little about the sharing

Transparency is a standalone obligation, and a breach of it survives even where the sharing itself was entirely lawful. Article 13 GDPR governs data collected from the individual and Article 14 data obtained from another source, and 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 has to name the categories of recipients concretely, such as hosting providers, payroll administrators or credit reference agencies, and where the sharing is with a specific named 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 and to identify the safeguard relied on and how a copy of it can be obtained.

Article 14 goes further where data was not obtained from the individual: the notice must also state the categories of personal data concerned and the source they came from, and it must be provided within a reasonable period and in any event within one month, or at the latest at the first communication with the individual if that comes sooner. Buying a marketing list and using it without ever telling the people on it is one of the clearest breaches available. Our guidance on drawing up a კონფიდენციალურობის პოლიტიკა ნიდერლანდებში sets out what the notice has to contain in full.

Review the notice whenever a new recipient is added, and update it before the sharing begins rather than at the next annual review. Notices must also be concise, intelligible and in clear and plain language under Article 12(1), which rules out solving the problem by listing every conceivable recipient in a document nobody can read.

Treating pseudonymised data as anonymous

Pseudonymised data is personal data. Article 4(5) GDPR defines pseudonymisation as processing personal data so that it can no longer be attributed to a specific person without additional information, which is kept separately and subject to safeguards. The definition assumes that the attribution remains possible; that is what distinguishes it from anonymisation, and recital 26 confirms that data which can still be attributed to an individual by the use of additional information remains within the scope of the Regulation.

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 what other datasets the recipient has: a set of pseudonymised records combined with a postcode, a date of birth and a transaction history is frequently re-identifiable, and the assessment must take account of 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 genuinely difficult to achieve and easy to claim. Aggregation of small groups, unique combinations of attributes and rich behavioural data all defeat it. Treat data as pseudonymised, and therefore as personal data, unless a documented and technically sound anonymisation process says otherwise, and 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 the organisation’s favour when a breach is assessed. It reduces the consequences of a leak. It does not reduce the compliance obligations that apply before the leak.

What enforcement looks like in the Netherlands

The AP supervises compliance with the GDPR and the UAVG and can investigate on its own initiative or after a complaint. Its powers under Article 58 GDPR run from a warning and a reprimand through an order to bring processing into compliance, to a temporary or definitive ban on processing and an order suspending data flows to a recipient in a third country. An administrative fine is only one of the instruments, and for a business dependent on a particular data flow it is rarely the most damaging one.

Article 83 sets two tiers of maximum fines: the lower tier applies to breaches of obligations such as those in Articles 25 to 39, including the absence of a processing agreement or a DPIA, and the higher tier to breaches of the basic principles, the legal bases, data subject rights and the rules on international transfers. Each tier is expressed as a fixed ceiling or a percentage of total worldwide annual turnover in the preceding financial year, whichever is higher, so for a group of companies the percentage rather than the ceiling is usually the operative figure. Article 83(2) lists the factors that determine the amount, including the nature and duration of the infringement, whether it was intentional or negligent, the measures taken to mitigate the damage and the degree of cooperation with the authority.

Regulatory action is not the only exposure. Article 82 GDPR gives any person who has suffered material or non-material damage a right to compensation from the controller or processor, and in the Netherlands such claims are increasingly brought collectively under the Wet afwikkeling massaschade in collectieve actie (WAMCA) by foundations acting for large groups. A decision of the AP, once published, is a convenient starting point for such a claim.

A personal data breach caused by unlawful sharing brings its own timetable. Article 33 requires notification to the AP without undue delay and, where feasible, within 72 hours of becoming aware of the breach, unless it is unlikely to result in a risk to individuals. Article 34 requires the affected individuals to be informed without undue delay where the breach is likely to result in a high risk to them. All breaches must be documented internally, including those that are not notified, and the reasoning for not notifying is part of that record.

Bringing a data-sharing arrangement into order

The seven risks above share a single 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 a current record of processing activities under Article 30, which already has to exist and which forces every recipient to be named. For each recipient, establish the role, the legal basis, the contractual instrument, the transfer position and what the privacy notice says. Most organisations find two or three flows that nobody can account for.

Build the assessment into the procurement process so that a supplier cannot 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 the position when the arrangement changes: a new sub-processor, a new purpose, a new country, or an acquisition that brings someone else’s data flows into the group. The obligation under Article 5(2) is to be able to demonstrate compliance, and that is an obligation about records as much as about conduct. For contracts with IT suppliers specifically, our IT სამართალი practice sets out how the data protection terms interact with the commercial ones.

ხშირად დასმული შეკითხვები

Legal advice on data sharing and the GDPR

Law & More advises businesses in the Netherlands on the legal side of data sharing: determining controller and processor roles, drafting and negotiating processing agreements and joint controller arrangements, assessing transfers outside the EEA, carrying out data protection impact assessments and updating privacy notices. We also assist organisations that are the subject of an AP investigation or that have to notify a personal data breach under a running deadline.

If you are uncertain whether a particular data flow can be justified, or you are entering into an arrangement in which personal data will move between organisations, you are welcome to contact us to discuss the position before the sharing begins.