Article 26: Jurisdiction and territoriality

To meet the article 26: jurisdiction and territoriality requirement, you must determine which EU Member State has supervisory jurisdiction over your NIS 2 in-scope entity based on where you are established (and document that decision), then route incident reporting, regulator engagement, and program ownership through that competent authority. This is a governance and operational mapping task anchored in Article 26 of NIS 2. (Directive (EU) 2022/2555, Article 26)

Key takeaways:

• Your first deliverable is a defensible jurisdiction determination memo tied to establishment facts and kept audit-ready.
• Operationalize jurisdiction by hard-wiring it into incident reporting playbooks, regulator contacts, and control ownership.
• Multi-country footprints fail when teams treat NIS 2 as “EU-wide” without a clear primary competent authority and local execution mapping.

Article 26 of NIS 2 answers a deceptively simple question regulators will ask early: “Which Member State is responsible for supervising you?” The directive’s default is straightforward: entities in scope fall under the jurisdiction of the Member State where they are established. (Directive (EU) 2022/2555, Article 26) For operators, the work is less about legal theory and more about preventing execution drift across countries, business units, and third parties.

If you are a Compliance Officer, CCO, or GRC lead, you need two things fast: (1) a clear internal decision on jurisdiction that you can defend using corporate establishment facts, and (2) an operating model so the right teams notify the right authority, on time, with consistent evidence. The fastest way to fail this requirement is to “assume” jurisdiction based on where revenue is earned, where customers sit, or where data centers run, without documenting the establishment basis and embedding it into incident and governance workflows.

This page gives requirement-level guidance you can implement immediately: how to decide jurisdiction, how to encode it into your NIS 2 obligation register, and what artifacts you should retain so an examiner can follow your logic without guesswork.

Regulatory text

Excerpt (provided): “Entities falling within the scope of this Directive shall be considered to fall under the jurisdiction of the Member State in which they are established, except in the case of:” (Directive (EU) 2022/2555, Article 26)

Operator meaning: Your NIS 2 program must be anchored to a specific Member State supervisory jurisdiction based on establishment, with documented reasoning and a working process that routes oversight and notifications accordingly. Article 26 also signals that exceptions exist (the excerpt ends mid-sentence), so you must read the full Article 26 text and any national transposition rules that apply to your footprint. (Directive (EU) 2022/2555, Article 26) (Directive (EU) 2022/2555)

Plain-English interpretation

• Default rule: If you are in scope, the Member State where you are established is your supervisory “home.” (Directive (EU) 2022/2555, Article 26)
• Your job: Convert that rule into an internal decision that is (a) evidence-based, (b) consistently applied across business and IT operations, and (c) reflected in your incident reporting and regulator engagement mechanics.
• Why regulators care: Jurisdiction determines which authority receives your notifications, asks follow-up questions, and may open supervisory actions. If you cannot show a consistent jurisdiction logic, regulators will assume your governance is immature even if your technical controls are solid.

Who it applies to (entity and operational context)

This requirement applies to entities falling within the scope of NIS 2 that operate in the EU and meet the directive’s scope conditions. (Directive (EU) 2022/2555, Article 26) Practically, you should treat it as applying to:

• EU-established legal entities that are in-scope (essential or important) and provide covered services.
• Groups with multiple EU establishments where different subsidiaries operate services that may each be in scope.
• Organizations with complex operating models (shared SOC, centralized incident response, shared IT, or outsourced operations) where reporting and regulator communications could easily be misrouted.

Operationally, Article 26 touches:

• Corporate governance: entity structures, registered office, and where management decisions are anchored.
• Security operations: who declares an incident and who sends the notification.
• Third-party risk: which entity contracts with critical third parties and which authority expects oversight evidence.

What you actually need to do (step-by-step)

Step 1: Build a “jurisdiction facts pack”

Collect verifiable facts for each potentially in-scope legal entity:

• Legal entity name, registration details, and registered office address
• Member State(s) of establishment for each in-scope entity
• Which services and systems each entity operates or controls
• Which entity is the contracting party for key third parties supporting those services (cloud, MSSP, telecom, managed hosting)

Output: a structured worksheet (or GRC record) that ties services to legal entities and countries.

Step 2: Determine the supervising Member State per entity (and document it)

Apply the default rule: the entity falls under the jurisdiction of the Member State where it is established, subject to Article 26 exceptions. (Directive (EU) 2022/2555, Article 26)

Create a short jurisdiction determination memo per entity:

• Your conclusion: “Entity X falls under jurisdiction of Member State Y”
• The establishment facts used
• Confirmation you reviewed Article 26 in full for exceptions and how you handled them (for example: “No exception applied” or “Exception applied; see analysis”)
• Owner and approver (Compliance/Legal plus Security leadership)

Why this memo matters: It becomes the anchor artifact auditors and regulators will ask for when they see cross-border operations.

Step 3: Create a NIS 2 obligation register with jurisdictional applicability

Maintain a single obligation register that lists:

• The obligation (e.g., incident reporting requirements, governance requirements)
• The jurisdictional owner Member State for each in-scope entity
• Control owners (Security, IT, Legal, Compliance)
• Implementation milestones and operational status

This is directly aligned with the recommended control: “Maintain a NIS 2 obligation register with jurisdictional applicability notes, control owners, and implementation milestones.” (Directive (EU) 2022/2555, Article 26)

Practical tip: If your GRC tool can’t model per-entity jurisdiction cleanly, keep a controlled spreadsheet with versioning and approvals. Examiners prefer a maintained register over a perfect tool that no one trusts.

Step 4: Hard-wire jurisdiction into incident workflows

Update incident response so the “who do we notify?” decision is not made during a crisis. Codify:

• Triage criteria and escalation path
• A step for confirming the impacted legal entity and its Member State jurisdiction
• Regulator contact list mapped to jurisdiction
• Evidence retention checklist for each stage of the incident workflow

This aligns to the recommended control: “Codify incident triage, escalation, and reporting workflows with timing triggers and evidence retention requirements.” (Directive (EU) 2022/2555, Article 26)

Minimum operational requirement: Your SOC/IR team can identify the impacted entity and jurisdiction from a single source of truth during the first escalation.

Step 5: Align third-party oversight to the right regulated perimeter

Many cross-border failures come from third-party operations being centralized while obligations are entity-specific. For each critical third party:

• Map which in-scope entity relies on the third party for the covered service
• Ensure contracts, SLAs, and incident notification clauses support your jurisdiction-specific reporting path
• Ensure assurance activities (risk assessments, audits, SOC reports) are stored and retrievable per in-scope entity

This aligns to the recommended control: “Integrate critical third-party dependencies into risk assessments, remediation tracking, and assurance activities.” (Directive (EU) 2022/2555, Article 26)

Step 6: Operational governance: name owners and test the model

Run a tabletop that tests:

• Can we identify the impacted legal entity fast?
• Do we know which Member State authority is responsible?
• Can Legal/Compliance approve the notification path without hunting for facts?
• Can we produce the jurisdiction memo and obligation register on request?

Track gaps as remediation items with owners and due dates.

Required evidence and artifacts to retain

Keep these artifacts “exam ready” (controlled, dated, and attributable):

1. Jurisdiction determination memo per in-scope entity (approved)
2. Entity-to-service mapping (service catalog view tied to legal entity and establishment)
3. NIS 2 obligation register with jurisdiction field and control owners (Directive (EU) 2022/2555, Article 26)
4. Incident reporting playbooks reflecting jurisdiction routing and regulator contacts (Directive (EU) 2022/2555, Article 26)
5. Incident exercise records (tabletop agenda, attendees, outcomes, remediation tickets)
6. Third-party dependency map for critical services, plus assurance evidence repository index (Directive (EU) 2022/2555, Article 26)
7. Change control evidence showing jurisdiction decisions are reviewed when entity structure or services change (M&A, re-org, outsourcing)

Common exam/audit questions and hangups

Expect these questions from internal audit, external assurance, or supervisory reviewers:

• “Which Member State supervises this entity for NIS 2, and why?” (Directive (EU) 2022/2555, Article 26)
• “Show me where that decision is documented and who approved it.”
• “If an incident impacts a shared platform used by multiple subsidiaries, who decides which authority is notified?”
• “How does your SOC determine which legal entity is affected?”
• “Where is the single source of truth for regulator contacts and reporting routing?”
• “How do third-party incident notifications flow to the correct in-scope entity and authority?”

Hangup to anticipate: organizations often maintain technical incident processes without the legal entity mapping needed to make jurisdiction determinations quickly.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating NIS 2 as one EU-wide program without entity-level jurisdiction	Creates conflicting reporting paths and unclear accountability	Maintain per-entity jurisdiction decisions and map controls to entities (Directive (EU) 2022/2555, Article 26)
Relying on tribal knowledge for “which authority to call”	Breaks under stress, staff turnover, or mergers	Maintain a regulator contact roster tied to the obligation register
Incident process can’t identify impacted legal entity	You can’t route notifications correctly	Add an “impacted entity” field to incident tickets and make it mandatory for escalation
Third-party oversight stored centrally with no entity linkage	Evidence retrieval fails during exams	Tag assurance artifacts to each in-scope entity and critical service
Not revisiting jurisdiction after corporate changes	Establishment facts drift	Add jurisdiction review to M&A and legal entity change management

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list case examples.

Risk implications to brief leadership on:

• Supervisory friction risk: Misrouted notifications or unclear jurisdiction slows response and invites deeper supervisory scrutiny.
• Operational risk during incidents: Teams lose time debating where to report rather than containing and communicating.
• Program governance risk: If you cannot explain jurisdiction cleanly, your broader NIS 2 governance credibility drops, and exam scope often widens.

Practical 30/60/90-day execution plan

Use phases to avoid fake precision while still driving execution.

Immediate (triage and containment)

• Assign a single accountable owner for jurisdiction mapping (usually Compliance/Legal with CISO support).
• Identify all potentially in-scope EU legal entities and collect establishment facts.
• Stand up a draft obligation register with a jurisdiction field. (Directive (EU) 2022/2555, Article 26)

Near-term (operationalization)

• Finalize jurisdiction determination memos and approvals.
• Update incident runbooks and SOC ticketing fields to capture impacted entity and jurisdiction.
• Build regulator contact rosters and escalation paths by Member State.
• Map critical third parties to in-scope entities and critical services; define where evidence will live.

Ongoing (test and maintain)

• Run at least one cross-border incident tabletop focused on “shared platform, multiple entities.”
• Add jurisdiction mapping review to corporate change processes (new entities, closures, service launches).
• Use a GRC system (or a controlled register) to track obligations, owners, and implementation milestones; Daydream is often the simplest place to maintain the obligation register and link it to incident and third-party evidence for exam retrieval. (Directive (EU) 2022/2555, Article 26)

Frequently Asked Questions

What does “established” mean operationally for Article 26?

Treat it as a legal-entity establishment question first, backed by corporate registration and registered office facts. Document your reasoning in a jurisdiction memo and keep it aligned to your entity structure. (Directive (EU) 2022/2555, Article 26)

We operate in multiple Member States. Do we have multiple jurisdictions?

You can, depending on which legal entities are in scope and where each is established. Build the mapping per entity and ensure your incident workflow can identify the impacted entity before notifications go out. (Directive (EU) 2022/2555, Article 26)

Our SOC is centralized outside the EU. Does that change jurisdiction?

Article 26 anchors jurisdiction to establishment for in-scope entities, not where the SOC sits, based on the provided excerpt. Operationally, you still need a workflow that routes reporting through the correct Member State authority. (Directive (EU) 2022/2555, Article 26)

What artifact do auditors ask for first on jurisdiction?

A short jurisdiction determination memo that cites establishment facts and references Article 26, plus an obligation register that applies that decision across controls and reporting workflows. (Directive (EU) 2022/2555, Article 26)

How should we handle shared services (one platform serving multiple subsidiaries)?

Add a decision step in incident triage to identify the impacted legal entity or entities, then apply the jurisdiction mapping to determine the reporting route. Test this in a tabletop because shared services are where confusion shows up. (Directive (EU) 2022/2555, Article 26)

What should we do if we think an Article 26 exception applies?

Pull the full Article 26 text and document the exception analysis explicitly in your jurisdiction memo, including who reviewed and approved it. Keep Legal involved and align the decision to incident reporting and regulator engagement workflows. (Directive (EU) 2022/2555, Article 26) (Directive (EU) 2022/2555)