For two decades, the software running quietly beneath a European company was, in the eyes of the boardroom, a technical matter. If it was slow, fragile or hard to patch, that was a problem for the IT department to manage and for the budget to absorb. In 2026, that framing has quietly become dangerous. Under the NIS2 Directive, which reached full effect across the European Union this year, the state of your systems is no longer only an operational question. It is a question of personal duty of care for the people at the top.

From an IT problem to a board problem

The shift that senior operators have not fully absorbed is where NIS2 places responsibility. The Directive makes clear that management-body members can be held personally liable for culpable conduct in the governance of cybersecurity. This is not a fine the company pays and forgets. It is accountability that reaches the individuals who approved, or failed to question, the risk. The headline penalties are substantial in their own right: fines of up to EUR 10 million or 2% of annual turnover, whichever is higher. But the deeper change is that a director can no longer honestly say the software estate was someone else’s remit.

Germany has made this concrete faster than most. According to reporting summarised by Reed Smith, Freshfields and Lexology, Germany implemented NIS2 into national law with effect from December 2025 and, notably, with no transition period. Entities in scope had to register with the federal cybersecurity authority, the BSI, within a short window that closed on 6 March 2026. There was no grace year in which to modernise quietly. Compliance was expected from day one.

The enforcement posture matched the letter of the law. The BSI is reported to have issued around 47 formal notices in the fourth quarter of 2025, and to have levied an early and pointed fine of EUR 850,000 on a mid-sized cloud provider. The stated grounds are worth reading carefully: inadequate incident detection and late reporting. NIS2 requires meaningful incident reporting within 24 hours. That is a demanding clock, and it is precisely the clock that ageing systems tend to fail.

Why legacy software is now a governance exposure

Here is the uncomfortable logic. NIS2 does not punish you for being breached in the abstract; it punishes you for being unable to detect, understand and report what happened to your own systems in time. Legacy platforms are structurally bad at exactly this. When a codebase has accreted twenty years of workarounds, when observability was bolted on late, when patching means a fire-drill because every fix risks breaking an undocumented integration, the organisation cannot credibly meet a 24-hour reporting duty. Industry replatforming analyses this year describe legacy estates silently consuming 40 to 60% of every development sprint on backports and patch maintenance. A team spending that much effort simply standing still is not a team that can react to an incident with speed.

So the ethical case follows almost mechanically. If a board continues to run software it cannot audit, cannot patch quickly and cannot see into clearly, and if that opacity is what causes a reporting failure, that is no longer an unlucky technical event. Under NIS2 it starts to look like a governance failure — a failure of the duty of care the Directive now attaches personally to management. “We didn’t know the system was that fragile” is, increasingly, an admission rather than a defence.

There is a sovereignty dimension worth naming lightly here. A single incident touching personal data can trigger NIS2 and GDPR together, and the question of who can be compelled to hand over data matters. The US CLOUD Act allows US authorities to compel US-owned providers to disclose data even when the servers sit in an EU data centre. Data residency, in other words, is not the same as data sovereignty — and the ability to know and control your own stack is part of the auditability regulators now expect.

The honest caveat

It would be dishonest to present modern, self-hosted infrastructure as a way to escape this responsibility. It is not. Self-hosting relocates the duty of care rather than removing it: you own the patching cadence, the incident detection, the reporting discipline. What it changes is your capacity to discharge that duty. A stack you can read, audit and update quickly is a stack a board can defensibly stand behind. A modern architecture with an intentionally agnostic core and plug-in modules that switch on and off without a restart is easier to reason about than a monolith no one fully understands. That is not a compliance guarantee. It is a materially better starting position.

This is the argument made at more length in VBWD’s own writing on sovereign-by-default commerce for the NIS2 era, and it is worth reading if the personal-liability question is now live in your governance meetings. For full disclosure, VBWD is a younger platform than the twenty-year incumbents; it trades some accumulated edge-case maturity for architecture, speed and auditability. For many regulated European operators that is now the better trade. For some it will not be. The point of NIS2 is that this is a decision the board must actually make, on the record.

If this maps to a conversation happening inside your own organisation, the useful next step is specific rather than generic: see your own workload on modern, self-hosted infrastructure. Request an enterprise installation and bring the numbers you’re trying to improve.

Sources: Reed Smith, Freshfields, Lexology and Reglyze on NIS2 and its German implementation; European DIGITAL SME Alliance and OpenVPN on the CLOUD Act and cloud sovereignty; industry replatforming analyses on legacy maintenance burden.