Article 26 — Joint controllers

Article 26 GDPR: Joint Controllers

1. The central idea behind joint controllership

Article 26 deals with situations in which more than one organisation is involved in determining how and why personal data are processed.

The easiest way to understand the provision is to begin with the question:

Who decides what happens to the personal data, and who is making those decisions together?

The GDPR normally works with a relatively simple structure:

Controller → determines purposes and means

Processor → processes data on behalf of the controller

But modern data ecosystems are rarely that simple.

A single processing operation may involve:

• a platform;

• an advertiser;

• a trade association;

• a technology provider;

• a marketplace;

• a hospital and research institution;

• two companies operating a joint service;

• several organisations using a common system.

Sometimes these entities are not merely cooperating with one another. They are collectively influencing the purposes and essential means of the processing.

That is where joint controllership arises.

Article 26 therefore recognises an important reality:

More than one organisation can be responsible for determining a processing operation.

The consequence is significant. Once two or more entities are genuinely joint controllers, they cannot simply allocate all GDPR responsibility to one party through a contract and treat the others as having no obligations.

Their internal arrangement can allocate responsibilities between them, but it cannot rewrite the factual reality of who is a controller.

2. Joint controllership is determined by facts, not contracts

This is probably the most important principle in Article 26.

Organisations cannot decide whether they are joint controllers simply by putting a label in a contract.

Example

suppose Company A and Company B sign an agreement stating:

"Company A shall be the sole controller. Company B has no responsibility under the GDPR."

That contractual wording is not decisive if, in reality, Company B participates in determining the purposes and means of the processing.

The GDPR looks at the actual activities and decision-making of the parties.

This is why the EDPB and CJEU approach the controller concept functionally.

The relevant question is not:

"What does the contract call us?"

It is:

"What do we actually do?"

This prevents organisations from avoiding GDPR responsibilities through contractual drafting.

3. The two essential elements: purposes and means

Joint controllership requires joint determination of the purposes and means of processing.

These two concepts come from the controller definition in Article 4(7).

Purpose

The purpose concerns:

Why is the personal data being processed?

Examples

include:

• advertising;
• fraud prevention;
• customer management;
• recruitment;
• research;
• authentication;
• behavioural analysis;
• delivery of a service.

Means

The means concern:

How is the processing carried out?

This can include decisions concerning:

• what categories of data are used;

• which systems are used;

• how information is collected;

• how it is disclosed;

• how it is stored;

• how long it is retained;

• how individuals are profiled;

• how information is made available.

Not every decision about technical details makes someone a controller.

Example

a company providing ordinary IT infrastructure may determine technical aspects necessary to operate its service while still acting as a processor.

The critical question is whether the organisation has a meaningful role in determining the essential purposes and means of the processing.

4. "Jointly" does not mean that both organisations must make exactly the same decisions

This is an area where Article 26 can easily be misunderstood.

Joint determination does not require the parties to sit together in one meeting and jointly approve every individual processing decision.

Joint controllership can arise through:

Common decisions

Both organisations expressly decide together what will happen to the data.

Converging decisions

The organisations make separate decisions that complement each other and together make the processing possible.

This second situation is particularly important.

Imagine:

Company A decides that customer information will be used to provide personalised advertising.

Company B determines the technical and operational framework through which those advertisements will be selected and delivered.

If their decisions complement one another and each has a tangible influence on the processing, joint controllership may arise.

The CJEU has repeatedly emphasised that joint controllership can arise even where the involvement of the parties is unequal.

One controller does not need to have exactly the same level of influence as the other.

5. The parties do not need to have access to the data

This is another crucial principle.

A common assumption is:

"If I cannot see the personal data, I cannot be a controller."

That is incorrect.

Controller status is primarily about decision-making power, not physical possession of the data.

The CJEU demonstrated this particularly clearly in IAB Europe (C-604/22).

The Court considered the role of IAB Europe in the Transparency and Consent Framework used in online advertising.

IAB Europe did not need direct access to all personal data processed within the advertising ecosystem to potentially qualify as a joint controller.

Why?

Because an organisation can influence the purposes and means of processing without itself physically possessing the resulting data.

This is highly significant for modern technology systems.

A platform designer, standards organisation or ecosystem operator may have controller responsibility even where it never stores the underlying personal data itself.

6. Joint controllership can exist at different stages

The parties do not have to participate in exactly the same way or at exactly the same moment.

One organisation might determine part of the processing at the collection stage.

Another might determine essential elements of what happens after collection.

The CJEU has accepted that joint controllers can participate:

• at different stages;

• to different degrees;

• through different forms of influence.

But there is an important limitation.

The parties must be jointly determining the purposes and means of the same processing operation or interconnected processing operations.

Simply touching the same data at different points does not automatically create joint controllership.

7. Sequential processing does not automatically mean joint controllership

Consider this example:

Company A collects customer data for selling a product.

It later sends certain information to:

Company B, which uses the information independently for fraud prevention.

Company A and Company B have different purposes.

Company A determines its own processing.

Company B determines its own processing.

The fact that the same information passes from A to B does not automatically make them joint controllers.

They may instead be separate or successive controllers.

This distinction is essential.

Joint controllers

Both participate in determining the purposes and means of the same processing.

Independent controllers

Each organisation independently determines why and how it processes the information.

Processor

The organisation processes the data on behalf of another organisation and does not determine its own purposes for that processing.

These three categories must not be confused.

8. Sharing data does not automatically create joint controllership

Suppose a university sends student information to a government authority because the law requires it.

The university and government authority may each be controllers for their respective processing activities.

They are not automatically joint controllers merely because personal data move from one organisation to another.

Similarly, two companies may exchange customer information while remaining separate controllers.

The decisive question remains:

Did they jointly determine the purposes and means of the relevant processing?

If the answer is no, Article 26 may not apply.

9. Sharing infrastructure does not automatically create joint controllership

The same principle applies to common infrastructure.

Imagine several companies in a corporate group use a shared customer database.

That fact alone does not necessarily make them joint controllers.

Suppose:

• each company enters information about its own customers;

• each company determines why it uses the information;

• each company controls access to its own data;

• each company determines retention;

• one group company merely provides hosting infrastructure.

The companies may remain separate controllers for their respective processing.

The hosting company may be a processor.

The important point is:

Shared technology does not necessarily mean shared controllership.

What matters is shared determination of purposes and means.

10. But jointly designed infrastructure can create joint controllership

The analysis changes where organisations jointly design and operate an infrastructure for a common processing purpose.

Suppose two companies create a shared platform specifically to:

• collect customer information;

• analyse customer behaviour;

• create joint profiles;

• distribute personalised offers.

If both companies determine the purposes and essential means of this system, joint controllership becomes much more likely.

The infrastructure is not decisive by itself.

What matters is how the infrastructure is designed and why it is operated.

11. Joint controllers do not need identical purposes

Another misconception is that joint controllers must have exactly the same purpose.

That is too narrow.

Two organisations can have different but closely connected and complementary interests in the same processing.

For example:

Company A wants to provide personalised advertising to its users.

Company B operates the advertising infrastructure and wants to facilitate targeted advertising through its platform.

Their interests are not necessarily identical.

Yet their decisions may converge in a manner that gives both of them influence over the purposes and means of the processing.

The CJEU has therefore focused on whether the decisions of the parties complement each other and have a tangible impact on the processing.

12. The marketplace example

The CJEU's case law concerning online marketplaces illustrates how broad the concept can be.

Imagine an online marketplace where sellers publish advertisements.

A seller provides personal information in an advertisement.

The marketplace:

• determines how advertisements are displayed;

• determines their structure;

• determines how they are organised;

• determines how long they remain available;

• determines how they are presented to particular recipients.

The marketplace is not merely a passive hosting provider.

Its decisions influence how the personal data contained in the advertisements are disseminated.

The CJEU has therefore recognised circumstances in which an online marketplace can be a joint controller with the advertiser.

The lesson is important:

An organisation can become a joint controller by exercising decisive influence over the way personal data are processed, even where another organisation initially supplied the information.

13. Search engines provide another important illustration

Search engines also demonstrate why controller status cannot be determined merely by asking:

"Who originally collected the data?"

A search engine may take information that already exists online and organise, index and disseminate it in a way that significantly affects how individuals can access that information.

Its role in organising and making information accessible can involve decisions that have an important influence over the processing.

This demonstrates the functional nature of the controller concept.

An organisation may become relevant to the processing because of what it does with information, not merely because it originally collected it.

14. IAB Europe and the advertising ecosystem

The online advertising ecosystem provides perhaps one of the best modern illustrations of joint controllership.

Digital advertising can involve:

• publishers;

• advertisers;

• advertising exchanges;

• consent-management systems;

• standards organisations;

• technology providers;

• data platforms.

An organisation does not necessarily escape controller status merely because it does not directly receive the final user-level data.

If it determines or materially influences the purposes and means of processing for its own purposes, joint controllership may arise.

The lesson from IAB Europe is particularly relevant to privacy engineers and AI governance professionals:

Control can exist at the level of system design, standards and decision architecture, not merely at the level of direct data possession.

This is becoming increasingly important in complex AI and digital ecosystems.

15. The arrangement under Article 26

Once organisations are correctly identified as joint controllers, Article 26 requires them to determine their respective responsibilities.

This is normally done through a joint-controller arrangement.

The agreement should not be treated as an ordinary commercial contract.

Its primary purpose is to establish:

Who will do what to ensure compliance with the GDPR?

The arrangement should therefore identify responsibility for matters such as:

• privacy notices;

• data subject rights;

• legal bases;

• security;

• breach notification;

• DPIAs;

• international transfers;

• processor management;

• regulatory communications.

The arrangement creates organisational clarity.

16. The agreement cannot change the factual status of the parties

This is critical.

A joint-controller arrangement does not create joint controllership.

The parties become joint controllers because the facts satisfy the controller definition.

The arrangement is a consequence of joint controllership, not its source.

Therefore:

==No agreement + joint determination = still joint controllers, but in breach of Article 26's arrangement requirement.==

Conversely:

==Agreement calling parties "joint controllers" + no genuine joint determination = the label does not necessarily create joint controllership.==

The facts come first.

The contract comes second.

17. What should a good joint-controller arrangement contain?

A strong arrangement should clearly explain:

Identity of the parties

Who are the joint controllers?

Processing activity

What processing is being jointly undertaken?

Purpose

Why is the processing carried out?

Categories of data

What personal data are involved?

Categories of data subjects

Whose data are processed?

Legal basis

Which controller is responsible for determining and documenting the legal basis, and how is this coordinated?

Transparency

Who provides the Article 13 or Article 14 information?

Data subject rights

Who receives and handles access, deletion, rectification, objection and other requests?

Security

Who implements which technical and organisational measures?

Data breaches

Who detects, assesses and reports breaches?

DPIA

Who conducts the assessment and who provides relevant information?

Processors

Who selects and manages processors?

International transfers

Who assesses and manages Chapter V transfer requirements?

Supervisory authorities

Who coordinates regulatory communications?

This is much more useful than a short clause saying:

"The parties shall comply with the GDPR."

18. Responsibility should follow practical proximity

The EDPB approach is particularly useful here.

Responsibilities should generally be allocated to the party that is best positioned to perform the particular obligation.

Suppose only Company A directly interacts with customers.

Company A is probably better positioned to:

• provide the privacy notice;

• collect consent where relevant;

• receive data subject requests;

• communicate with customers.

Company B may operate the underlying technology.

Company B may therefore be better positioned to:

• implement certain security measures;

• maintain technical logs;

• manage particular processing systems.

The allocation should therefore follow operational reality.

This creates a very practical principle:

Responsibility should follow control, proximity and capability.

19. Responsibilities do not have to be divided equally

Joint controllership does not mean:

"50% responsibility for A + 50% responsibility for B."

That is not how Article 26 works.

One controller may be responsible for 80% of the operational compliance tasks while another handles a smaller but important set of obligations.

The distribution depends upon the actual processing arrangement.

For example:

Company A

• collects the data;

• communicates with individuals;

• handles rights requests.

Company B

• operates the platform;

• determines certain profiling parameters;

• handles security and technical controls.

There is no requirement that their responsibilities be mathematically equal.

20. Some obligations cannot simply be outsourced through the arrangement

The joint-controller agreement is not a mechanism for eliminating individual GDPR obligations.

Some obligations attach to each controller independently.

Example

where applicable, each controller must comply with its own obligations concerning:

• Article 30 records;

• DPO appointment;

• general accountability;

• its own processing activities.

The arrangement can coordinate responsibilities, but it does not erase obligations that the GDPR imposes individually.

This is another reason why a joint-controller agreement should not be treated as a liability-allocation document alone.

21. The agreement must be transparent

Article 26 requires transparency.

This means the parties should be able to demonstrate clearly:

Who is responsible for what?

A vague arrangement such as:

"The parties shall cooperate to ensure GDPR compliance."

is inadequate as an operational model.

A better arrangement says:

"Company A shall provide the Article 13 notice because it directly collects the personal data. Company B shall provide Company A with the information necessary to describe its processing operations."

Now the responsibility is clear.

22. The "essence" must be made available to data subjects

Article 26 contains a particularly important transparency obligation.

Data subjects do not normally need to receive the entire commercial agreement.

Instead, the essence of the arrangement must be made available.

This allows individuals to understand:

• who the joint controllers are;

• what their respective roles are;

• who is responsible for what;

• whom the individual can contact;

• how rights can be exercised.

The requirement is designed to prevent a common problem:

Multiple organisations jointly process someone's data, but the individual has no idea which organisation is responsible for what.

Article 26 directly addresses this problem.

23. The full contract does not normally need to be published

The "essence" requirement should not be confused with an obligation to publish the entire commercial agreement.

Joint controllers may have commercially sensitive arrangements covering:

• pricing;

• intellectual property;

• business strategy;

• indemnities;

• commercial terms;

• liability allocation.

Those details do not normally need to be disclosed simply because Article 26 applies.

The data subject needs enough information to understand the privacy-relevant allocation of responsibility.

For example:

"Company A is responsible for responding to access requests, while Company B is responsible for providing the technical information necessary to respond."

That is the kind of information that is useful to the data subject.

24. The essence is about transparency, not contractual enforceability

The Article 26 arrangement is a contract between the controllers.

The data subject is generally not a party to that contract.

Therefore, the arrangement cannot be used to impose contractual restrictions upon the data subject.

This distinction becomes particularly important under Article 26(3).

25. Article 26(3): The data subject is not bound by the arrangement

This is arguably the strongest protection in Article 26.

Suppose Company A and Company B agree:

"Company A will handle all data subject requests."

The data subject may still exercise GDPR rights against either controller.

The internal allocation does not restrict the individual's rights.

This is crucial.

The joint controllers may organise their internal responsibilities however they wish, but they cannot tell an individual:

"You contacted the wrong controller, so your GDPR right does not apply."

That would defeat Article 26.

26. Example: access request

Suppose:

Company A + Company B = joint controllers

Their arrangement states:

Company A handles Article 15 access requests.

A data subject sends an access request to Company B.

Company B cannot simply respond:

"Please contact Company A. We are not responsible."

The arrangement is an internal organisational mechanism.

The individual retains the right to exercise their rights against each controller.

Company B should therefore have an appropriate mechanism for handling or forwarding the request while ensuring that the data subject is not disadvantaged.

This reflects one of the most important principles of Article 26:

Internal allocation cannot reduce external rights.

27. Why Article 26(3) is so important

Imagine the opposite rule.

Suppose joint controllers could divide responsibilities in such a way that each could tell individuals:

"That is the other company's responsibility."

The individual could be trapped between two organisations.

Company A says:

"Ask B."

Company B says:

"Ask A."

The GDPR prevents this procedural dead end.

The individual can exercise rights against each joint controller.

The organisations must resolve the internal allocation themselves.

This places the burden of coordination on the controllers rather than on the individual.

28. The contact point

Article 26 allows the joint controllers to designate a contact point.

This is not merely a convenience.

It can make the system considerably easier for individuals.

For example:

Privacy Contact for the Joint Processing: privacy@example.com

The individual does not need to understand the internal corporate structure.

They simply have one obvious channel through which to exercise their rights.

The contact point may be:

• a DPO;

• one of the joint controllers;

• another designated function.

For non-EU joint controllers, the EU representative may also potentially serve as a contact point where appropriate.

29. A contact point does not eliminate the rights against other controllers

Even if one controller is designated as the single contact point, Article 26(3) remains applicable.

The data subject may still exercise rights against each joint controller.

Therefore:

Contact point ≠ exclusive legal target

The contact point simplifies communication.

It does not eliminate the legal rights of the data subject against the other joint controllers.

30. Joint controllership and processors: the critical distinction

This is one of the most important areas for practical GDPR analysis.

Consider a company hiring a cloud provider.

The company decides:

• why customer data are processed;

• what data are collected;

• how the data are used.

The cloud provider merely stores the data according to the company's instructions.

The cloud provider is generally a processor.

Now change the facts.

Suppose the cloud platform begins deciding, for its own purposes:

• how customer data will be analysed;

• which behavioural profiles will be created;

• how the resulting information will be used for its own commercial purposes.

The analysis changes.

If the provider is determining purposes for itself, it may no longer be acting merely as a processor for that processing.

Depending on the precise facts, it may become an independent controller or potentially a joint controller.

The labels in the contract cannot decide the issue.

31. Joint controller versus independent controller

The distinction is equally important between joint and separate controllers.

Joint controllers

They jointly determine the purposes and means.

Independent controllers

Each independently determines its own purposes and means.

For example:

A retailer sends customer information to a payment provider.

The retailer processes the information to complete a purchase.

The payment provider processes information independently for its own legal and fraud-prevention purposes.

They may be separate controllers for their respective processing rather than joint controllers.

The fact that they interact during one commercial transaction does not automatically create joint controllership.

32. The key analytical question

When analysing a complicated relationship, ask:

Could each organisation independently determine the relevant processing without the other?

Then ask:

Do their decisions complement each other in determining the purposes and essential means of the same processing?

And finally:

Does each organisation exercise influence over the processing for its own purposes or in a manner that gives it a meaningful role in determining the processing?

These questions are more useful than simply asking whether the organisations have signed a "joint-controller agreement."

33. The importance of purpose

Purpose is particularly important.

A processor acts:

on behalf of another entity.

A controller acts:

for its own purposes.

If an organisation begins using personal data for its own independent purposes, it may cease to be merely a processor for that activity.

For example:

A company hires an analytics provider to measure website traffic.

The provider processes data according to the company's instructions.

That is consistent with a processor relationship.

But if the provider also takes the information and combines it with data from thousands of other clients to create its own advertising profiles for commercial purposes, the analysis becomes considerably more complicated.

The provider is no longer simply following instructions for the customer's purposes.

Purpose is therefore often the dividing line.

34. Joint controllership in AI ecosystems

Article 26 has growing significance for AI systems.

Consider an AI ecosystem involving:

• an AI developer;

• a platform provider;

• an enterprise deploying the model;

• a data provider.

Suppose the enterprise and AI provider jointly decide:

• what personal data will be collected;

• why it will be used to train or improve the system;

• what categories of individuals will be included;

• how the resulting profiles will be used.

Depending on the precise facts, joint controllership may arise.

But if the AI provider merely processes data according to the enterprise's documented instructions and has no independent purpose, it may remain a processor.

The critical question remains:

Who actually determines the purposes and essential means of the processing?

AI architecture makes this question more difficult, but the legal principle remains the same.

35. Joint controllership in research

Research collaborations also provide useful examples.

Suppose a university and pharmaceutical company jointly design a research project involving patient data.

They jointly decide:

• the research objective;

• what categories of data will be collected;

• how the data will be analysed;

• how results will be generated.

They may be joint controllers.

But suppose the university independently determines the research purpose and simply hires a laboratory to perform analysis according to detailed instructions.

The laboratory may instead be a processor.

Again, the actual allocation of decision-making power is decisive.

36. Article 26 is closely connected with accountability

Article 26 should be read together with the broader accountability principle.

When multiple organisations participate in processing, it becomes easy for responsibility to become blurred.

Without Article 26, organisations might say:

"We thought the other company was handling that."

The provision requires the organisations to decide in advance:

• who handles rights;

• who provides notices;

• who manages breaches;

• who deals with regulators;

• who manages processors;

• who conducts DPIAs;

• who handles transfers.

This makes joint controllership an organisational governance requirement, not merely a classification issue.

37. The arrangement should be mapped to the actual data flow

A sophisticated joint-controller arrangement should be built around the actual processing lifecycle.

For example:

Collection

Company A

Consent / legal basis

Company A + Company B

Storage

Company B

Profiling

Company A + Company B

Disclosure

Company B

Data subject requests

Company A as primary contact, with cooperation from B

Deletion

Both parties according to their respective systems

This kind of operational mapping is much more useful than a generic contractual allocation.

38. Article 26 and transparency under Article 5

Article 26 cannot be understood independently from the principle of transparency in Article 5(1)(a).

The problem that Article 26 seeks to prevent is opacity.

Imagine a person uses an online service and sees:

"We may share your data with our partners."

But the person cannot determine:

• who the controllers are;

• why each organisation processes the information;

• who is responsible for rights;

• whom to contact.

That is exactly the type of fragmented processing environment in which transparency becomes difficult.

Article 26 responds by requiring the essence of the joint arrangement to be available to the data subject.

39. The data subject should not have to understand corporate structures

Privacy law should be designed from the individual's perspective.

A user should not have to understand:

• corporate groups;

• subsidiaries;

• licensing agreements;

• platform arrangements;

• technology contracts;

• advertising supply chains.

Suppose three companies jointly operate a service.

The privacy notice should make it reasonably clear:

"Companies A, B and C jointly determine how your information is used for this service. Company A is your primary contact for privacy requests. Company B operates the analytics component. Company C manages the customer platform."

This is much more meaningful than merely publishing three company names.

The essence requirement is therefore fundamentally about making responsibility intelligible.

40. The arrangement cannot reduce the standard of protection

The joint-controller arrangement is an internal mechanism.

It cannot be used to contract out of mandatory GDPR rights.

The controllers cannot agree:

"Neither party will respond to deletion requests."

Nor:

"Only users who contact Company A can exercise their rights."

Nor:

"Company B has no responsibility for security even though it controls the relevant infrastructure."

The arrangement must operate within the GDPR, not around it.

41. Liability and Article 26

Article 26 should also be understood alongside Article 82.

Joint controllership can have significant liability consequences.

Where multiple controllers are responsible for processing that results in GDPR damage, the GDPR contains mechanisms designed to ensure that the data subject is not left without an effective remedy simply because several organisations were involved.

The internal agreement can determine how the controllers allocate responsibilities and potentially manage their relationship between themselves.

But that internal allocation does not necessarily determine the data subject's external rights.

This produces another important principle:

Internal allocation of responsibility and external enforceability are different questions.

42. A practical example: joint marketing campaign

Suppose a bank and an insurance company jointly launch a financial-services campaign.

They jointly decide:

• which existing customers will receive the campaign;

• what personal information will be used;

• how customer profiles will be analysed;

• what marketing messages will be delivered.

They may be joint controllers for that processing.

Their Article 26 arrangement could state:

Bank

• provides the initial privacy information;

• receives data subject requests;

• maintains the customer-facing portal.

Insurance company

• provides information about its processing;

• manages its marketing platform;

• handles certain campaign-related deletion processes.

Both remain responsible for their respective GDPR obligations.

The customer can nevertheless exercise their rights against either controller.

43. A practical example: social-media platform and advertiser

Consider an advertiser using a social-media platform to target a defined audience.

The advertiser chooses:

• target characteristics;

• campaign objectives;

• audience criteria.

The platform determines:

• how the advertisements are delivered;

• how users are selected;

• how advertisements are displayed.

Depending on the precise processing and the degree of influence exercised by each party, aspects of the processing may involve joint controllership.

But one must not automatically classify every advertiser-platform relationship as joint controllership.

The precise processing operation must be isolated.

This is an important methodological point:

Controller status is assessed in relation to particular processing activities, not necessarily to an organisation as a whole.

An organisation may be:

• controller for one processing activity;

• joint controller for another;

• processor for another.

44. Joint controllership is processing-specific

This is an essential practical lesson.

A company does not receive a permanent label saying:

"Joint controller."

Instead, its role is determined with reference to particular processing activities.

Example

Company A might:

For payroll: controller

For cloud hosting: processor

For joint marketing campaign: joint controller

For independent fraud analytics: separate controller

This functional analysis is much closer to how the GDPR actually operates.

45. What should organisations do in practice?

When two organisations collaborate, they should conduct a controller-processor/joint-controller assessment before the processing begins.

The assessment should identify:

1. Purpose

Why is the processing taking place?

2. Decision-making

Who decided that the processing would occur?

3. Means

Who determines the essential methods of processing?

4. Independence

Is each organisation acting for its own purposes?

5. Instructions

Is one organisation genuinely acting on the documented instructions of another?

6. Influence

Does each organisation have meaningful influence over the processing?

7. Data access

Who actually receives or accesses the data?

This is relevant, but not determinative.

8. Legal basis

Who determines and documents the lawful basis?

9. Rights

Who interacts with data subjects?

10. Operational control

Who can actually change how the processing works?

This assessment should be documented.

46. A useful decision framework

The following framework can simplify difficult cases.

Scenario

A Company A determines why and how data are processed. Company B merely follows A's instructions.

Likely relationship

Controller + processor.

Scenario

B Company A determines its own purposes. Company B independently determines its own purposes.

Likely relationship

Separate controllers.

Scenario

C Company A and Company B jointly determine the purposes and essential means.

Likely relationship

Joint controllers.

Scenario

D Company A and Company B merely exchange information but independently decide how to use it.

Likely relationship

Separate controllers.

Scenario

E Company A and Company B jointly design a system and determine how personal data will be collected, analysed and used.

Likely relationship

Potential joint controllers.

The precise facts remain decisive.

47. The deepest principle of Article 26

Article 26 is ultimately built around a simple proposition:

The person whose data are being processed should not bear the consequences of fragmented organisational responsibility.

If several organisations jointly determine the processing, the individual should not have to solve the organisations' internal allocation problems.

The controllers must organise themselves.

They must decide:

• who does what;

• how requests are handled;

• how information is provided;

• how breaches are managed;

• how security is implemented;

• how compliance is demonstrated.

But from the individual's perspective, the GDPR remains fully available.

Conclusion

Article 26 is not simply a requirement to sign a joint-controller agreement. Its real importance lies in three connected principles.

First: factual joint determination creates joint controllership

The status depends on what the parties actually do, not what their contract calls them.

Two or more organisations become joint controllers where they jointly determine the purposes and means of the relevant processing. Their participation may be unequal, may occur at different stages and may arise through complementary or converging decisions.

They do not necessarily need to possess the data themselves.

Second: the joint-controller arrangement creates internal accountability

Once joint controllership exists, the organisations must transparently allocate their GDPR responsibilities.

The arrangement should address the practical operation of compliance, particularly:

• Articles 13 and 14 information;

• data subject rights;

• security;

• breaches;

• DPIAs;

• processors;

• international transfers;

• regulatory communications.

The allocation should reflect the actual roles and practical proximity of each controller to the processing.

Third: the arrangement cannot restrict the data subject

This is the most important protection.

The joint controllers can decide between themselves who handles a particular obligation.

The data subject does not have to accept that internal division.

Under Article 26(3), the individual can exercise GDPR rights against each joint controller.

Thus, the GDPR deliberately separates:

internal responsibility allocation

from

external protection of the data subject.

The overall architecture can therefore be remembered as:

Joint decision-making creates joint controllership.

Joint controllership requires transparent internal allocation of responsibility.

Internal allocation cannot diminish the individual's rights.

That is the core of Article 26.

The provision is particularly important in the modern digital economy because processing increasingly occurs through ecosystems rather than single organisations. Advertising networks, online marketplaces, research collaborations, AI platforms, social-media ecosystems, financial services and interconnected digital platforms can involve numerous actors whose decisions collectively shape the processing of personal data.

Article 26 ensures that complexity in the organisation's business model does not become complexity in the individual's rights.

The decisive question is therefore never simply:

"Who has the data?"

It is:

"Who actually determines why and how this processing takes place?"

And where the answer is two or more organisations acting together, Article 26 provides the framework for making that shared responsibility transparent, operational and enforceable. :::