Welke bedrijven in industrie en logistiek vallen onder de NIS2?
De Cyberbeveiligingswet onderscheidt twee categorieën: essentiële entiteiten en belangrijke entiteiten. In de sectoren industrie, transport en logistiek gaat het ruwweg om organisaties met meer dan 50 medewerkers of een jaaromzet boven de 10 miljoen euro die diensten verlenen die als kritiek worden aangemerkt. Denk aan grotere transportbedrijven, havengebonden dienstverleners, productiebedrijven in chemie, metaal of voedsel, en logistiek dienstverleners die deel uitmaken van ketens voor andere sectoren. Of jouw organisatie er precies onder valt, bepaal je via de zelfregistratie bij het NCSC, die per 15 augustus 2026 verplicht was. Wie twijfelt: controleer het aan de hand van de sectorindeling in de wet. Niet registreren terwijl je er wel onder valt is al een overtreding.
Wat moet je aantoonbaar geregeld hebben?
De wet vraagt drie dingen die je moet kunnen aantonen, niet alleen beschrijven. Eerst de zorgplicht: passende technische en organisatorische maatregelen voor risicobeheer. Dat betekent toegangsbeheer op systemen, encryptie van gevoelige data, patchbeheer, en een gedocumenteerde risicoanalyse van je kritieke processen. Ten tweede de meldplicht: een significant incident moet binnen 24 uur gemeld worden bij de toezichthouder, met een volledig rapport binnen 72 uur. Dat veronderstelt dat je weet wat er in je systemen gebeurt, en wanneer. Ten derde de ketenverantwoordelijkheid: je bent mede-verantwoordelijk voor de digitale beveiliging van je toeleveranciers en softwareleveranciers. Als jouw ERP-pakket of TMS bij een externe partij draait, moet je kunnen aantonen dat ook die partij aan de normen voldoet. Boetes bij niet-naleving lopen op tot 10 miljoen euro of 2% van de wereldwijde jaaromzet.
Waar loopt de operatie tegenaan?
In de praktijk struikelen maak- en logistiekbedrijven op drie punten. Eerste punt: systemen zijn niet transparant. Wie heeft toegang tot welke data? Welke externe partijen koppelen aan jullie systemen? Dat is in een wildgroei van legacy-software, losse koppelingen en spreadsheets nauwelijks te beantwoorden. Tweede punt: incidentrespons bestaat op papier, maar niet in de praktijk. Een meldplicht van 24 uur veronderstelt dat je een incident herkent en classificeert als het zich voordoet, niet drie dagen later. Dat lukt niet zonder monitoring op je operationele systemen. Derde punt: ketenverantwoordelijkheid is onbekend terrein. Bedrijven weten vaak niet precies welke software zij draaien, wie die beheert, en of die partij ook NIS2-compliant is. Dat is het moment waarop de vraag over software-eigendom ineens juridische relevantie krijgt.
Wat draagt goed gebouwde software bij aan NIS2-compliance?
Gestructureerde data en systeemtransparantie zijn geen IT-luxe, ze zijn een compliance-vereiste. Een systeem dat precies bijhoudt wie wanneer welke actie heeft uitgevoerd, een auditlog bijhoudt per transactie, en toegangsrechten op rolniveau beheert, maakt het voldoen aan de zorgplicht uitvoerbaar in plaats van theoretisch. Hetzelfde geldt voor incidentrespons: als je systeem geïntegreerde logging heeft en afwijkingen signaalt, kun je binnen 24 uur een gefundeerde melding doen. Maatwerksoftware heeft hier een specifiek voordeel: je weet wat erin zit, je beheert de code zelf, en er is geen externe SaaS-leverancier die de spelregels bepaalt over dataopslag of toegang. Bij standaardpakketten moet je aantonen dat de leverancier compliant is, documentatie opvragen die leveranciers niet altijd vlot verstrekken, en hopen dat de update-cyclus aansluit bij de beveiligingsnormen. Bij software waarvan jij eigenaar bent, bepaal je dat zelf.
NIS2 is geen IT-project: de operationeel directeur is aan zet
De Cyberbeveiligingswet legt bestuurlijke verantwoordelijkheid expliciet neer bij de leiding van de organisatie, niet bij de IT-beheerder. Dat betekent dat de operationeel directeur of COO moet kunnen uitleggen welke kritieke processen er zijn, welke systemen die processen ondersteunen, en welke maatregelen zijn genomen als die systemen uitvallen of worden aangevallen. Begin dus bij de operatie: welke processen zijn kritiek, welke systemen draaien daarin, en wat is de impact als ze uitvallen? Vanuit dat beeld werk je terug naar de technische en organisatorische maatregelen. Software-selectie en softwareontwikkeling worden daarmee onderdeel van risicobeleid. Niet als bijzaak, maar als kern.