GDPR Art.56 Lead Supervisory Authority & One-Stop-Shop: Which DPA Controls Your GDPR Enforcement (2026)

Post #447 in the sota.io EU Cyber Compliance Series

If your SaaS, API, or platform processes personal data of users across multiple EU member states, you do not answer to 27 separate data protection authorities. GDPR Art.56 establishes the one-stop-shop (OSS) mechanism: a single lead supervisory authority (lead SA) handles enforcement for all cross-border processing. The Irish Data Protection Commission (DPC) became the default lead SA for thousands of tech companies precisely because of Art.56 — not because of tax advantages alone.

Getting your lead SA wrong has direct legal consequences: filing with the wrong DPA, missing an investigation response from your actual lead SA, or misunderstanding what "cross-border processing" means under Art.4(23) can expose you to enforcement gaps and jurisdictional disputes. This guide explains the mechanics.

The Art.56 One-Stop-Shop in One Paragraph

Art.56(1) states: "The supervisory authority of the main establishment or of the single establishment of the controller or processor shall be competent to act as lead supervisory authority for the cross-border processing carried out by that controller or processor."

That sentence means:

1. You have a main establishment (or a single establishment if you have only one EU presence)
2. The SA in the member state where that main establishment is located is your lead SA
3. That lead SA has primary competence for all cross-border processing investigations and enforcement decisions
4. Other member states' SAs become concerned SAs — they can participate, but the lead SA drives the process

What Is Cross-Border Processing? Art.4(23) Definition

Art.56 only applies to cross-border processing, defined in Art.4(23) as either:

• Processing in multiple member states — your systems operate in or serve users in more than one EU/EEA country
• Processing that substantially affects data subjects in multiple member states — even if operations are in one country, effects spread across borders (e.g. a German platform serving users in Germany, France, and Poland)

Single-member-state processing is excluded. If your platform serves only German users and all operations are in Germany, the German DPA (BfDI/state DPAs) retains full competence without the OSS structure.

Determining Your Main Establishment: The Art.4(16) Test

Art.4(16)(a) — Controller main establishment:

"the place of its central administration in the Union, unless the decisions on the purposes and means of the processing of personal data are taken in another establishment of the controller in the Union and the latter establishment has the power to have such decisions implemented, in which case the establishment having taken such decisions shall be considered to be the main establishment"

Art.4(16)(b) — Processor main establishment:

"the place of its central administration in the Union, or, if the processor has no central administration in the Union, the establishment of the processor in the Union where the main processing activities in the context of the activities of an establishment of the processor take place"

The default is central administration location. But there is an override: where substantive decisions about processing purposes and means are actually made. This is why companies that run their EU data operations from Dublin have the Irish DPC as lead SA, regardless of where the corporate headquarters is registered.

The Decision-Making Test

The EDPB has consistently held (Guidelines 03/2022 on Art.4(7)) that the main establishment is where:

1. Real and effective exercise of management activities over data processing
2. Stable arrangements (not a letterbox entity)
3. Actual power to implement decisions about processing

A holding company registered in Luxembourg that outsources all data decisions to a Dublin engineering team does not qualify as the main establishment. The Dublin office does.

Common mistake: Choosing your main establishment based on corporate registration rather than where data decisions are actually made. SAs will look at where engineers, data architects, and product managers sit — not just the company incorporation documents.

How to Identify Your Lead SA: Decision Flowchart

Q1: Do you process personal data of EU data subjects?
    └─ No → GDPR does not apply (Art.3)
    └─ Yes → Q2

Q2: Do you have an establishment in the EU?
    └─ No → Go to "Third-country entity" section below
    └─ Yes → Q3

Q3: Is the processing cross-border (Art.4(23))?
    └─ No → Lead SA = SA of your sole establishment
    └─ Yes → Q4

Q4: Where is your main establishment?
    └─ Central administration in DE → Lead SA = BfDI/state DPA
    └─ Central administration in IE → Lead SA = Irish DPC
    └─ Central administration in NL → Lead SA = Dutch AP
    └─ Data decisions made elsewhere → Main establishment = where decisions made
    └─ Multiple equal candidates → Notify EDPB (Art.65) for consistency

EU Lead SA Reference Table

Concerned Supervisory Authorities: Art.56(2) and Art.60

When your lead SA investigates you, it does not act alone. Concerned SAs — the SAs of member states where your processing substantially affects data subjects — must be involved under Art.60.

Art.56(2) exception: A local SA remains competent to handle a complaint if:

• The matter relates only to an establishment in its member state, or
• The matter substantially affects data subjects only in its member state

This exception exists to prevent data subjects from being disadvantaged by the OSS. A German user complaining about a German-only service uses the German DPA, full stop.

The Art.60 Cooperation Procedure

When the lead SA proceeds with a cross-border case:

1. Lead SA shares case information with all concerned SAs
2. Draft decision submitted to concerned SAs (Art.60(3))
3. Concerned SAs have 4 weeks to raise relevant and reasoned objections (Art.60(4))
4. If objections raised: lead SA either amends the draft or refers to EDPB consistency mechanism (Art.65)
5. EDPB binding decision (Art.65(1)(a)) if concerned SAs cannot agree
6. Final decision adopted by lead SA, communicated to controller/processor

The lead SA's final decision is binding across all member states for the cross-border processing. A single DPC fine imposed on Meta applies to Meta's processing across all 27 member states — not just Ireland.

Third-Country Entities: No EU Establishment

If you are a non-EU company (US, UK post-Brexit, etc.) processing EU data under Art.3(2) (targeting/monitoring), you must:

1. Appoint an Art.27 EU Representative (mandatory under Art.27(1))
2. Your lead SA is the SA of the member state where your representative is established

Important nuance: Having an EU representative does not make the representative's member state your "main establishment" for all purposes. It only determines OSS competence for companies with no EU establishment at all. Once you have an actual EU subsidiary or branch, Art.4(16) applies instead.

UK post-Brexit: The UK Information Commissioner's Office (ICO) is no longer part of the OSS mechanism. UK companies with EU establishments must determine their lead SA under Art.4(16) for EU GDPR compliance. UK GDPR and EU GDPR are now separate regimes. A company processing UK and EU data needs:

• A lead SA in the EU (under EU GDPR)
• Compliance with UK ICO requirements separately

Art.56(3-5): Local SA Referral Rights

Even when OSS applies, local SAs retain referral powers:

Art.56(3): Any data subject may lodge a complaint with any SA — including their local SA — regardless of where the controller's main establishment is.

Art.56(4): A local SA must forward a cross-border complaint to the lead SA and notify the data subject.

Art.56(5): The lead SA acts as single point of contact for the controller/processor and informs them of any referred complaints.

Art.56(6): If a complaint relates solely to an establishment in the concerned SA's member state, the lead SA must "deal" with it, but the concerned SA acts as the "rapporteur" SA and handles the case locally — a partial exception to OSS primacy.

This created significant practical tension in the early OSS years: German and French SAs routinely referred cases to the Irish DPC, then disagreed with the DPC's draft decisions, triggering EDPB dispute resolution. The Meta, WhatsApp, and TikTok cases all proceeded through this art.60/art.65 mechanism.

Landmark OSS Cases: What Enforcement Looks Like

Meta (Facebook/Instagram) — Irish DPC as Lead SA

• Facts: Irish DPC investigated Meta's legal basis for behavioral advertising (consent vs legitimate interest vs contract performance)
• Process: Art.60 cooperation → concerned SAs (AT, DE, FR, etc.) raised objections → Art.65 EDPB binding decision
• Outcome: EDPB found contract performance basis invalid for behavioral ads → DPC ordered €390M fine (Jan 2023) across both platforms
• Significance: Single DPC decision, enforceable across all member states, triggered by EDPB overriding DPC's draft

TikTok — DPC Lead SA for EU Operations

• Facts: Irish DPC investigated TikTok's processing of children's data and transfers to China
• Process: Art.60 cooperation → Art.65 for parts disputed by concerned SAs
• Outcome: €345M fine (Sep 2023) for children's data privacy failings
• Developer lesson: If your service has any component targeting or serving children across EU, your lead SA's decision will be EDPB-reviewed given the political sensitivity

WhatsApp — DPC Art.60/65 Procedure

• Facts: EDPB overrode DPC's proposed fine calculation in 2021
• Outcome: Final fine €225M — largest DPC fine at the time
• Lesson: Lead SA's initial decision can be overridden by EDPB if concerned SAs coordinate objections

OSS Mechanics: What to Document

As a controller or processor subject to OSS, you need to document and be able to demonstrate:

Python: LeadSADeterminator

from enum import Enum
from dataclasses import dataclass, field
from typing import Optional

class MemberState(Enum):
    DE = "Germany"
    IE = "Ireland"
    FR = "France"
    NL = "Netherlands"
    SE = "Sweden"
    LU = "Luxembourg"
    ES = "Spain"
    IT = "Italy"
    PL = "Poland"
    BE = "Belgium"
    # Add all 27 member states as needed

LEAD_SA_MAP = {
    MemberState.DE: "BfDI / State DPA (bfdi.bund.de)",
    MemberState.IE: "Data Protection Commission (dataprotection.ie)",
    MemberState.FR: "CNIL (cnil.fr)",
    MemberState.NL: "Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl)",
    MemberState.SE: "IMY (imy.se)",
    MemberState.LU: "CNPD (cnpd.public.lu)",
    MemberState.ES: "AEPD (aepd.es)",
    MemberState.IT: "Garante (garanteprivacy.it)",
    MemberState.PL: "UODO (uodo.gov.pl)",
    MemberState.BE: "APD (autoriteprotectiondonnees.be)",
}

@dataclass
class EstablishmentProfile:
    central_admin_state: Optional[MemberState]
    data_decision_state: Optional[MemberState]  # Where processing decisions are made
    has_eu_establishment: bool
    representative_state: Optional[MemberState]  # For Art.27 rep (non-EU entities)
    affected_member_states: list[MemberState] = field(default_factory=list)

@dataclass
class LeadSAResult:
    lead_sa: str
    jurisdiction: MemberState
    rationale: str
    is_cross_border: bool
    concerned_sas: list[str]
    oss_applies: bool

class LeadSADeterminator:
    def determine(self, profile: EstablishmentProfile) -> LeadSAResult:
        is_cross_border = len(profile.affected_member_states) > 1

        if not profile.has_eu_establishment:
            if not profile.representative_state:
                raise ValueError("Non-EU entity must designate Art.27 representative")
            lead = profile.representative_state
            return LeadSAResult(
                lead_sa=LEAD_SA_MAP.get(lead, f"SA of {lead.value}"),
                jurisdiction=lead,
                rationale="No EU establishment — lead SA determined by Art.27 representative location",
                is_cross_border=is_cross_border,
                concerned_sas=self._get_concerned_sas(lead, profile.affected_member_states),
                oss_applies=is_cross_border,
            )

        if not is_cross_border:
            lead = profile.central_admin_state or profile.data_decision_state
            return LeadSAResult(
                lead_sa=LEAD_SA_MAP.get(lead, f"SA of {lead.value}"),
                jurisdiction=lead,
                rationale="Single-member-state processing — OSS does not apply, local SA competent",
                is_cross_border=False,
                concerned_sas=[],
                oss_applies=False,
            )

        # Cross-border: apply Art.4(16) test
        # Data decision location overrides central admin if different
        if (profile.data_decision_state and
                profile.data_decision_state != profile.central_admin_state):
            lead = profile.data_decision_state
            rationale = (
                f"Main establishment = data decision location ({lead.value}) "
                f"overrides central admin ({profile.central_admin_state.value if profile.central_admin_state else 'none'}) — Art.4(16)(a)"
            )
        elif profile.central_admin_state:
            lead = profile.central_admin_state
            rationale = f"Main establishment = central administration location ({lead.value}) — Art.4(16)(a)"
        else:
            raise ValueError("Cannot determine main establishment — provide central_admin_state or data_decision_state")

        return LeadSAResult(
            lead_sa=LEAD_SA_MAP.get(lead, f"SA of {lead.value}"),
            jurisdiction=lead,
            rationale=rationale,
            is_cross_border=True,
            concerned_sas=self._get_concerned_sas(lead, profile.affected_member_states),
            oss_applies=True,
        )

    def _get_concerned_sas(
        self,
        lead: MemberState,
        affected: list[MemberState]
    ) -> list[str]:
        return [
            LEAD_SA_MAP.get(ms, f"SA of {ms.value}")
            for ms in affected
            if ms != lead
        ]


# Example: German startup, engineering in Dublin, users in DE/FR/NL/PL
profile = EstablishmentProfile(
    central_admin_state=MemberState.DE,
    data_decision_state=MemberState.IE,  # Engineers + data decisions in Dublin
    has_eu_establishment=True,
    affected_member_states=[MemberState.DE, MemberState.FR, MemberState.NL, MemberState.PL],
)

det = LeadSADeterminator()
result = det.determine(profile)
print(f"Lead SA: {result.lead_sa}")
print(f"Rationale: {result.rationale}")
print(f"Concerned SAs: {result.concerned_sas}")
# Lead SA: Data Protection Commission (dataprotection.ie)
# Rationale: Main establishment = data decision location (Ireland) overrides central admin (Germany) — Art.4(16)(a)
# Concerned SAs: [BfDI / State DPA, CNIL, Autoriteit Persoonsgegevens, UODO]

Art.56 for SaaS and PaaS Developers: Practical Checklist

Determining your lead SA (do this once, review annually):

• Map all EU member states where your processing affects data subjects (Art.4(23) cross-border test)
• Identify where central administration is (corporate registration and actual management)
• Identify where data processing decisions are made (engineers, product, data architecture)
• If different: document the override and file with the SA of where decisions are made
• If no EU establishment: designate Art.27 representative; their member state becomes OSS jurisdiction
• Register DPO with lead SA under Art.37(7) (if DPO required or voluntary)
• Notify lead SA of main establishment formally if investigating a complaint (Art.56(6))

Operational OSS readiness:

• Single contact point within organisation for lead SA communications
• Lead SA investigation response procedures documented (complement Art.31 cooperation)
• Art.60 cooperation awareness: responses must address all concerned SA questions, not just lead SA
• EDPB consistency mechanism awareness: know that lead SA decisions can be overridden (Art.65)
• Record which member states constitute "concerned SAs" in your RoPA (Art.30)
• Brexit note: if UK operations, UK ICO compliance is separate from EU lead SA

Startup-specific note (common mistakes):

• Do not conflate tax residency with GDPR main establishment — different tests
• Letterbox entities do not qualify as main establishment (EDPB Guidelines 03/2022)
• Do not file a GDPR complaint response with the wrong SA — it wastes time and signals poor compliance
• If relocating EU operations (e.g. DE → IE or vice versa), update Art.37(7) DPO registration with new lead SA

sota.io and Art.56

sota.io is a data processor under Art.4(8) for customer applications deployed on its infrastructure. Under Art.56:

• sota.io's lead SA is determined by its main establishment (German entity with German operations → German DPA competence)
• Customer controllers determine their own lead SA based on their main establishment — sota.io's location does not determine the customer's lead SA
• Art.28 DPA includes audit rights that align with Art.56 cooperation — SAs can investigate sota.io directly under Art.31 for customer data processed on its infrastructure
• Cross-border reach: sota.io processes data for customers serving multiple EU member states, making it subject to OSS for its own processing activities

For developers evaluating EU PaaS: your infrastructure provider's lead SA affects the SA investigation chain for sub-processor audits under Art.58(1)(e). Choosing a processor with a German lead SA (as opposed to a US-headquartered cloud with no clear EU main establishment) simplifies your own OSS compliance picture.

See Also

• GDPR Art.31: Cooperation with Supervisory Authorities — what happens during an SA investigation
• GDPR Art.57-58: SA Tasks and Powers — SA investigative and corrective powers
• GDPR Art.83-84: Administrative Fines — fine calculation for cross-border decisions
• GDPR Art.27: EU Representative Obligation — Art.27 rep for non-EU entities
• GDPR Art.37-39: DPO Requirements — DPO registration with lead SA