1. Concept: Why “Joint Controller Ambiguity” arises

Under Article 4(7) and Article 26 of the GDPR, joint controllership exists when two or more entities jointly determine the purposes and means of processing personal data. The difficulty (and “ambiguity”) arises because:

• The GDPR does not require equal control—only “joint influence”
• Responsibility can be asymmetric (one party may be more dominant)
• The threshold is functional, not formal (contracts are not decisive)
• Many commercial relationships (platforms, HR systems, adtech, insurance groups in Denmark/EU) blur lines between:
  • controller vs processor
  • independent controllers vs joint controllers

The Court of Justice of the EU (CJEU) has consistently adopted a broad interpretation, which creates uncertainty for Danish companies, especially in group structures and digital ecosystems.

2. Key CJEU Case Law establishing ambiguity principles

Case 1: Wirtschaftsakademie Schleswig-Holstein v ULD (C‑210/16)

Principle: Facebook fan page operator = joint controller with Facebook.

• A German educational institution ran a Facebook fan page.
• Facebook collected visitor data and provided analytics.
• The operator had no direct access to data → yet still liable.

Held:

• Determining “audience insights” meant influencing processing purposes.
• Even indirect influence is enough for joint controllership.

Why it creates ambiguity:

• No access to data ≠ no controller status
• Small actors can be jointly liable with tech giants

Case 2: Fashion ID (C‑40/17)

Principle: Website embedding Facebook “Like” button → joint controllership.

• Retailer embedded third-party plug-in.
• Plug-in triggered automatic data transfer.

Held:

• Website operator is joint controller for initial data collection only
• Not responsible for Facebook’s later processing

Ambiguity created:

• Joint controllership can be partial (step-based liability)
• Responsibility is fragmented across processing stages

Case 3: Jehovah’s Witnesses case (C‑25/17)

Principle: Religious community organizing preaching = joint controller.

• Members collected personal data during door-to-door preaching.

Held:

• Organization influenced purpose and methods → joint controllership exists even without direct data handling.

Ambiguity:

• Organizational coordination alone may create liability
• Control can be “structural”, not technical

Case 4: Google Spain v AEPD (C‑131/12)

Principle: Search engine = controller of indexing and display.

• Google was responsible for processing indexing personal data.

Relevance to joint control reasoning:

• Even if third-party content exists, own processing purpose creates controller status
• Later used as foundation for broad joint control logic

Ambiguity:

• Overlapping responsibilities between publisher and platform

Case 5: IAB Europe (C‑604/22)

Principle: Industry body jointly responsible for adtech consent system.

• IAB Europe created “TC String” consent framework.

Held:

• Even without direct access to data, influencing processing architecture = joint controller

Ambiguity:

• Entities can be controllers via rule-setting influence
• Expands liability into governance structures (not just data handling)

Case 6: Nacionalinis visuomenės sveikatos centras (C‑683/21) (Lithuanian COVID app case)

Principle: Public authority + IT developer = joint controllers.

• COVID tracking app developed by private company but used by authority.

Held:

• Both entities jointly determined purposes/means even if roles differed in practice.

Ambiguity:

• “Informal approval” or de facto use can create joint responsibility
• Blurs outsourcing vs joint governance distinction

3. How Denmark applies joint controllership ambiguity

While Denmark has limited standalone Supreme Court case law specifically defining joint controllership, Danish practice follows:

• EU GDPR directly (no national deviation)
• Guidance from the Danish Data Protection Agency (Datatilsynet)
• Direct application of CJEU case law

Danish context where ambiguity is common:

(A) Insurance & financial groups

• Group companies share HR systems, customer databases
• Often unclear if:
  • shared controller group
  • or controller–processor structure

(B) Public–private IT systems

• Municipal digital services
• Vendors co-designing systems often become joint controllers unintentionally

(C) Adtech & marketing platforms in Denmark

• Cookie banners, tracking tools, SaaS analytics platforms
• Following IAB Europe logic → frequent joint controllership findings

4. Core legal tests used in Denmark (derived from EU case law)

Courts and regulators assess:

1. Purpose test

• Do both parties pursue their own purposes?

2. Means test

• Do they jointly decide technical/organizational means?

3. Influence test (critical after IAB Europe)

• Even indirect influence = joint controllership

4. Stage-based liability test (Fashion ID principle)

• Liability may apply only to part of processing lifecycle

5. Key legal consequences of joint controller ambiguity

If classified as joint controllers in Denmark:

• Mandatory Article 26 arrangement required
• Shared GDPR obligations (information duties, DSAR handling)
• Potential joint and several liability for damages
• Increased compliance burden and audit exposure

6. Conclusion

The “joint controller ambiguity” problem in Denmark is not caused by national law but by EU-wide CJEU jurisprudence, which has:

• Expanded joint controllership beyond direct data access
• Recognized indirect influence as sufficient
• Allowed partial and asymmetric responsibility
• Extended liability into governance, platforms, and technical infrastructure

This makes Danish compliance practice highly cautious—many organizations prefer controller–processor structures instead of joint controllership, even when real-world facts might suggest otherwise.