NIS2 for UK groups with EU operations: why a federated model works best
NIS2 is easy for UK groups to frame badly.
The usual mistake is to treat it as a broad EU cyber law and ask whether the UK business is caught by it. That is too blunt. For a UK-headquartered group, the better question is narrower and more useful: which entities in the group, in which EU Member States, carrying out which activities, fall within scope under local law. That is the real starting point.
That framing matters because NIS2 changes the baseline. Scope is wider, governance expectations are higher, and accountability is more explicit. For UK groups with EU operations, the issue is rarely whether “the UK” is regulated in the abstract. It is whether specific parts of the group are, and whether the organisation knows exactly which parts those are.
That is why the right response is usually not a generic central compliance programme. It is a federated operating model.
Start with scope, not controls
Most weak NIS2 responses start in the wrong place.
They start with controls, policy drafting, and programme management before the scoping work has been done properly. That is how organisations create a lot of compliance activity, very little legal precision, and unnecessary cost.
The first task is to identify the relevant legal entities, the relevant Member States, and the relevant activities. Then the group needs to understand what those entities actually depend on: shared technology, central suppliers, incident response, monitoring, legal support, reporting lines, and management decision-making.
For most UK groups, a measured scoping exercise is enough to bring order quickly. Which EU entities may be in scope? What services do they provide? Which parts of the group operating model do they rely on? Where does accountability sit today? Without those answers, “NIS2 compliance” becomes a label attached to a generic cyber uplift.
The right model is federated, not fragmented
This is where many groups go off course.
There is nothing wrong with centralisation. In many organisations it is the only sensible way to manage shared technology, common standards, reporting, evidence, and oversight. The centre can and should help interpret obligations, set baseline expectations, track implementation, and challenge weak execution.
The problem starts when centralisation turns into a generic compliance machine.
That usually looks familiar: broad control mandates applied across the group, extra governance layers added because they look prudent, reporting structures built to show motion, and central teams assuming that standardisation equals compliance. It rarely does. More often, it leaves the legal obligation only partly answered while driving cost up across the wider group.
The point is not to choose between centralisation and localisation. It is to centralise consistency and oversight, while keeping scope, accountability, and evidencing anchored to the entity that carries the obligation.
In a federated model, the centre provides grip: standards, visibility, evidence aggregation, challenge, and follow-through. The in-scope entity retains accountability: understanding its own obligation, applying the relevant controls, maintaining the evidence trail, and being able to show how that obligation is being discharged in practice.
Centralise the things that benefit from consistency. Do not centralise away entity-level accountability.
Blanket compliance is expensive
This cost point is often missed.
A generic central programme feels safe because it looks comprehensive. It produces activity, control libraries, governance forums, dashboards, and a visible compliance narrative. But it often creates the wrong kind of comfort. The centre can see that a programme is running, while the in-scope entity may still be unable to show clearly what its obligations are, who owns them, and how they are being discharged.
The cost effect is straightforward. The group ends up running more controls, more governance, and more process than the relevant entities actually require. Teams spend time implementing measures that are not necessary for the local obligation. Central teams spend time tracking activity that does not materially improve compliance. Management sees motion, but the legal precision remains weak.
That is the worst combination: higher run-cost and lower confidence.
A federated model avoids that by aiming for the minimum viable set of controls needed to comply credibly at entity level, while still using the centre to maintain consistency, oversight, and reporting. Standardisation is useful where it improves accuracy, consistency, and cost control. It becomes a problem when it expands beyond the actual obligation.
Accuracy first. Then standardise what is worth standardising.
This is a governance issue as much as a cyber issue
NIS2 is often described as a cyber regulation. That is true, but incomplete.
It is also a governance test. The issue is not simply whether controls exist. It is whether oversight is real, whether accountability is clear, and whether decisions can be evidenced at the right level.
Many UK groups run technology, procurement, identity, monitoring, and incident response centrally. That may be entirely sensible. It becomes a problem only when the EU entity that may have to answer a regulator cannot show how risk is governed, how incidents are escalated, and how oversight is exercised over services it does not directly control.
Group policy is useful. Shared controls are useful. Central reporting is useful. But none of that removes the need for the in-scope entity and its management body to show that the obligation is understood, owned, and governed properly.
Incident reporting is where weak design gets exposed
Nothing reveals this faster than incident reporting.
When a reportable incident occurs, the organisation does not get the luxury of theoretical governance. It needs clear ownership, clear escalation, and a usable evidence trail. That is manageable in a federated model where the entity knows its obligations, the centre knows its supporting role, and the reporting path is already designed.
It is much harder where everything depends on central coordination that was never properly mapped back to the legal obligation.
The useful question is not whether the group has an incident response policy somewhere. It is whether the in-scope entity can actually operate inside the reporting timetable. Can it classify an event quickly enough? Can it trigger escalation without internal debate? Can it bring cyber, legal, operations, and leadership into one decision cycle? Can it show what was known, when, and by whom?
What boards should ask now
Boards do not need to become NIS2 technicians. They do need to ask better opening questions.
Which EU entities are potentially in scope? In which Member States? Which activities bring them there? Who has validated that analysis? Which obligations must stay anchored to the in-scope entity? What sits sensibly at the centre? Can the relevant entity evidence oversight, accountability, and execution without reconstructing it after the event?
For UK groups with EU operations, NIS2 compliance should not become a generic central programme. The centre should provide grip, visibility, and consistency. But the compliance model should be federated: built around the actual entities in scope, their local obligations, and the minimum viable measures needed to comply effectively.
Done well, that is more accurate, more cost-efficient, and more defensible than building a broad compliance machine that creates activity without precision.
This is the final post in the Strathberg Insights launch series. Across these five articles, we have covered building GRC from scratch, recognising and addressing operational drift, navigating converging regulatory frameworks, assessing genuine cybersecurity maturity, and designing proportionate NIS2 compliance for multi-jurisdictional groups. If any of these themes resonate with challenges in your organisation or portfolio, we welcome a conversation: strathberg.com