Navigating Third-Party Data Sharing and Transfers in the Age of GDPR

According to data from the International Association of Privacy Professionals (IAPP), approximately 90% of organizations now outsource the processing of personal data to third-party vendors for essential functions like cloud hosting, payroll, and analytics. This means that personal data is frequently shared among multiple parties as part of ordinary business operations. Under the GDPR, giving another entity access to personal data, even where that access is limited, indirect, or remote, constitutes ‘processing’ and triggers specific legal obligations.

The GDPR does not regulate third-party access to personal data through a single, uniform set of rules. Instead, the applicable obligations depend on how each party is classified (controller, joint controller, or processor), the contractual nature of the relationship, and whether personal data is accessed from or made available to entities outside the European Union or European Economic Area.

While the core principles of the GDPR are well-established, practical uncertainties still exist. Especially evolving realities of modern data sharing, including complex vendor ecosystems, cross-border remote access, and ongoing court decisions and regulatory interpretations that continue to shape how the rules apply in practice. This article addresses these uncertainties by breaking down third-party data sharing and transfers, and also touches on how to stay compliant when data travels through complex global supply chains.

What Constitutes Third-Party Data Sharing Under GDPR

The GDPR does not define “third-party data sharing” as a standalone legal concept. Instead, it regulates data sharing through its broader rules on the processing and disclosure of personal data. Article 4(2) defines processing to include “disclosure by transmission, dissemination, or otherwise making available” personal data.

In practical terms, third-party data sharing occurs whenever an organisation makes personal data accessible to another legally distinct entity. The decisive factor is access, not where the data is stored, ownership of the data, or the technical method used. If that entity can view, receive, or otherwise use personal data as a result of that disclosure, data sharing has taken place under the GDPR and triggers the requirement for rigorous case-by-case assessments.

Internal Use vs Third-Party Access

Under the GDPR, whether access to personal data is considered “internal” or “third-party” depends on legal identity. Article 4(10) treats any natural or legal person, public authority, agency or body outside the controller, processor, or persons acting under their authority as a separate party. Processing is internal only where personal data is accessed within the same legal entity, even if multiple departments, teams, or employees are involved. Third-party data sharing arises where access is granted to legally distinct entities. This includes companies within a corporate group that were registered as separate entities. The European Data Protection Board(EDPB) has consistently clarified that companies within the same corporate group are not automatically considered a single controller and cannot rely on group membership alone to treat data access as internal.

Controllers and Processors in Third-Party Sharing

Once personal data is shared with a third party, the GDPR requires organisations to determine who is legally responsible for the processing. This responsibility is defined through role classification: controller, processor, or, in some cases, joint controller. Misunderstanding these roles is one of the most common sources of GDPR non-compliance in third-party data sharing.

i). Sharing Data With Processors vs Other Controllers

With GDPR, who you share data with affects what obligations apply. The distinction between a processor and a controller determines the legal responsibilities, documentation requirements, and exposure to regulatory scrutiny. As set out in Articles 4(7) and 4(8), a data controller decides why and how personal data is processed, while a data processor acts only on the controller’s instructions without determining purposes independently. And regulators make it clear that the role classification must reflect actual behaviour, not contract labels.

Where the receiving party determines its own purposes or means of processing, for example, combining the shared data with its own datasets for independent analytics or advertising, that party acts as a separate or joint controller. Even if both parties benefit from the processing, they are separate controllers if each independently decides why and how the data is used.

Recent guidance from the European Data Protection Board (EDPB) reinforces that controllers must know the identity, role, and responsibility of each processor and sub-processor in the processing chain and cannot abdicate this responsibility. Controllers must have up-to-date information on all parties that process data on their behalf. This comes as regulators have increasingly targeted misclassification in enforcement actions, particularly in advertising and analytics integrations, where third parties were treated as processors in contracts but acted as controllers in practice.

ii). Misclassification Creates GDPR Compliance Gaps

When an entity is incorrectly treated as a processor:

• Controllers may rely on inappropriate legal bases for sharing.
• Transparency notices may fail to inform data subjects of who is responsible for processing.
• Obligations such as joint controllership disclosures may be bypassed.
• Accountability documentation becomes inaccurate.

In addition, recent enforcement actions, most notably the May 2025 Belgian Market Court ruling on IAB Europe, demonstrate these risks. In that case, the misclassification of the entity’s role led to total transparency failure and the absence of a valid legal basis. Similarly, complaints by advocacy groups like NOYB against TikTok, Grindr, and AppsFlyer in late 2025 highlight how major players continue to facilitate unlawful tracking and sensitive data sharing through third-party tools while evading their primary GDPR accountability duties.

Because of such trends, GDPR compliance gaps caused by role misclassification are now a key focus in enforcement. Meaning controllers that cannot demonstrate they understood and documented the role of each third party expose themselves to investigation, fines, and mandated changes to data sharing practices.

Data Sharing vs International Data Transfers

Under the GDPR, data sharing and international data transfers are related but distinct concepts. Not all third-party data sharing automatically counts as a cross-border transfer, and not all remote access triggers transfer requirements.

When Third-Party Access Becomes an International Data Transfer

Chapter V of the GDPR states that third-party access to personal data becomes an international data transfer only where specific conditions are met. According to guidance from the European Data Protection Board (EDPB), a transfer occurs when:

• A controller or processor subject to the GDPR is involved in the processing;
• That entity discloses or otherwise makes personal data available to another controller, joint controller, or processor; and
• The recipient is located outside the European Economic Area (EEA) or is an international organization.

Where all three elements are present, GDPR transfer rules apply. This means additional safeguards, such as an adequacy decision, Standard Contractual Clauses, or another Chapter V mechanism, are required in addition to general GDPR compliance obligations.

Note that data stored in the EEA accessed from outside the EEA by an external party remotely, through remote login, API access, or cloud-based tools, also qualifies as an international transfer under GDPR. This interpretation was solidified by the Court of Justice of the EU (CJEU) in the Schrems II ruling and clarified in the European Data Protection Board’s (EDPB) guidelines, which explicitly state that remote access to data by an “importer” (a separate legal entity) in a third country (non-EEA) is a transfer, triggering the full requirements of Chapter V of the GDPR.

However, not all third-party data sharing meets this threshold, and this distinction is often misunderstood. Third-party access does not constitute an international data transfer where:

i). Access is purely internal within the same legal entity
Remote access by an organization’s own staff while abroad is not a transfer because the data stays within the same legal entity. For example, an EU employee accessing their company’s database while travelling in the US is performing internal processing. While no formal transfer safeguards, are required, the organization must still ensure the connection is secure under Article 32

ii). A non-EEA entity collects data directly from individuals
When an individual in the EU provides their data directly to a non-EEA organization, for example, booking a US hotel or signing up for a foreign app, no “transfer” occurs. Because the individual is not a controller or processor, the Chapter V transfer requirements are not triggered. However, the non-EEA organization may still be directly bound by GDPR rules under Article 3 if they target EU residents.

GDPR Requirements for Third-Party Data Sharing and Transfers

With GDPR, sharing personal data with a third party is a regulated activity. Meaning, it is only allowed when certain basic legal requirements are met. They include;

i) A Valid Lawful Basis for the Sharing

Personal data can only be shared if a specific lawful basis under Article 6 covers the disclosure itself, not just the initial collection. Under 2026 standards, one must ensure the “purpose of sharing” is compatible with the original “purpose of collection.”

Common lawful bases include:

• Contractual Necessity: Sharing is essential to deliver the service the user, or data subject, requested.
• Legal Obligation: Sharing required by law, such as reporting to tax authorities or law enforcement.
• Legitimate Interests: Sharing for a genuine business purpose, provided you have conducted a Legitimate Interest Assessment (LIA) to ensure your interests do not override the individual’s privacy rights.
• Explicit Consent: Required for sharing sensitive “Special Category” data or for high-risk tracking and profiling.

If there is no lawful basis for the sharing, the disclosure is not allowed under the GDPR.

ii) Clear identification of roles

Before sharing data, organisations must determine the role of the third party under the GDPR. A controller decides why and how personal data is used, while a processor handles personal data only on behalf of a controller and follows its instructions. There are also Joint controllers who jointly determine purposes and means and must transparently allocate responsibilities. These roles are based on how the data is actually used, not on job titles or contract wording. Getting this wrong can lead to GDPR compliance gaps.

iii) Mandatory Data Processing Agreements for Processors

Where a third party acts as a processor, Article 28 GDPR requires a binding written agreement that includes specific, non-negotiable terms.

At a minimum, the contract must:

• limit processing to documented instructions,
• impose confidentiality obligations,
• require appropriate technical and organizational security measures,
• regulate the use of sub-processors,
• require assistance with data subject rights,
• mandate breach notification procedures,
• and ensure secure deletion or return of data at the end of the service.

Generic commercial agreements or vague data protection clauses are not sufficient to meet these requirements. In fact, supervisory authorities view the DPA as a roadmap for liability. A primary example of this is the 2025 case, the Danish Data Protection Agency (Datatilsynet) found that a processor (EG A/C — a service provider for several Danish municipalities) violated the GDPR by engaging a sub-processor without the controller’s prior written authorisation as required under Article 28(2) GDPR. The subcontracted entity was ServiceNow, which was not listed or approved in the agreement between the municipalities (data controllers) and EG Without these specific Article 28 terms, the agreement is legally void under GDPR, leaving the controller fully liable for any errors the processor makes.

iv) Transparency Toward Data Subjects

Controllers must clearly disclose third-party data sharing in accordance with Articles 13 and 14 GDPR.

This includes informing individuals about:

• the identity or categories of third-party recipients,
• the purpose of the disclosure,
• the lawful basis relied upon,
• and whether data may be accessed from outside the EU/EEA.

Failure to accurately describe third-party sharing in privacy notices has been a recurring issue in supervisory authority investigations, particularly where disclosures are framed in broad or ambiguous terms that do not reflect actual data flows.

v) Due Diligence and Selection of Third Parties

The GDPR imposes an accountability obligation on controllers to ensure that third parties provide sufficient guarantees of compliance. This includes assessing security measures before granting access, verifying GDPR awareness and operational readiness, and, most importantly, monitoring ongoing compliance where appropriate. Controllers cannot delegate responsibility simply by outsourcing processing activities. Liability remains with the controller for unlawful or inadequately governed sharing.

vi) Security of shared personal data

Articles 5(1)(f) and 32 GDPR require personal data to be protected against unauthorised access, disclosure, alteration, or loss. This obligation does not end once data is shared with a third party. On the contrary, sharing data increases the number of people, systems, and environments that can potentially access it, which in turn increases the risk of misuse or compromise.

When personal data is shared with third parties, controllers must ensure that security is embedded into how the data is accessed and handled in practice. This includes implementing appropriate access controls so that only authorised personnel can view or process the data, maintaining system security through measures such as encryption, patch management, and secure authentication, and limiting the amount of data shared to what is strictly necessary for the intended purpose. Safeguards must also prevent third parties from accessing data in ways that go beyond the agreed scope of the processing.

Importantly, GDPR does not impose a one-size-fits-all security standard. Security measures must reflect the nature of the personal data involved, the likelihood and severity of potential harm to individuals, and the specific processing context. For example, sharing basic contact details for customer support does not carry the same risk profile as sharing financial, health, or location data, and the level of technical and organisational protection must be adjusted accordingly.

vii) Preservation of data subject rights

Third-party data sharing must not interfere with the exercise of data subject rights under Chapter III GDPR. From an individual’s perspective, their rights do not change simply because their personal data has been shared with another organisation. They are still entitled to access, correct, delete, or otherwise control their data in the same way as if it were held only by the original controller.

Controllers must therefore ensure that processors and other third parties are technically and organisationally capable of supporting data subject rights in practice. This includes the ability to locate personal data promptly, correct inaccuracies, delete or restrict data when required, and transmit data in a portable format where applicable. If third parties lack the systems or procedures to respond to rights requests, compliance becomes impossible regardless of how well the controller handles the request internally.

Crucially, responsibility for compliance with data subject rights cannot be shifted to third parties. Even where a processor or partner causes delays or failures, supervisory authorities will hold the controller accountable for ensuring that effective rights mechanisms are in place across the entire data sharing chain. But the processor can be directly sued or fined by regulators if they negligently interfere with a rights request or fail to delete data as instructed.

Additional GDPR Requirements for Third-Party Access Outside the EU/EEA

When personal data that falls under the GDPR is made available to a third party located outside the EU/EEA, additional legal obligations arise that go beyond the core requirements for third-party sharing. These obligations are set out in Chapter V of the GDPR and are designed to ensure that personal data continues to be protected at a level essentially equivalent to that guaranteed within the EU/EEA, even when it is accessed, used, or processed in a jurisdiction with differing data protection laws.

Basically, international access or disclosure of personal data is not automatically permitted merely because the sharing is lawful under the basic rules (such as lawful basis, transparency, and security). Instead, such access is allowed only if the conditions in Chapter V are satisfied in addition to those basic requirements.

a) Valid Transfer Mechanisms Under Chapter V

Controllers and processors that make personal data available outside the EU/EEA must ensure that one of the following conditions is met:

i) Adequacy Decisions (Article 45)

An Adequacy Decision under Article 45 is the “gold standard” for international data sharing. It is a formal recognition by the European Commission that a non-EEA country provides a level of protection essentially equivalent to the GDPR. When a country is deemed adequate, data flows to it are treated like intra-EU transfers, requiring no additional safeguards, Standard Contractual Clauses (SCCs), or complex Transfer Impact Assessments (TIAs).

This status is not permanent and is reviewed every four years to ensure the third country’s surveillance and privacy laws haven’t regressed. As of 2026, the list of adequate jurisdictions includes the UK, Japan, South Korea, Canada, and New Zealand, as well as the EU-U.S. Data Privacy Framework for certified American companies.

Relying on adequacy significantly reduces compliance costs and legal risks. However, organizations must remain vigilant; if a country’s adequacy is revoked or suspended—as seen in past challenges to U.S. data flows, controllers must immediately implement alternative legal mechanisms to avoid unlawful processing. Always verify the current status on the European Commission’s official adequacy list.

ii) Appropriate Safeguards (Article 46)

In the absence of an adequacy decision, personal data may still be accessed or transferred to a third country if appropriate safeguards are in place. These safeguards must provide binding and enforceable rights for individuals and ensure that the data continues to benefit from protections equivalent to those under the GDPR.

Common appropriate safeguards include:

Standard Contractual Clauses (SCCs): They are standardized, non-negotiable contract terms that bridge the legal gap between the EU and “third countries” that lack an adequacy decision. By signing SCCs, the data importer legally commits to treating the data according to European standards, regardless of their own local laws.

However, since the landmark Schrems II ruling, SCCs are no longer a “sign-and-forget” solution. Organizations are now legally required to perform a Transfer Impact Assessment (TIA) to determine if the recipient country’s government surveillance laws, such as FISA 702 in the U.S., could override the protections in the contract. If a risk is identified, the clauses alone are considered insufficient.

To remain compliant in 2026, exporters must often implement supplementary measures alongside SCCs. These typically include technical safeguards like end-to-end encryption, where the importer cannot access the keys, or pseudonymization. If a TIA reveals that no combination of clauses and safeguards can prevent unlawful government access, the data sharing must be suspended.

Binding Corporate Rules (BCRs): They serve as a “premium” compliance mechanism for multinational corporate groups. They are internal, legally binding codes of conduct that commit every entity within a global organization, including those in “third countries,” to apply the same rigorous GDPR-level standards. Unlike standard contracts, BCRs must be formally reviewed and approved by a lead Supervisory Authority through a rigorous coordination process, ensuring that the group’s governance, staff training, and complaint-handling mechanisms are robust enough to protect data subjects worldwide.

However, BCRs are not a “set-and-forget” solution. Following the standards reinforced by the Schrems II ruling, organizations using BCRs must still conduct Transfer Impact Assessments (TIAs) for each jurisdiction where a group entity operates. This is to ensure that local surveillance laws do not override the privacy commitments made in the BCRs. If a subsidiary in a high-risk country cannot fulfill the BCR requirements due to local law, the group must implement supplementary technical measures, such as advanced encryption, to bridge the gap.

iii) Derogations for Specific Situations (Article 49)

There are limited exceptions that permit personal data to be transferred outside the EU/EEA in the absence of an adequacy decision or appropriate safeguards. They are designed to address exceptional or unavoidable situations, not routine or ongoing data transfers.

Article 49 allows transfers in specific circumstances, such as where the individual/data subject has given explicit, informed consent, where the transfer is necessary for the performance of a contract, or where it is required for important reasons of public interest. These derogations apply on a case-by-case basis and are typically intended for one-off or occasional transfers.

Crucially, supervisory authorities interpret Article 49 strictly. Organisations cannot rely on derogations to justify regular, large-scale, or systematic transfers, nor can they use them as a long-term alternative to adequacy decisions or Article 46 safeguards. For example, a company cannot rely on “contractual necessity” to justify the systematic use of a US-based cloud service for all its internal HR data. Doing so would turn a “last resort” exception into a permanent loophole. Their role is to provide a last resort where no other lawful transfer mechanism is realistically available.

b) Additional Requirements Beyond Chapter V

Even when Chapter V mechanisms are used, controllers and processors must still comply with all other GDPR obligations, including:

• maintaining a valid lawful basis for the processing (Article 6),
• implementing appropriate security measures (Article 32),
• respecting data minimization and purpose limitation (Article 5),
• ensuring data subject rights remain enforceable, and
• documenting transfers and safeguards as part of accountability obligations.

These overarching requirements continue to apply whether personal data is accessed within or outside the EU/EEA.

Common Compliance Mistakes in Third-Party Data Sharing and Transfers

Even experienced organisations frequently fall into predictable compliance errors when sharing personal data with third parties or enabling cross-border access. These mistakes are commonly cited in supervisory authority findings, compliance reviews, and industry analyses, and they persist because they stem from misunderstandings of GDPR fundamentals and evolving case law.

i) Missing or Inadequate Data Processing Agreements (DPAs)

A foundational requirement of GDPR Article 28 is that controllers must enter into valid written agreements with processors before sharing personal data. However, some failures keep occurring, including sharing data without any DPA, or relying on generic vendor contracts that lack mandatory GDPR terms such as security measures, sub-processor controls, and breach notification duties. Without these terms, there is no enforceable framework governing how the data is handled.

ii) Lack of Visibility over Subprocessors

Third-party processors often rely on their own subprocessors, such as cloud hosting providers, analytics tools, or external developers. A common compliance failure is that organizations do not know who these subprocessors are or how they handle personal data.

Typical issues include failing to identify or list approved subprocessors in contracts, allowing subprocessors to operate without being bound by equivalent GDPR safeguards, and having no notification or approval process when new subprocessors are added. As a result, personal data may be accessed or processed by unknown parties without the controller’s knowledge or control.

iii) Insufficient Technical and Organisational Measures (TOMs)

Article 32 GDPR requires controllers and processors to implement technical and organizational measures that are appropriate to the risks involved. A common mistake is assuming that a third party’s “standard security” is sufficient, without assessing or verifying what protections are actually in place.

This requires controllers to actively assess and verify the security measures applied by third parties before and during the processing. This includes exercising audit rights, reviewing third-party security certifications, such as ISO 27001 or SOC2, and ensuring that vendors have implemented state-of-the-art protections. Relying on generic assurances or assumed “standard security” is not sufficient. Where basic protections such as encryption, access controls, monitoring, or incident response procedures are missing or poorly implemented, personal data may be exposed to avoidable risks, for which the controller remains accountable under the GDPR.

iv) Incomplete or Outdated Records of Processing Activities (RoPA)

Article 30 GDPR requires controllers to maintain accurate and up-to-date records of processing activities, including details of third-party data sharing and international transfers. However, many organizations either do not maintain these records at all or fail to update them as new vendors, partners, or transfer mechanisms are introduced. This often results in missing recipient lists, unclear or undocumented legal bases, absent transfer records, or no indication of which safeguards are relied upon.

RoPA is one of the first documents supervisory authorities request during audits or investigations. Incomplete or outdated records make it difficult to demonstrate compliance, signal weak data governance, and can lead regulators to impose corrective measures or administrative fines, even in the absence of a reported breach.

v) Failing to Maintain or Update Transfer Mechanisms (SCCs / BCRs)

International transfers of personal data outside the EU/EEA require valid safeguards, most commonly Standard Contractual Clauses (SCCs) or Binding Corporate Rules (BCRs). A common compliance mistake is treating these mechanisms as static paperwork rather than safeguards that must be reviewed as legal requirements and transfer risks evolve.

So, organizations may continue using outdated SCC templates, fail to carry out transfer impact assessments (TIAs), or overlook the need for supplementary technical or organizational measures where destination-country laws could undermine data protection. Even where contracts are in place, these gaps can mean that international access to personal data is unlawful, a risk highlighted by regulatory enforcement actions involving global platforms, like Meta.

Legal and Operational Risks of GDPR Non-compliance

GDPR non-compliance on third-party data sharing and transfer exposes organizations to significant legal liability, operational disruption, financial losses, and reputational damage. These are documented risks that regulators, courts, and privacy advocates have confronted to date:

i) Regulatory Fines and Financial Penalties

The most immediate risk of mishandling third-party sharing or international transfers is the imposition of administrative fines. Under the GDPR’s two-tier penalty system, violations of core principles, including unlawful data sharing or failing to provide appropriate safeguards for transfers, fall into the highest bracket. These can reach up to €20 million or 4% of a company’s total global annual turnover from the preceding financial year, whichever is higher.

A notable example is the €1.2 billion fine issued by the Irish Data Protection Commission against Meta in May 2023. This remains the largest fine in GDPR history. The regulator found that Meta continued to transfer personal data from the EU to the U.S. following the Schrems II ruling without ensuring that the data was protected from U.S. government surveillance. This case proved that even using Standard Contractual Clauses (SCCs) is not a “get out of jail free” card if the Transfer Impact Assessment (TIA) reveals that local laws (like FISA 702) undermine those clauses.

Note that financial risk extends beyond one-time fines to include periodic penalty payments or daily fines imposed under Article 58 that accumulate until a violation is corrected.

ii) Legal Actions and Civil Liability

Civil liability under Article 82 has become as significant a threat as regulatory fines. The Court of Justice of the EU (CJEU) has solidified the standard that “non-material damage”, such as the mere “loss of control” over one’s data or the resulting psychological distress, can justify financial compensation even without a direct financial loss. This is particularly dangerous for organizations sharing data with third parties, as any unlawful disclosure or lack of transparency is now seen as a compensable harm.

Furthermore, the full implementation of the EU Representative Actions Directive has paved the way for class-action style litigation. Consumer advocacy groups can now aggregate thousands of small individual claims into massive collective lawsuits. Under the GDPR’s joint and several liability rules, individuals can sue the original controller for a third-party processor’s mistake, forcing the controller to pay the full damages before attempting to recover costs from the partner.

Current trends show a surge in these mass claims, particularly regarding the unlawful use of third-party tracking pixels on sensitive healthcare and financial platforms. These cases demonstrate that failing to vet a vendor’s data-sharing practices can lead to catastrophic civil payouts that far exceed the initial regulatory fine. 

iii) Operational Disruptions and Business Impact

Operational disruption can also be particularly damaging because regulators can use Article 58 to issue stop-processing orders. These orders act as a digital “kill switch,” instantly blocking international data transfers or third-party access essential for cloud services, global payroll, or centralized CRM systems. As seen in the landmark Meta ruling, authorities can force a total suspension of data flows if safeguards are deemed insufficient under Schrems II standards. Such an intervention can paralyze a company’s core business model overnight, as the order typically remains in place until full compliance is technically and legally proven.

Beyond simple shutdowns, non-compliance frequently leads to forced data migrations and the termination of critical vendor partnerships. Recently, organizations found using non-compliant third-party providers are often legally required to move vast datasets to “sovereign” or local EU providers. These emergency migrations are astronomically expensive, cause significant system downtime, and can result in the loss of years of integrated functionality. When a regulator breaks a data-sharing chain, the resulting business paralysis creates a level of operational fragility that far exceeds the cost of any administrative penalty. 

iv) Reputational Damage and Loss of Trust

Reputational damage has evolved from a vague PR concern into a measurable commercial liability. With the maturity of privacy-first markets, consumers and B2B partners now view GDPR compliance as a baseline indicator of corporate integrity and digital safety. A public enforcement action, especially one involving the “invisible” sharing of sensitive data with unauthorized third parties, triggers an immediate loss of trust that can lead to rapid customer churn. In a competitive landscape, this trust deficit often results in long-term brand erosion that is far more difficult to recover from than paying a one-time administrative fine.

For B2B organizations, the stakes are even higher as non-compliance can lead to systemic partner exclusion. Going forward, standard procurement due diligence requires vendors to prove a clean regulatory record; a documented failure in third-party data management can disqualify a company from lucrative contracts and government tenders. Modern privacy advocacy groups, such as NOYB, have mastered the art of “naming and shaming” non-compliant firms, ensuring that breaches remain in the public eye through viral social campaigns and media coverage. This environment makes privacy a core pillar of brand value, where a single mishandled transfer can permanently alienate a privacy-conscious global audience. 

v) Contractual and Third-Party Liability

Contractual and third-party liability is governed by the principle of “non-delegable responsibility.” Under Article 28, a Data Controller remains legally the primary guarantor of the data, meaning they are the first line of accountability for any failure within their supply chain. Even if a breach is entirely the fault of a third-party vendor’s negligence, regulators like the EDPB will hold the original controller liable for culpable lack of oversight. While a contract may allow a controller to sue a vendor for damages later, it cannot be used as a legal shield to prevent a supervisory authority from issuing fines or suspension orders against the controller directly.

Therefore, organizations must recognize that joint and several liability under Article 82 allows data subjects to claim full compensation from either the controller or the processor. This “deep pocket” rule means individuals often target the better-funded controller first, regardless of who caused the error. Furthermore, if a controller fails to conduct a rigorous Transfer Impact Assessment (TIA) or security audit before sharing data, they are considered to have “accepted the risk” of the vendor’s non-compliance. This creates a high-stakes environment where a partner’s failure is legally treated as the controller’s own failure, making robust vendor vetting a core survival requirement rather than a mere procurement step. 

Final thought

The GDPR regulates third-party sharing through a layered framework. At the base level, organizations must establish a lawful basis, ensure transparency, correctly classify roles, and implement binding contractual and security safeguards. Where access extends beyond the EU/EEA, additional transfer-specific requirements apply to ensure that personal data continues to benefit from protection that is essentially equivalent to that guaranteed within the Union.

Regulatory enforcement patterns show that non-compliance most often arises not from obscure legal questions, but from practical failures, such as unclear role classification, inadequate contracts, and uncontrolled subprocessors etc. These weaknesses expose organizations to legal liability, operational disruption, financial penalties, and loss of trust.

Ultimately, GDPR compliance in third-party data sharing is not achieved through isolated measures or template contracts. It requires ongoing governance, a clear understanding of data flows, and active oversight of all parties with access to personal data. Organisations that treat third-party access as a regulated disclosure are far better positioned to meet GDPR requirements and withstand regulatory scrutiny.