A main establishment is the organisation’s central decision-making location in the EEA for cross-border processing. A supervisory authority concerned is any authority affected because the organisation is established there, data subjects there are substantially affected, or a complaint is filed there. The lead authority coordinates oversight, while concerned authorities still retain an enforcement role.
How GDPR Splits Central Control from Local Concern
A main establishment is about where the organisation makes the key cross-border decisions. A supervisory authority concerned is about which authorities have a stake in those decisions because of where the organisation operates, where people are affected, or where a complaint lands. The distinction matters because it determines who leads, who participates, and when coordination is mandatory.
For cross-border processing, the main establishment is the anchor point for the lead supervisory authority. That lead authority typically takes the coordinating role on the case, but it does not erase the role of other authorities. If the controller or processor has meaningful activity in multiple EEA states, the regulatory picture is inherently shared rather than purely local.
A supervisory authority concerned is therefore broader than a simple “other regulator.” It can be involved because the organisation is established in that state, because data subjects there are substantially affected, or because a complaint was filed there. In practice, this means a single processing activity can trigger both a central lead and several concerned authorities, each with a legitimate enforcement interest.
Why the Two Roles Are Not Interchangeable
The main establishment test is organisational and structural, while the concerned authority test is situational and impact-based. Main establishment asks where strategic decisions on the processing are actually made, not where a head office is registered on paper. Concerned authority asks whether that authority has a direct regulatory connection to the processing outcome or the people affected by it.
This is why an organisation can have one main establishment but several concerned authorities for the same processing operation. The lead authority does the coordination, but local authorities are not reduced to observers. They may review the facts, weigh in on objections, and remain part of the enforcement path when the case has local impact.
For practitioners, the operational point is that jurisdiction is not just a legal label, it is a case-management design. If cross-border processing is ongoing, the organisation should know which entity is the main establishment, which authority is likely to lead, and which other authorities may become concerned through establishment, impact, or complaint channels.
What This Means When You Map a Real Processing Activity
In a live GDPR assessment, the first question is not only “where are we headquartered?” It is “where are the key decisions for this processing actually taken, and where are the affected data subjects located?” If those answers differ, the authority picture usually becomes multi-jurisdictional.
That is especially important when complaints, incident handling, or enforcement follow the flow of the data rather than the corporate chart. A complaint can make an authority concerned even where the organisation has no central decision-making role there. Likewise, substantial local impact can bring in concerned authorities even if the processing strategy is directed elsewhere.
For a useful reference point on the regulation itself, the EU General Data Protection Regulation (GDPR) remains the clearest public text for the underlying rules on cross-border processing, including the provisions that shape supervisory cooperation. NHIMG also maintains an Identity Security Regulatory Map that helps practitioners place GDPR alongside other regulatory regimes when governance spans multiple control domains.
Risk and Threat Considerations
Misidentifying the main establishment can create a coordination problem, not just a paperwork issue. If the lead authority is assumed incorrectly, an organisation may notify the wrong regulator first, miss objection timelines, or fail to anticipate parallel scrutiny from other concerned authorities.
Failure mechanism: The organisation treats corporate structure as the same thing as decision-making control, then underestimates which authorities are entitled to participate in cross-border oversight. That can delay response, fragment communications, and increase the chance of inconsistent positions across jurisdictions.
Impact: The result can be duplicated regulatory engagement, slower resolution of complaints or incidents, and a weaker defence if authorities disagree on the facts or the scope of the processing.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 sets the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art. 4(16) — Main Establishment | Defines main establishment for cross-border processing and lead authority allocation. |
| Art. 4(22) — Supervisory Authority Concerned | Defines when an authority becomes concerned by establishment, impact, or complaint. | |
| Art. 56 — Lead Supervisory Authority | Sets the lead authority coordination model for cross-border processing cases. | |
| Recommendation — Document the actual decision-making centre for each cross-border processing activity. Map each processing activity to every authority that may be concerned by its effects. Route cross-border cases through the lead authority while preserving local authority involvement. | ||
| ISO/IEC 27001:2022 | A.5.35 — Independent review of information security | Supports independent checking of governance and compliance arrangements across jurisdictions. |
| Recommendation — Review cross-border governance arrangements independently against the documented operating model. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Helps define the legal and regulatory context in which cross-border processing occurs. |
| Recommendation — Document the regulatory context and processing footprint before assigning authority roles. | ||
Practitioner Guidance
What to verify: Confirm where the key processing decisions are actually made, who can change those decisions, and whether that governance is documented in a way that matches operational reality. If the organisation has distributed decision-making, do not assume there is a single clean lead authority without checking the facts.
What to prioritise: Build a cross-border mapping that ties each major processing activity to the likely lead authority and the set of authorities that could become concerned through establishment, effect, or complaint. That mapping is most valuable when it is maintained per processing activity, not only per legal entity.
Practitioner takeaway: The practical distinction is that main establishment drives coordination, while concerned authority drives participation, so cross-border GDPR governance fails when organisations confuse central control with local regulatory interest.
Related resources from NHI Mgmt Group
- What is the difference between notifying the supervisory authority and notifying impacted data subjects under GDPR?
- What is the difference between a data fiduciary under DPDPA and a data protection authority under GDPR?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
