NIS2 Compliance for Large Enterprises (250+ Staff): The Group-vs-Entity Framework Multinationals Get Wrong

Large enterprises don’t fail NIS2 because they under-invest. ENISA’s 2025 NIS Investments survey of 1,080 EU organisations skewed heavily toward large enterprises — 83% of respondents — and compliance spending is climbing across the board. They fail because the program is built for one legal entity, and a large enterprise is rarely one. It’s a parent company, a handful of operating subsidiaries, maybe a shared-services arm, spread across three or four Member States, each one a separate legal person under NIS2 — whether the group treats it that way or not.

That mismatch — a single group-wide policy binder standing in for entity-by-entity compliance — is the most common structural error in large-organisation NIS2 programs, and it’s the subject of this guide: how scope, governance, jurisdiction, and tooling change once an organisation crosses the 250-staff line and starts operating as a group rather than a single company.

Does This Apply to Your Organisation? The Large-Enterprise Scope Test

In plain terms: if your organisation employs 250 or more people, it is almost certainly in scope for NIS2 as a large enterprise — the only remaining question is whether it lands in the stricter “essential” tier or the “important” tier, and that depends on sector, not size.

NIS2’s size test isn’t a NIS2-specific number. Article 3 pulls its size-cap straight from Commission Recommendation 2003/361/EC, the EU’s standard definition of a medium-sized enterprise: fewer than 250 staff, and annual turnover not exceeding €50 million and/or a balance sheet not exceeding €43 million [1][2]. That “and/or” matters more than most summaries let on. Staff headcount of 250 or more is sufficient on its own — turnover is irrelevant at that point. Below 250 staff, an entity only exceeds the medium ceiling if turnover tops €50 million and the balance sheet tops €43 million at the same time; clearing just one of those two financial tests still leaves it classified as medium [1b].

Your entity	Sector type	NIS2 classification
250+ staff, or >€50m turnover AND >€43m balance sheet	Annex I (energy, transport, banking, financial infrastructure, health, water, digital infrastructure, ICT B2B management, space, public administration)	Essential entity
250+ staff, or >€50m turnover AND >€43m balance sheet	Annex II (postal/courier, waste, chemicals, food, manufacturing, digital providers, research)	Important entity
Any size	Qualified trust service providers, TLD name registries, DNS service providers	Essential — size-independent
Under 250 staff and under both financial ceilings	Any	Generally out of scope, unless nationally designated

If your organisation sits under that 250-staff line, the size-cap analysis and the rest of this framework don’t apply the same way — see our 90-day SME compliance roadmap instead. For the full essential-vs-important breakdown by sector, see our essential vs. important entities guide. What the rest of this article covers is what changes once an organisation clears that line and operates as a group of legal entities rather than one company — because the scope test above has to be run separately, entity by entity, not once for the whole group.

Group-Level vs. Entity-Level Compliance: Why Parent Sign-Off Isn’t Enough

In plain terms: a parent company’s security policy is a starting template, not a compliance certificate — every subsidiary that independently clears the scope test has to adopt, approve, and evidence that policy on its own.

The single most expensive mistake a large group makes is treating NIS2 as a group-wide project with one finish line. NIS2 doesn’t recognise “the group” as a compliance subject. It recognises legal entities. A parent company that approves a single security policy, rolls it out as a PDF to twelve subsidiaries, and calls the program complete has produced a document, not compliance — each of those twelve subsidiaries still has to independently meet its own registration, risk-management, and incident-notification obligations under whichever national law transposes NIS2 in its own Member State [4].

Where group-level thinking does apply is the scope test itself. Determining whether a subsidiary crosses the 250-staff or financial threshold uses consolidated group figures for “linked” enterprises — majority voting control, broadly — and a proportional share of “partner” enterprise figures, where an upstream enterprise holds 25% or more of the capital or voting rights, under the same Recommendation 2003/361/EC framework that defines the size-cap [1c]. That produces a counter-intuitive result competitors rarely spell out: a 90-person subsidiary that would be comfortably under the threshold on its own numbers can still be pulled into scope because its parent’s headcount and turnover get added to its own for the classification test — even though the compliance obligation that follows is the subsidiary’s alone to meet.

The practical gap analysis looks like this:

Current state (typical large group)	Required state under NIS2	Effort to close
One group-wide security policy, centrally owned	Each in-scope entity adopts and can evidence its own Article 21 risk-management measures	Medium — policy content can be shared, ownership and evidence cannot
Group headcount used loosely to judge “are we big enough to worry about this”	Entity-by-entity classification using consolidated/partner figures per subsidiary	Medium — a spreadsheet exercise, but easy to get wrong without legal input
Single incident response plan, group SOC	Each entity capable of meeting its own national 24-hour early-warning and 72-hour notification obligations to its own competent authority	High — shared SOC works operationally, but notification duty and record-keeping stay entity-specific
No documented answer to “which subsidiaries are actually in scope”	A maintained, entity-level scope register reviewed at least annually	Low-Medium once the first pass is done

Subsidiary Scoping: A Decision Framework for Group Companies

In plain terms: run three separate questions per subsidiary — is it in scope, what classification does it get, and which national authority does it answer to — because a “yes” on the first question doesn’t automatically answer the other two the same way for every entity in the group.

Groups that get this wrong almost always collapse the three questions into one. A subsidiary manufacturing components in Poland, a shared IT-services entity in Ireland, and a logistics arm in Romania can all belong to the same 4,000-employee group and still land in three different places: one as an important entity under Annex II manufacturing rules, one as an essential entity because ICT service management to other businesses sits in Annex I, and one possibly out of scope entirely if it falls under both financial ceilings on a standalone basis and isn’t majority-owned in a way that triggers consolidation.

Work the three questions in this order:

1. Is this subsidiary in scope at all? Apply the 250-staff / €50m-turnover-and-€43m-balance-sheet test using consolidated figures for majority-owned (linked) entities and proportional figures for 25%+ (partner) holdings, not the subsidiary’s standalone numbers [1c].
2. Which classification does it get? This is sector-driven, not size-driven once scope is established — the same headcount lands an Annex I entity as “essential” and an Annex II entity as “important,” with different supervisory intensity and penalty ceilings attached.
3. Which competent authority does it answer to? This is the question groups skip entirely, and it’s the subject of the next section — because for most large enterprises, the answer is “more than one.”

A maintained scope register — one row per legal entity, updated at least annually and whenever headcount, ownership, or turnover shifts materially — is the single artefact that answers all three questions on demand. Without it, “are we compliant” becomes a re-investigation every time an auditor, acquirer, or new subsidiary asks.

The Multi-Jurisdiction Reality: Article 26 and Concurrent Authority

In plain terms: unless your entity is a cloud provider, DNS provider, data centre, CDN, managed service provider, or one of a handful of other named digital-service categories, there is no “lead regulator” shortcut — a manufacturer, bank, or energy company with establishments in four Member States answers to all four national authorities, separately.

Article 26(1) sets the general rule plainly: an entity falls under the jurisdiction of the Member State in which it is established [4]. Read at group scale, that rule does the heavy lifting on its own — each subsidiary is its own “entity” for NIS2 purposes, so each one answers to its own Member State. A group with essential or important subsidiaries in Germany, France, and Poland isn’t managing one jurisdiction question with three data points; it’s managing three separate compliance relationships, each with its own registration and its own supervisory contact, running in parallel. The directive’s recitals note that authorities in different Member States are expected to cooperate on entities they jointly encounter [4] — but that’s cooperation between regulators, not a shortcut that consolidates the group’s obligations into one relationship.

NIS2 does carve out a one-stop-shop exception, and this is where most large-enterprise content oversells the relief available. Article 26(1)(b)’s single-jurisdiction mechanism is scoped narrowly to specific entity types: DNS service providers, TLD name registries, domain-name registration service providers, cloud computing service providers, data centre service providers, content delivery network providers, managed service and managed security service providers, online marketplaces, online search engines, and social networking platforms [4]. A manufacturer running four plants across the EU, a bank with subsidiaries in three Member States, or an energy operator with cross-border infrastructure gets none of that relief — each establishment answers to its own national authority in full, with no lead-regulator shortcut. For the narrow set of entities that do qualify, “main establishment” is determined by a three-step fallback: first, the Member State where cybersecurity risk-management decisions are predominantly taken; second, if that can’t be determined, where cybersecurity operations are actually carried out; third, the establishment with the highest EU headcount [4]. For the full walkthrough of how that test is applied, see our Article 26 jurisdiction deep-dive.

This is compounded by a fact generic NIS2 content treats as settled and shouldn’t: national transposition is still, in mid-2026, a moving target. The European Commission issued reasoned opinions to 19 Member States in May 2025 for failing to fully notify NIS2 transposition, and by mid-2026 had referred four of them — Ireland, Spain, France, and the Netherlands — to the Court of Justice of the EU over the same failure [7]. Germany, by contrast, brought its NIS2UmsuCG into force on 6 December 2025, covering an estimated 29,500 entities through a two-step BSI registration process [6]. A group with establishments in Germany and Ireland is, right now, compliant against two different maturity levels of national law — a strong argument for building the group’s internal control set to the Directive’s Article 21 baseline rather than to any single Member State’s current implementing text. Our transposition tracker follows country-by-country status as it changes.

CISO Governance Structure at Group Scale

In plain terms: Article 20 makes the management body — not the security team — personally accountable for approving risk-management measures, and at group scale that duty doesn’t delegate cleanly to one central CISO; it needs to be mapped to an accountable officer per legal entity.

Article 20 is explicit that the management body of each essential and important entity must approve the Article 21 risk-management measures the entity takes, oversee their implementation, and “can be held liable for infringements” [5]. Management body members must also undergo training so they can meaningfully assess cybersecurity risk [5]. Read literally, that obligation attaches to the management body of each in-scope entity — a single group CISO reporting into the parent board satisfies Article 20 for the parent, but not automatically for every subsidiary board that carries an approval-and-liability duty of its own.

The governance structures that hold up under audit at group scale generally split the role in two:

Role	Owns	Reports to
Group CISO / Group Security Officer	Baseline control framework, shared tooling, group-wide risk register, coordination across national authorities	Parent management body
Entity-level accountable officer (per in-scope subsidiary)	Local sign-off of Article 21 measures for that entity, local incident-notification execution, local evidence pack for its own competent authority	Subsidiary management body, with a dotted line to the Group CISO
Subsidiary management board	Formal approval of the entity’s risk-management measures and personal liability for that approval	Its own national competent authority, on request

Compliance teams working through this structure consistently find the same failure mode: the group CISO produces excellent group-wide policy, but no individual subsidiary board can point to a dated approval record of its own. “Our parent has a CISO” is not the evidence a national authority is asking for — a board resolution, at that specific entity, is. For a structured approach to that sign-off, see our CISO responsibilities guide and Article 20 board liability breakdown.

GRC Platform Requirements for Multi-Entity Compliance

In plain terms: a GRC platform built for one company breaks down at group scale not because it lacks features, but because it has no concept of “the same control, ten different owners, ten different audit trails.”

Article 21(2) sets out ten measure categories every in-scope entity must address: risk-analysis policy, incident handling, business continuity and backup, supply chain security, secure system acquisition and development, effectiveness-assessment procedures, cyber hygiene and training, cryptography policy, HR security and access control, and multi-factor or continuous authentication [3]. For a single entity, a control library mapped to those ten categories is most of the work. For a group running the same library across five, fifteen, or forty legal entities, the requirements shift:

• Entity-scoped control ownership — the same Article 21(2)(d) supply-chain control needs a distinct, named owner and a distinct evidence trail at each entity, even where the underlying policy text is shared.
• Per-authority reporting output — because Article 26 puts each establishment under its own national authority’s supervision, the platform needs to produce entity-specific, authority-ready reporting rather than one group dashboard.
• Consolidated risk visibility without collapsing entity accountability — the group board needs an aggregate risk picture; each subsidiary board still needs its own defensible approval record. A platform that only supports one of those views forces a manual reconciliation exercise every audit cycle.
• Change propagation with local sign-off gates — when the group updates a baseline policy, each entity’s accountable officer needs to re-approve the change locally, not inherit it silently.

The deciding question for any GRC platform pitched at a multi-entity program isn’t whether it “supports NIS2” — most claim to, usually by mapping ISO 27001 controls onto Article 21 headings. It’s whether the platform can produce, on demand, ten separate and non-identical evidence packs from one shared control library. One group-wide export means the group is still doing entity-level compliance in a spreadsheet on the side.

Compliance Checklist and Deadlines

In plain terms: there is no single group-wide deadline — each entity’s clock runs against its own Member State’s transposition date, which is why a maintained, dated checklist per entity beats a single group Gantt chart.

Step	Owner	Timing
Run the scope test per legal entity (consolidated/partner figures)	Group compliance / legal	Before anything else — annually thereafter
Confirm essential vs. important classification per entity	Group compliance / legal, entity input	Immediately after scoping
Register each in-scope entity with its own national competent authority	Entity-level accountable officer	Per that Member State’s registration deadline — Germany’s statutory window has already closed as of this writing; other states vary
Management body formally approves Article 21 measures, per entity	Subsidiary management board	Before or alongside registration
Stand up entity-specific incident-notification capability (24hr early warning, 72hr assessment)	Group SOC + entity-level officer	Operational before go-live, not after first incident
First independent audit evidencing compliance	Entity-level officer, external auditor	By 30 June 2026 in jurisdictions applying that extended deadline — confirm locally, as this varies by Member State

Penalty Exposure: Why It’s Per Entity, Not Per Group

In plain terms: the fine is levied on the individual entity, but the turnover used to calculate it is the parent group’s — Article 34 fixes the percentage-based ceiling against “the total worldwide annual turnover…of the undertaking to which the essential entity belongs,” not the subsidiary’s own revenue [5b]. A small subsidiary with a large parent carries the parent’s revenue exposure, even though the compliance failure and the fine are entity-specific.

That cuts both ways operationally: the subsidiary still has to independently meet its own registration and Article 21 evidence obligations — group turnover determines how big the fine could be, it doesn’t lower the bar for compliance or shift the obligation up to the parent. A well-run group CISO function doesn’t shield an under-resourced subsidiary from enforcement in its own Member State; from a supervisory authority’s perspective, the entity’s own compliance record and the group’s turnover are two separate facts that combine at the penalty stage, not before.

Entity classification	Maximum penalty	Supervision style
Essential entity	€10 million or 2% of the parent undertaking’s global turnover, whichever is higher [5b]	Proactive — authorities can inspect without a triggering incident
Important entity	€7 million or 1.4% of the parent undertaking’s global turnover, whichever is higher [5b]	Reactive — typically triggered by an incident or complaint

Because enforcement runs per Member State, a group with essential entities in four countries carries four separate maximum-penalty exposures, not one capped group-wide figure. For jurisdiction-specific enforcement patterns, see our Germany enforcement guide and the broader NIS2 penalties overview.

Frequently Asked Questions

Does a parent company’s NIS2 compliance cover its subsidiaries automatically?
No. Each legal entity that independently meets the scope test has its own registration, risk-management, and notification obligations, regardless of what the parent has implemented [4]. Shared policy content helps; it doesn’t substitute for entity-level approval and evidence.

Are all our subsidiaries automatically “large enterprises” because our group is large?
Not on their own numbers, but often yes once consolidation applies. A subsidiary under 250 staff can still be pulled into scope if its figures are consolidated with a majority-owning parent, or proportionally combined with a 25%+ partner holding [1c].

Can we use a single lead regulator for the whole group?
Only if the entity falls into one of the categories Article 26(1)(b) names — DNS/TLD/domain-registration providers, cloud, data centre, CDN, managed service/security providers, online marketplaces, search engines, social networks. Manufacturers, financial groups, energy operators, and most other large enterprises don’t qualify. Under Article 26(1)’s general rule, each subsidiary answers to the competent authority of the Member State where that subsidiary is established — so a group with establishments in four Member States is managing four separate regulatory relationships [4].

Who is personally liable if a subsidiary fails to comply?
That subsidiary’s own management body. Article 20 attaches approval, oversight, and infringement liability to the management body of each entity, not the group’s central security function [5].

What’s the fastest way to find out which of our entities are actually in scope?
Build the scope register first, entity by entity, using consolidated or partner-adjusted figures rather than group headcount as a proxy, then classify and jurisdiction-map only the entities that clear the test. Skipping straight to policy work without that register is the most common source of wasted effort in large-group programs.

Key Takeaways

NIS2 was written around the legal entity, not the corporate group, and every structural decision in a large-enterprise compliance program follows from that fact. Scope is tested per entity, using consolidated figures. Classification is sector-driven and can differ across the same group. Jurisdiction is concurrent, not centralised, for all but a narrow list of digital-service entity types. Governance liability attaches to each subsidiary’s management body. Penalty exposure is calculated, and enforced, per entity — not against the group’s combined risk posture.

The groups that get through an audit cleanly are the ones that built an entity-level scope register before they built a single policy document. That register is the one artefact everything else here — classification, jurisdiction mapping, governance sign-off, GRC evidence, deadline tracking — hangs off.

Sources

[1] Directive (EU) 2022/2555 (NIS2), Article 3 — EUR-Lex
[1b] Commission Recommendation 2003/361/EC, Annex Article 2 (size ceilings) — EUR-Lex
[1c] Commission Recommendation 2003/361/EC, Annex Article 3 (partner/linked enterprise definitions) — EUR-Lex (same URL as [1b])
[2] NIS2 Directive, Article 3 (essential and important entities) — nis-2-directive.com
[3] NIS2 Directive, Article 21 (cybersecurity risk-management measures) — nis-2-directive.com
[4] NIS2 Directive, Article 26 (jurisdiction and territoriality) — nis-2-directive.com
[5] NIS2 Directive, Article 20 (governance) — nis-2-directive.com
[5b] NIS2 Directive, Article 34 (administrative fines) — nis-2-directive.com
[6] BSI (Germany) — NIS-2-regulierte Unternehmen — bsi.bund.de
[7] European Commission — NIS2 transposition status — digital-strategy.ec.europa.eu
[8] ENISA — NIS Investments 2025 — enisa.europa.eu

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.