NIS2 Subsidiary Compliance: Group Policy Isn’t Enough — Here’s What Article 26 Actually Requires

A group with subsidiaries in four member states doesn’t have one NIS2 compliance problem. It has four — one per national regulator, each with its own registration form, its own audit expectations, and its own view of whether the parent company’s policy binder actually applies to the entity in front of them.

This is the part most compliance programs get wrong first: they build a single group-wide information security policy, hand it down to every subsidiary, and assume that satisfies the Directive. It doesn’t. NIS2 is written entity by entity, not group by group — and the gap between those two framings is where most multi-entity compliance failures start.

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.

Does NIS2 Subsidiary Compliance Apply to Your Group?

In plain terms: if any legal entity in your group meets the NIS2 size and sector criteria in its own right — or the group’s combined figures push it over the threshold — that entity is in scope, regardless of whether its parent or siblings are also in scope.

Start with the scope test for each entity separately:

Question	What it determines
Is the entity established in the EU, or does it offer services into the EU?	Whether NIS2 applies at all, and to which Member State’s transposition
Does the entity operate in one of the 18 sectors listed in Annex I or II?	Sector eligibility (energy, transport, banking, health, digital infrastructure, manufacturing, and others)
Does the entity, on a standalone basis, employ 50+ staff or exceed €10M turnover/balance sheet?	Medium-entity threshold (Important entity, most sectors)
Is the entity linked or a partner enterprise to other group companies (25%+ ownership or voting rights)?	Whether group-level aggregation of headcount and financials applies
Does a sector-specific override apply (e.g. sole telecom/energy provider in a Member State)?	In-scope regardless of size

The fourth row is the one groups miss. Where entities are linked or partner enterprises under the Annex to Commission Recommendation 2003/361/EC, aggregation generally applies — a subsidiary with 30 employees that looks too small on its own can be pulled into scope once its headcount and turnover are combined with the parent’s [6]. Practitioner guidance treats a subsidiary’s degree of operational independence — particularly whether it runs its own network and information systems — as a relevant factor Member States may weigh here, but the starting assumption for any group entity is that aggregation applies unless proven otherwise.

Run this test on every legal entity in the group individually. A large parent and three small subsidiaries doesn’t produce one answer — it can produce four different ones, with some entities essential, some important, and some out of scope entirely. Registration itself follows the same per-entity logic: each in-scope entity submits its own name, sector, contact details, and Member States of operation to its own national authority. There is no group-level registration form.

Why Article 26 Puts Every Subsidiary Under Its Own National Regulator

In plain terms: the regulator that supervises your subsidiary is determined by where that subsidiary is established — not by where your group’s headquarters or security function sits.

Article 26(1) states that entities within scope fall under the jurisdiction of the Member State where they are established [1][2]. For most subsidiaries, that’s straightforward: a German subsidiary answers to Germany’s competent authority, a Polish subsidiary to Poland’s, regardless of what the parent company’s home regulator expects. The Directive carves out a narrower main-establishment rule for a specific list of digital-infrastructure and platform providers — DNS operators, cloud and data-centre providers, CDNs, managed service and managed security service providers, and online marketplaces, search engines, or social-networking platforms — where only one Member State has jurisdiction, determined by where cybersecurity risk-management decisions are predominantly taken [1][2].

Two details matter for group structures specifically. First, the Directive is explicit that legal form doesn’t decide jurisdiction — a subsidiary with its own legal personality is treated the same as a branch, because the test is effective activity through stable local arrangements, not a corporate org chart [2]. Second, for the main-establishment carve-out, if cybersecurity decisions can’t be pinned to one Member State, jurisdiction falls to wherever cyber operations are actually carried out, and failing that, to wherever the entity has the most EU employees [1][2]. A group that centralises security decision-making at headquarters in one country doesn’t get to claim that country’s jurisdiction for every subsidiary — that provision applies only to the narrow list of digital-infrastructure entity types, not to a manufacturing or energy subsidiary that happens to report into a central security team.

Ireland’s National Cyber Security Centre confirms the practical consequence directly in its published guidance: there is no group-level registration mechanism, and each entity submits its own registration to its own national authority [5]. A group with five subsidiaries in scope across three Member States is dealing with three separate competent authorities, three sets of enforcement expectations, and — per Article 20, covered below — three separately liable management bodies. (For the full three-tier main-establishment test and the non-EU representative rules, see our dedicated Article 26 jurisdiction guide.)

Group-Level Policy vs Entity-Specific Documentation: What Actually Satisfies an Auditor

In plain terms: a centrally drafted policy is a starting point, not evidence. What an auditor at the subsidiary level actually wants to see is proof that entity adopted, adapted, and approved that policy for its own operations.

Article 21(2)(a) requires “policies on risk analysis and information system security” [4] — it doesn’t say who has to write them, but Article 20(1) is specific about who has to approve them: the management body of the entity itself [3]. That’s the mechanical reason a shared PDF from group headquarters doesn’t survive scrutiny on its own. The policy needs a local approval date, a local management-body signature, and — where the group template doesn’t match local operations exactly — documented local amendments.

Reviewing gap analyses across groups with subsidiaries in three or more Member States, the same failure mode shows up repeatedly: the group security team treats “we have a policy” as the finish line, when the actual finish line is “every in-scope entity has evidence it adopted, reviewed, and locally approved that policy.” Those are different deliverables. The first is a document. The second is a paper trail.

A workable propagation model has three steps: draft once at group level to avoid 74 slightly different risk-analysis frameworks; tailor per entity to reflect that subsidiary’s actual sector, size, and risk exposure (a manufacturing subsidiary’s business continuity plan should not be a copy-paste of a services subsidiary’s); and document local adoption with a dated board or management-body sign-off, not just an email confirming receipt. Skip the third step and the group has a well-written policy with no entity-level evidence behind it — which is precisely what an inspector checking Article 20 compliance is trained to look for.

The Shared Service Centre Problem: When Your Own IT Team Becomes a Regulated Entity

In plain terms: if your group runs a centralised IT or security function that serves multiple subsidiaries, that shared service centre can itself trigger supply-chain security obligations for the entities it serves — and in some structures, qualify as a regulated entity in its own right.

Article 21(2)(d) requires entities to address supply chain security, “taking into account the vulnerabilities specific to each direct supplier” [4]. A shared service centre supplying IT infrastructure, identity management, or security monitoring to sibling entities is functionally a direct supplier to each of them — the fact that it sits inside the same corporate group doesn’t remove the dependency. Each subsidiary that relies on the shared service centre needs the same documented supplier-risk assessment it would apply to an external vendor: what the shared centre provides, what happens if it fails, and what contractual or intra-group service-level commitments back that up.

The classification question runs the other way too. If the shared service centre operates as a separate legal entity — common where groups centralise IT into a dedicated subsidiary for tax or operational reasons — its own headcount and turnover feed into the same linked/partner-enterprise aggregation described earlier. A shared service centre with 40 employees can still be pulled into scope on a standalone basis if its activities fall within an NIS2 sector, or via aggregation with the wider group’s figures. Groups that treat the shared service centre purely as internal overhead, with no entity-level NIS2 assessment of its own, are the ones most likely to discover — usually during a subsidiary’s own gap analysis — that the centre was never scoped at all.

The practical fix is to treat the shared service centre exactly like an external managed service provider for compliance purposes: give it its own Article 21(2)(d) supplier profile inside each subsidiary’s supply chain register, and run its own standalone scope test rather than assuming group membership exempts it.

Article 20 Personal Liability Doesn’t Stop at the Parent Board

In plain terms: the management body that can be held personally liable under NIS2 is the management body of the in-scope entity — meaning a subsidiary’s own board or directors, not the parent company’s board, carries that exposure for that subsidiary.

Article 20(1) states that management bodies of essential and important entities must approve the cybersecurity risk-management measures taken under Article 21, oversee their implementation, “and can be held liable for infringements by the entities of that Article” [3]. Read against Article 26’s jurisdiction rule, the consequence for a group structure is direct: liability tracks the entity, and the entity is supervised locally. A subsidiary’s own management body — whatever local board, supervisory board, or equivalent governance structure that entity has — is the one exposed if that subsidiary’s Article 21 measures aren’t approved, overseen, and evidenced at the local level.

Article 20(2) adds a training obligation: management body members must be trained to identify risk and assess the cybersecurity measures affecting their entity’s services [3]. A subsidiary board that has never seen its own entity’s risk register — because the group’s central security team handled it without a local sign-off — has not met that obligation, regardless of how mature the group’s overall program is.

Exposure	Who bears it under NIS2	What documentation reduces it
Corporate fine (essential entities)	The in-scope entity — up to €10M or 2% of turnover, whichever is higher [7]	Entity-level Article 21 measure register with dated evidence
Corporate fine (important entities)	The in-scope entity — up to €7M or 1.4% of turnover, whichever is higher [7]	Same as above, calibrated to the entity’s risk profile
Personal liability / management ban	Members of that entity’s own management body, per national implementing law	Board minutes showing approval of measures, oversight activity, and training records specific to that entity

The turnover figure behind that percentage is not the subsidiary’s standalone revenue — Article 34 calculates it against the total worldwide annual turnover of the undertaking to which the entity belongs [7]. In practice, a small subsidiary’s own fine ceiling can be sized off the whole group’s turnover, even though the liability, approval, and oversight obligations that triggered the fine stayed entirely local to that one entity’s management body. Group scale increases the exposure; it doesn’t share the accountability.

The practical implication is that a group cannot centralise Article 20 accountability the way it can centralise document drafting. Central teams can prepare the risk register, the measures, and the training material — but the approval, oversight, and training itself has to happen at the subsidiary’s own governance level, with its own record. (For the exact enforcement mechanics and how national implementing laws vary on personal sanctions, see our Article 20 board liability guide and the penalties reference.)

Three Models for Structuring Group-Wide NIS2 Compliance

Everything above points to the same design question: how much of the compliance program should be built once at group level, versus rebuilt separately at every subsidiary? In practice, groups tend to land on one of three models.

Model	How it works	Where it breaks down
Centralised	Group security team drafts, approves, and maintains one policy set applied uniformly across all entities	Fails Article 20 — a parent-level approval doesn’t satisfy a subsidiary’s own management-body obligation, and one-size policies rarely fit a sector-diverse group
Decentralised	Each subsidiary builds and maintains its own program independently, with no shared framework	Duplicates effort across every entity, produces inconsistent risk-assessment quality, and gives group leadership no visibility into aggregate exposure
Hybrid	Group team drafts a master control set; each subsidiary’s own management body adapts, approves, and evidences its local version	Requires more coordination than either extreme, but is the only model that satisfies both Article 21 consistency and Article 20’s entity-level accountability

The hybrid model changes what each role is responsible for. The group CISO or security lead owns the master template and cross-entity consistency, but not the local sign-off. The subsidiary’s compliance officer owns tailoring the template to that entity’s actual risk profile and keeping its evidence trail current. The subsidiary’s own board or management body owns approval, oversight, and training — the parts of Article 20 that cannot be delegated upward or centralised away. (A documented role-responsibility split like this is also the basis of a defensible board governance framework if regulators from different Member States ask how accountability is assigned across the group.)

Compliance Checklist for Multi-Entity Groups

Step	Effort	Notes
Run the scope test on every legal entity individually, including shared service centres	Medium	Don’t assume a group-wide answer; some entities may be essential, some important, some out of scope
Register each in-scope entity with its own national competent authority	Low	No group-level registration exists; each filing is separate
Draft a master Article 21 control set at group level	Medium	Covers the ten measure categories in Article 21(2); built to be tailored, not copy-pasted
Tailor and locally approve the control set at each subsidiary	High	Requires that entity’s own management body to sign off — this step cannot be centralised
Map the shared service centre as a supplier in every served entity’s supply chain register	Medium	Applies even where the centre sits inside the same corporate group
Deliver Article 20(2) training to each subsidiary’s management body	Medium	Group-level training material is fine; attendance and comprehension must be entity-specific
Maintain a per-entity evidence log (approval dates, board minutes, training records)	Ongoing	This is what an auditor or regulator will ask to see first

Frequently Asked Questions

If our parent company is already NIS2-compliant, do our subsidiaries still need to comply separately?

Yes. Article 26 assigns jurisdiction to the Member State where each entity is established, and Article 20 assigns liability to that entity’s own management body [1][2][3]. A parent’s compliance program doesn’t transfer that obligation.

Do small subsidiaries automatically fall outside NIS2 scope?

Not necessarily. Where a subsidiary is a linked or partner enterprise to other group companies, its headcount and financials are generally aggregated with the group’s figures under the Recommendation 2003/361/EC framework, which can pull an otherwise small entity into scope [6].

Can one shared service centre handle compliance for the whole group?

It can handle drafting and technical implementation, but not the approval and oversight obligations under Article 20, which sit with each subsidiary’s own management body. The shared service centre itself may also need its own scope assessment if it operates as a separate legal entity or crosses size thresholds.

Which national authority has jurisdiction if our subsidiaries operate in multiple Member States?

Each subsidiary generally falls under the authority of the Member State where it is established, per Article 26(1) [1][2]. A narrower main-establishment rule applies only to a specific list of digital-infrastructure and platform entity types.

What’s the fastest way to get a subsidiary board audit-ready?

Start with the two documents Article 20(1) requires the management body to approve — the Information Security Policy and Risk Assessment Methodology — plus a role matrix showing who owns implementation versus who owns accountability.

Sources

• EUR-Lex — Directive (EU) 2022/2555 (NIS2), full text: eur-lex.europa.eu
• The NIS 2 Directive — Article 26, Jurisdiction and Territoriality: nis-2-directive.com
• The NIS 2 Directive — Article 20, Governance: nis-2-directive.com
• The NIS 2 Directive — Article 21, Cybersecurity Risk-Management Measures: nis-2-directive.com
• National Cyber Security Centre Ireland — NIS2 FAQ: ncsc.gov.ie
• Glocert International — NIS2 Applicability: Essential vs Important Entities: glocertinternational.com
• The NIS 2 Directive — Article 34, Administrative Fines: nis-2-directive.com