NIS2 and Your Legacy Systems: Compliance Obligations Your Old Software Was Never Designed For

If your company runs in Belgium and the Netherlands, you are currently living under two different versions of the same law. That is not a paradox, it is the practical reality of NIS2 in 2026, and it has direct consequences for the software you already run.

Most NIS2 coverage explains the directive. Far less of it explains what the obligations mean for systems that were built years before anyone had heard of NIS2: the ERP that has no meaningful logging, the integration nobody documented, the server whose patch cycle is “when something breaks”. That gap is where compliance quietly turns into an engineering problem.

Where things actually stand

Belgium moved early and is already enforcing. The Belgian NIS2 law and its Royal Decree entered into force on 18 October 2024, making Belgium one of only four Member States to meet the original deadline. The Centre for Cybersecurity Belgium (CCB) acts as both national cybersecurity authority and CSIRT. In-scope entities had to register through the Safeonweb@Work portal by 18 March 2025, and by late 2025 roughly 1,500 essential and 2,500 important entities had done so. On 18 April 2026 Belgium passed its first conformity assessment deadline: essential entities had to submit verified documentation showing that cybersecurity controls are actually in place, assessed by an accredited body or by the CCB. Self-declarations were not accepted.

The Netherlands is still catching up. The Dutch transposition, the Cyberbeveiligingswet (Cbw), replaces the older Wbni. It passed the House of Representatives on 15 April 2026, with entry into force expected during 2026. In the meantime the European Commission referred the Netherlands to the Court of Justice on 8 July 2026 for failing to notify full transposition. NCSC-NL is already publishing guidance and operational expectations.

For a company operating in both countries, the message is uncomfortable but clear: in Belgium you are late if you have not acted, and in the Netherlands the transposition gap is preparation time, not a reprieve. Surveys through 2026 have repeatedly found that a large majority of in-scope organisations describe themselves as not ready.

What NIS2 actually asks for

Strip away the legal language and NIS2 comes down to two things: a set of duty-of-care measures you must have in place, and a reporting obligation when something goes wrong.

The duty-of-care measures cover risk analysis, incident handling, business continuity, supply chain security, security in acquisition and development, access control, multi-factor authentication, cryptography, vulnerability handling and staff awareness.

The reporting timetable is where NIS2 becomes concrete. For a significant incident, the sequence is an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month.

Read that timetable again with your oldest system in mind. Twenty-four hours is not a lot of time to notice, confirm and characterise an incident. It is essentially no time at all if the system in question cannot tell you what happened inside it.

Why legacy systems struggle with this

Here is the part that lands on engineering teams rather than on legal.

You cannot report what you cannot detect

The 24-hour clock assumes you will notice. Many older systems log almost nothing useful: no structured audit trail, no centralised collection, no alerting on anomalies. When something suspicious happens, the honest answer is often that nobody would know for weeks.

Retrofitting logging and monitoring into a running production system is unglamorous, careful work. It is also the single most valuable thing most companies can do for NIS2 readiness, because it turns an unanswerable question into an answerable one.

Duty of care assumes an inventory you may not have

Risk analysis, vulnerability handling and access control all presuppose that you know what you are running. In practice, many mid-size companies cannot produce a complete list of their systems, dependencies, integrations and who has access to what. Shadow integrations built years ago for a specific need are a recurring example.

The first NIS2 task for most companies is therefore not writing a policy. It is mapping reality.

Vulnerability handling requires a patch path that works

A duty to handle vulnerabilities implies you can actually apply fixes. Systems running end-of-life frameworks, unsupported runtimes or dependencies frozen years ago often cannot be patched without a modernisation step first. That is a maintenance programme, not a policy decision, and it needs lead time.

Supply chain security cascades to your suppliers, and to you

This is the clause that quietly widens NIS2 far beyond the entities formally in scope. In-scope organisations must manage security in their supplier relationships. So if your customer is an essential or important entity, their obligations arrive at your door as contractual requirements, questionnaires and evidence requests, whether or not NIS2 applies to you directly.

Many companies discover they are affected not through a regulator, but through a customer’s procurement form.

Documentation is now evidence

Belgium’s April 2026 deadline made this explicit: verified documentation, assessed externally, not a self-declaration. Documentation stops being internal hygiene and becomes the artefact that demonstrates compliance. Systems whose knowledge lives in one person’s head cannot produce that.

What this means practically

NIS2 readiness for a company with older systems tends to follow a predictable sequence:

  • Map what you run. Systems, versions, dependencies, integrations, data flows, access. This is the foundation for everything else.
  • Fix detection first. Logging, centralised collection and alerting, so the 24-hour clock is survivable.
  • Establish a patch path. Identify what cannot currently be patched and plan the modernisation those systems need.
  • Tighten access. Access control and multi-factor authentication, including on the old internal tools everyone forgets.
  • Write it down. Architecture, runbooks, incident procedures, in a form an external assessor can read.
  • Rehearse the reporting path. Know who notifies the CCB or NCSC-NL, with what information, within which deadline.

None of these steps is exotic. All of them are maintenance work on systems that cannot go down while the work happens.

How Dink can help

This is the work we already do, applied to a compliance deadline.

Our fixed-scope technology assessment produces exactly the map NIS2 assumes you have: what runs where, on what versions, integrated with what, with which single points of failure and which gaps in monitoring and recovery readiness.

Adding logging, closing vulnerabilities and modernising components that can no longer be patched are changes to live systems. Staged rollouts, reversible changes and testing are how we work on critical systems already, because the alternative, taking the system down, is not available.

And documenting what only lives in people’s heads is standard practice when we take over a system. Under NIS2 that documentation is no longer just useful internally, it is evidence.

If you are not sure whether NIS2 applies to you, or you know it does and you are looking at systems that were never designed for it, that is a good first conversation to have.

Frequently asked questions

Does NIS2 apply to mid-size companies?
Often yes. NIS2 generally covers medium and large organisations, from 50 employees or 10 million euro turnover, across 18 sectors. Certain entity types are in scope regardless of size, and Member States can designate additional entities. Even outside direct scope, the supply chain security obligations of your customers can reach you contractually.

What is the difference between Belgium and the Netherlands right now?
Belgium transposed NIS2 with effect from 18 October 2024, required registration with the CCB by 18 March 2025, and set its first conformity assessment deadline for essential entities on 18 April 2026, requiring externally verified documentation. The Netherlands is transposing through the Cyberbeveiligingswet, which passed the House of Representatives on 15 April 2026 with entry into force expected during 2026. Companies operating in both countries face different timelines for the same directive.

How quickly do we have to report an incident under NIS2?
For a significant incident: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month. Meeting the first deadline depends on detection, which is where older systems usually fall short.

Our systems are old. Where do we start?
Start by mapping what you actually run, then fix detection through logging and monitoring. Those two steps unlock everything else: you cannot do risk analysis, vulnerability handling or incident reporting without knowing what exists and being able to see what it is doing.

Are we affected if our customers are in scope but we are not?
Frequently, yes. In-scope entities must manage supply chain security, so their obligations pass to suppliers through contracts, security questionnaires and evidence requirements. Many companies first encounter NIS2 through a customer’s procurement process rather than through a regulator.

This is practical guidance from an engineering perspective, not legal advice. For scoping and classification decisions, involve your legal counsel or your national authority.

Wondering whether your systems could meet a 24-hour reporting deadline? Start with a fixed-scope technology assessment, or get in touch.

Digital Sovereignty: Why Your Technology Partner Matters as Much as Your Cloud

For years, “digital sovereignty” sounded like a Brussels word: something discussed in policy papers, not in board meetings. That has changed. Over the past two years it has moved from an abstract ambition to a practical question that mid-size companies are being asked by their auditors, their insurers, their public-sector clients and their own boards.

And the question is sharper than it used to be. It is no longer only where does our data sit? It is who actually controls the systems our business runs on, and what happens if that relationship changes?

Most of the conversation focuses on cloud providers. That matters. But there is a second dependency that gets far less attention and is often harder to unwind: the people who build and maintain your software.

What digital sovereignty actually means

It helps to strip away the rhetoric. Digital sovereignty is not about doing everything yourself, and it is not about refusing to work with anyone outside Europe. The most useful definition circulating in European policy circles is simpler: sovereignty means having strategic options for the things that are critical to you.

That reframing matters, because it turns an ideological debate into a risk question. For each critical part of your technology, you can ask:

  • If this provider changed its terms, its pricing or its ownership tomorrow, what would we do?
  • Which legal system governs this relationship, and can we actually enforce it?
  • If we needed to move, could we? How long would it take, and who would do it?

A company with good answers is sovereign in the way that counts. A company whose answer is “we would have a serious problem” has a dependency, whatever the marketing says.

Why this stopped being theoretical

Three things pushed sovereignty from policy discussion into operational reality.

The legal conflict is real. US legal frameworks such as the CLOUD Act can compel American providers to produce data regardless of where it is physically stored, which sits awkwardly against GDPR obligations. This is not a hypothetical tension for a European company handling personal data, it is a documented conflict of laws that no contract fully resolves.

Regulation now asks the question directly. NIS2 pushed operators of critical infrastructure toward demonstrable control over their data and systems. The June 2026 European Technological Sovereignty Package went further: its centrepiece, the Cloud and AI Development Act, introduces a formal sovereignty assurance framework governing which cloud services may handle sensitive public sector workloads. The consequence cascades downstream. If you supply, integrate with, or hold contracts under public bodies, their sovereignty requirements become your requirements.

Concentration became a visible risk. A large share of European businesses depend on a small number of non-European providers for infrastructure they cannot quickly replace. Geopolitics made that concentration feel less like efficiency and more like exposure.

The dependency nobody puts on the risk register

Here is the part that gets missed.

You can host everything in an EU region, sign every data processing agreement, and still have a critical dependency that sits entirely outside your control: the knowledge of how your systems work.

If the team that understands your core platform is unreachable, unaccountable under a legal system you can use, or simply gone, you do not control that system in any meaningful sense. You are renting access to your own business logic.

This is not an argument against working with international teams. It is an argument for being deliberate about four things.

Jurisdiction and enforceability

When something goes wrong, which court hears it, and under which law? A contract with a European entity, governed by European law, is enforceable in a way that a contract with a distant entity in an unfamiliar legal system often is not, whatever the SLA promises.

Regulatory accountability

The GDPR and now the EU AI Act place obligations on you, not only on your suppliers. A partner already operating under those rules understands what documentation, data minimisation and transparency actually require, because they carry the same obligations. That is very different from a supplier who treats EU compliance as an export formality.

Proximity that is operational, not sentimental

Shared working hours, shared language, and a shared understanding of how European businesses actually operate. When a critical system fails at 09:00 CET, the value of a partner who is awake, reachable and legally accountable is not an abstraction. We wrote about this in more detail in our guide to outsourcing system maintenance in Belgium and the Netherlands.

Continuity of knowledge

Sovereignty over a system means being able to answer “how does this work?” without depending on a single person or a single vendor’s goodwill. That is why documentation is not administrative overhead, it is the mechanism that keeps control of a system with its owner. This is a core part of how we approach long-term maintenance.

Sovereignty is not autarky

It is worth saying plainly, because the debate often loses this nuance: choosing European does not mean choosing worse, and it does not mean isolation. European policy discussions themselves have settled on language like “resilient openness” rather than protectionism.

The goal is not to build a wall. It is to make sure that for the systems your business cannot afford to lose, you have a partner who is accountable under a legal system you can rely on, reachable in your working day, and operating under the same regulations you do.

At Dink, that is precisely how we are structured. We are a Belgian company, contracting under European law, bound by the GDPR and the EU AI Act as directly as our clients are. We also work with senior engineers across Europe and the Americas, which gives our clients coverage across their full working day. Those two facts are not in tension: accountability, jurisdiction and regulatory alignment sit in Europe, while delivery capacity is deliberately distributed. That is what having strategic options looks like in practice. You can read more about how we work.

How to evaluate a technology partner on sovereignty

A practical set of questions, useful whether or not you end up working with us:

  • Which legal entity am I contracting with, and under which law? Not the brand, the entity.
  • Where is my data processed, and by which sub-processors? Ask for the list, not the assurance.
  • Who holds the knowledge of my system, and is it documented? If the answer is “their team”, ask what happens when their team changes.
  • What is the exit path? If we ended this relationship, what would we receive, in what format, and how long would a handover take?
  • Do they carry the same regulatory obligations I do? GDPR, NIS2 where relevant, and increasingly the AI Act.
  • Can they reach me in my working day, in a language my team works in?

If a prospective partner is uncomfortable with these questions, that discomfort is itself the answer.

Where to start

Most companies discover their real dependencies only when they map them. That mapping is an engineering exercise before it is a strategic one: what runs where, on whose infrastructure, maintained by whom, documented to what degree. It is exactly what our fixed-scope technology assessment is designed to produce.

If you are also weighing where AI fits into this picture, the same questions about jurisdiction, data location and accountability apply with even more force. That is built into our AI adoption program, and we covered the data protection side in our article on where AI creates value in a business.

Digital sovereignty, in the end, is not a purchase. It is a property of how your technology relationships are structured. The companies that have it are not the ones with the strongest opinions about it, they are the ones who asked the boring questions early.

Frequently asked questions

What is digital sovereignty for a business? Digital sovereignty is the ability to keep meaningful control over the data, systems and technology relationships your business depends on. In practice it means having strategic options for critical services: knowing which legal system governs each relationship, where your data is processed, and whether you could change providers if you needed to. It does not require doing everything in-house or in Europe.

Why does it matter where my technology partner is based? Because location determines jurisdiction, and jurisdiction determines what you can enforce. A partner established in the EU contracts under European law, carries GDPR and EU AI Act obligations directly, and can be held accountable through a legal system you can access. It also affects practical things like working hours, language, and how quickly someone can respond when a critical system fails.

Does choosing a European technology partner mean higher costs? Not necessarily, and the comparison is usually framed wrongly. The relevant cost is total: unplanned downtime, knowledge lost when a team changes, the effort of an unplanned migration, and the compliance work you carry regardless of who your supplier is. A partner who documents systems and is accountable under your own legal framework often reduces those costs rather than adding to them.

What is the Cloud and AI Development Act (CADA)? CADA is the centrepiece of the European Technological Sovereignty Package presented in June 2026. It introduces a formal sovereignty assurance framework determining which cloud services may handle sensitive public sector workloads. Its effects extend beyond the public sector: private companies that supply, integrate with or hold contracts under public bodies inherit those requirements through the supply chain.

How do I know if my company has a sovereignty problem? Ask what would happen if a critical provider changed its terms, was acquired, or became unavailable. If the honest answer is that you could not move, could not enforce your contract, or could not explain how the system works without that provider, you have a dependency worth addressing. Mapping it is usually the first concrete step.