Which companies in industry and logistics fall under NIS2?
The Cyberbeveiligingswet distinguishes two categories: essential entities and important entities. In the sectors of industry, transport, and logistics, this broadly covers organisations with more than 50 employees or an annual turnover above 10 million euros that provide services designated as critical. This includes larger transport companies, port-related service providers, manufacturing companies in chemicals, metals, or food, and logistics service providers that form part of supply chains for other sectors. Whether your organisation falls within scope is determined through self-registration with the NCSC, which was mandatory from 15 August 2026. If in doubt, verify against the sector classification defined in the legislation. Failing to register when you are in scope is already a violation.
What must you be able to demonstrate?
The law requires three things that you must be able to demonstrate, not merely describe. First, the duty of care: appropriate technical and organisational measures for risk management. This means access controls on systems, encryption of sensitive data, patch management, and a documented risk analysis of your critical processes. Second, the incident reporting obligation: a significant incident must be reported to the supervisory authority within 24 hours, with a full report due within 72 hours. This presupposes that you know what is happening in your systems, and when. Third, supply chain accountability: you share responsibility for the digital security of your suppliers and software vendors. If your ERP or TMS is hosted by an external party, you must be able to demonstrate that this party also meets the required standards. Fines for non-compliance can reach 10 million euros or 2% of global annual turnover.
Where does the operation run into trouble?
In practice, manufacturing and logistics companies tend to stumble on three points. First: systems lack transparency. Who has access to which data? Which external parties connect to your systems? In an environment of legacy software, ad hoc integrations, and spreadsheets, these questions are nearly impossible to answer. Second: incident response exists on paper but not in practice. A 24-hour reporting requirement assumes that you can recognise and classify an incident as it happens, not three days later. That is not achievable without monitoring on your operational systems. Third: supply chain accountability is unfamiliar territory. Companies often do not know precisely which software they run, who manages it, or whether that party is also NIS2-compliant. This is the moment when questions about software ownership suddenly take on legal significance.
How does well-built software contribute to NIS2 compliance?
Structured data and system transparency are not IT luxuries; they are compliance requirements. A system that records exactly who performed which action and when, maintains an audit log per transaction, and manages access rights at role level makes meeting the duty of care practical rather than theoretical. The same applies to incident response: if your system has integrated logging and flags anomalies, you can submit a substantiated report within 24 hours. Custom software has a specific advantage here. You know what is in it, you manage the code yourself, and there is no external SaaS vendor setting the rules on data storage or access. With off-the-shelf packages, you must demonstrate that the vendor is compliant, request documentation that vendors do not always provide promptly, and hope that the update cycle aligns with security standards. With software you own, you decide that yourself.
NIS2 is not an IT project: the operations director is responsible
The Cyberbeveiligingswet explicitly places board-level accountability with the leadership of the organisation, not with the IT administrator. This means the operations director or COO must be able to explain which critical processes exist, which systems support those processes, and what measures are in place if those systems fail or are attacked. Start with the operation: which processes are critical, which systems run within them, and what is the impact if they go down? From that picture, you work back to the technical and organisational measures required. Software selection and software development thereby become part of risk policy, not as a side matter, but as a core element.