NIS 2 for multinationals: why group structures are suddenly legally relevant

NIS 2 affects more than just traditional vital providers

NIS 2 is intended to increase the digital resilience of organizations. This happens with stricter security obligations, stricter incident reporting requirements, more attention to suppliers and serious consequences in the event of non-compliance. The scope of the rules has also broadened. More sectors, more entities and more activities may fall under the scheme.

For many organizations, the first reflex is still: do we fall under NIS 2 or not? In practice, this question is seldom so simple. Especially among internationally operating groups, the answer is not readily available at the corporate level. Those who have multiple companies, different activities and a central IT environment will quickly notice that the legal map looks different from the organization chart.

At Startup-Recht, we see that this is exactly the kind of subject where legal theory and operational reality collide. On paper, the system seems clear. In practice, it actually raises questions about demarcation, responsibility and internal coordination.

The real puzzle starts with the concept of entity

An important starting point is that NIS 2 does not start from the group as a whole, but from the entity. That sounds technical, but it has major consequences. Not the company in a broad sense, but the individual entities, are the starting point for assessing whether the rules apply.

This immediately leads to tension. Because while considering the applicability per entity, the size criteria are again linked to an approach that also includes data from related or partner companies. As a result, a relatively small company within a larger group can still come into the picture, precisely because it is part of a larger whole.

For startups and scale-ups, this is extra relevant as soon as the company grows through subsidiaries, foreign branches or functionally separate business units. A local entity can be operationally small and fairly independent, but still be legally drawn into a broader assessment. This makes a purely legal scope analysis difficult, especially when the IT systems within the group are not fully centrally organized.

Why the magnitude test doesn't always make sense

The tension becomes even clearer when a smaller entity within a group actually operates autonomously. Think of a foreign subsidiary with its own team, its own systems and limited dependence on the rest of the group. From a cyber risk point of view, an incident there does not automatically have to have consequences for the entire group.

However, group size can play a major role in the assessment. That doesn't always feel logical in such cases. After all, the idea behind NIS 2 is that organizations that play a relevant role in critical processes are subject to more stringent requirements. In practice, if an entity operates quite separately, it matters when the size of the group still determines.

For young tech companies that are scaling up internationally, this is not a theoretical discussion. Scale-ups, in particular, often build a structure at a rapid pace with separate companies for funding, IP, staff, sales or regional expansion. Then the question quickly arises whether this legal design will later unexpectedly affect the NIS 2 assessment.

Internal IT services can also bring the group within reach

One of the most striking points is that not only the core activity of a group is relevant. Support activities can also ensure that an entity falls within scope. This applies in particular to internal IT services.

Many groups work with a shared services center or an internal IT company that provides security services, cloud-related services, or other managed ICT services to group companies. For NIS 2, it is not decisive that such services are offered commercially to third parties. It may already be sufficient that they are granted within the EU.

This means that a group whose main activity does not itself fall into a NIS 2 sector can still have to deal with NIS 2 via an internal service provider. Think of an organization that is primarily active in hospitality, retail or another sector outside the classic critical domains, but has organized highly centralized digital services internally. Then legal attention suddenly shifts to the shared services center.

For tech companies, this is extra relevant. Within rapidly growing groups, security, cloud management, development support and central infrastructure are often consciously brought together in one entity. This is efficient, but it can also mean that it is precisely this internal structure that forms an entry point for NIS 2 obligations.

One entity can wear multiple hats at the same time

The situation becomes even more complex when an entity combines multiple activities. For example, a company can operate within different sectors or sub-segments. In such a case, it is possible that the same entity falls under the regime from multiple angles.

This has practical consequences. Not only should it be determined that the entity falls under NIS 2, but also what sectoral liabilities are accumulating. This is an important point for governance, documentation and internal controls. An organization that thinks it has finished with one qualification may actually face a more layered package of requirements.

For founders and management teams, this is primarily a warning against too rough analyses. A quick conclusion at group level, or a simple label question per business line, is usually not enough. If you want to get serious about NIS 2 compliance, you need to take a deeper look at the concrete role of each entity and the actual services provided within the group.

Does NIS 2 apply to the entire group immediately?

That question is obvious, but the answer is nuanced. If one group company falls under NIS 2, this does not automatically mean that all other group companies also fall directly under the same regime.

However, there can be a broad effect within one and the same entity. If an entity falls under the rules, other parts within the same entity may also be affected by those obligations. But a further automatic transfer to all companies within the group does not necessarily follow.

In practice, the image is less clear. Group companies are often closely intertwined. They share monitoring, security tooling, policies, identity management, or a central Security Operations Center. As a result, other entities may still have to deal with NIS 2 obligations operationally, even if they do not appear to fall into scope independently.

This is familiar to scale-ups. Many organizations are growing faster than their governance grows with it. Legally, there are several entities, but technically and organizationally everything still runs on one central stack. Then the distinction between direct applicability and actual impact suddenly becomes very relevant.

Jurisdiction: In which country do the rules apply?

Once a group is active in multiple EU countries, the following question comes to the table: which national regime applies? And just as important: can there be more than one?

The main rule is strict. If an entity is located in the Netherlands and provides services or activities in the Netherlands or another EU member state, it falls under the Dutch regime. But other entities within the same group may be subject to the implementation laws of other member states at the same time. So there is not automatically one counter for the entire group.

That immediately makes international compliance a lot tougher. A parent company with subsidiaries in different countries cannot simply suffice with one central approach that is legally the same everywhere. Differences between national implementations can create additional organisational and financial pressure.

For startups and scale-ups with European expansion plans, this is an important point of attention. Today, if you mainly look at commercial growth opportunities per country, it is wise to also assess early what legal and compliance consequences that country structure will have later. This is because NIS 2 can also turn an international rollout into a multidisciplinary governance exercise.

A different regime applies to some digital services

For certain entities with a cross-border digital nature, a separate jurisdiction regime applies. This involves looking at the head office. This includes activities in the fields of digital infrastructure, management of ICT services and digital providers, including providers of cloud computing services and managed security services.

The location of that head office will be determined gradually. First, we look at where cybersecurity risk management decisions are primarily made. If that doesn't provide a clear answer, attention will shift to where the cybersecurity activities are conducted and then where the entity has the largest number of employees in the EU.

For groups with central security governance, this is particularly relevant. On paper, an internal IT entity may be located in the Netherlands, while the strategic decisions are actually made elsewhere in the group. Then the question may arise whether the location of the controlling company is not the determining factor. The result may be that a Dutch operating entity will eventually end up under a different national regime than initially expected.

For tech companies that work with central platform teams, foreign holding structures or pan-European security management, this is no detail. It directly addresses the question of who internally owns compliance, which country is leading and how reporting processes should be set up.

Incident reporting is quickly becoming a cross-border problem

Perhaps the most practical bottleneck lies in the reporting obligation. Because what happens if one incident affects multiple entities within the same group?

Think of an internal shared services center that provides security services to various group companies. If an incident occurs there, there is a good chance that other entities will also suffer consequences. The starting point is then that affected entities should separately assess whether they should report. This may result in the need for reports in multiple countries.

A central notification for the entire group may be operationally obvious, but legally this is not necessarily the same as a one-stop shop. For groups with multiple locations in different EU member states, this makes a big difference. Incident response must then not only be technically well organized, but also legally and organizationally.

At Startup-Recht, we see that many young technology companies organize their incident processes very centrally. This is logical and often wise. But once a company has multiple entities and jurisdictions, that central approach must be translated into a structure that clearly states who reports where, based on what qualification and under what national framework.

What does this mean in concrete terms for startups and scale-ups?

The most important lesson is that for growth companies, NIS 2 is not just about security controls. The regulation also forces a closer look at corporate structure, internal services and European expansion.

For startups that are still in an early phase, this may be a reason to think more carefully about setting up shared services, IP companies and central IT functions. For scale-ups with multiple countries, subsidiaries and a centralized platform, it is primarily a signal that scope, jurisdiction and reporting obligations cannot be assessed separately.

A useful first step is to identify all entities, their activities and how network and information systems are organized within the group. This is followed by the question of which entities may fall under NIS 2, which of them may have multiple qualifications, and where the relevant cybersecurity decisions are actually made.

In addition, it is wise not to let legal, compliance, security and IT look at this issue side by side, but together. Especially in international groups, that prevents the legal analysis from saying something different from the technical reality. That's where else the most surprises occur.

Conclusion: NIS 2 requires a map of your group, not just your systems

NIS 2 makes it clear that cyber compliance does not stop with firewalls, policies and monitoring. For organizations operating internationally, it's just as much about how the group is legally structured, where services are provided and how responsibilities are distributed within the organization.

For startups and scale-ups in the tech sector, this is a relevant wake-up call. Those who grow rapidly often build complexity automatically. And it is precisely this complexity that can determine under NIS 2 which entity falls in scope, which national regime applies and where an incident must be reported.

The practical message is clear: do not wait for an incident or a supervisor to conduct the structure test. Start inventorying entities, activities, central IT functions and internal dependencies on time. Because under NIS 2, your group structure is no longer just a corporate issue, but also a cybersecurity issue.

‍