Hoe ik NIS2-trajecten begeleid (en waar het altijd fout gaat)

Ik begeleid bedrijven in kortdurende NIS2-implementatietrajecten, grotendeels gebaseerd op ISO 27001-richtlijnen plus de verplichte extra elementen uit de NIS2-richtlijn. Het proces is overzichtelijk:

1. Risico-analyse met de directie - Welke systemen zijn kritiek? Wat zijn de grootste dreigingen?

2. Interviews met sleutelfunctionarissen - IT, kwaliteit, operatie, HR, finance

3. Gap-analyse - Waar staan we nu, waar moeten we naartoe?

4. Beleid op maat schrijven - Geen standaard templates, maar écht passend bij de organisatie

5. Roadmap - Concrete acties met eigenaren en deadlines

6. Operationele Planning - Concrete terugkerende controles en toezicht op maatregelen

Op papier klinkt dit helder. In de praktijk loop ik regelmatig tegen dezelfde muur: onduidelijk eigenaarschap. Niet in stap 4 of 5. Maar al in stap 1.

De vier blinde vlekken die ik elke keer tegenkom

1. IT voelt zich verantwoordelijk voor infrastructuur — niet voor SaaS

Wat ik hoor:

"Wij beheren de servers, het netwerk, de laptops. Maar die Salesforce-omgeving? Die Google Workspace? Dat heeft verkoop zelf aangeschaft. Daar hebben wij niets mee te maken."

Het probleem:

De afgelopen vijf jaar zijn organisaties massaal naar SaaS-oplossingen overgestapt. Vaak zonder IT erbij te betrekken. En nu? Die systemen bevatten klantdata, contracten, personeelsgegevens - maar niemand voelt zich verantwoordelijk voor de beveiliging ervan.

Concrete voorbeelden van blinde vlekken:

• Wie borgt dat Multi-Factor Authentication (MFA) verplicht is?

• Wie checkt of een vertrekkende medewerker uit álle systemen wordt gehaald?

• Wie heeft de contracten gelezen? Wat gebeurt er als de SaaS-leverancier omvalt of gehackt wordt?

• Wie is verantwoordelijk voor de exit-strategie? Hoe krijgen we dan onze data 'terug'?

• Wie monitort verdachte inlogpogingen?

Antwoord: meestal niemand.

Waarom dit gevaarlijk is:

SaaS-oplossingen worden standaard gezien als "veilig" omdat je niet hoeft te patchen. Maar beveiliging is meer dan patchen. Het gaat om toegangsbeheer, monitoring, exit-strategieën, beoordeling van de leverancier inzake ketenrisico's en contractuele afspraken.

En als niemand zich eigenaar voelt van die SaaS-omgeving, gebeurt daar niets.

2. Technische Dienst beheert OT, maar ziet security als "iets voor IT"

Wat ik hoor:

"Die productielijn? Die draait al tien jaar. Nooit problemen mee gehad. Security is toch iets voor de IT-afdeling?"

Het probleem:

Operational Technology (OT) - denk aan productielijnen, PLC-systemen, toegangscontrole - is vaak compleet gescheiden van IT. Andere afdelingen, ander budget, andere leveranciers.

Maar steeds vaker zijn die OT-systemen wél verbonden met het netwerk. Voor remote support. Voor monitoring. Voor efficiency.

En dan heb je een probleem:

• Technische Dienst heeft geen security-expertise

• IT heeft geen OT-expertise

• Vaak voelt niemand zich eigenaar van het snijvlak

Concrete risico's:

• Remote access zonder MFA (leverancier belt: "Ik moet erin voor onderhoud" of kan er zelfs zelfstandig bij)

• Verouderde systemen zonder patches (leverancier zegt: "Update op eigen risico". TIP: Dit is iets waar ze na de invoering van de Cyber Resilience Act (CRA) niet meer mee wegkomen. Gebruik dit in je voordeel in gesprekken met je (OT) leveranciers

• Geen segmentatie tussen OT en IT-netwerk (als IT gehackt wordt, ligt productie ook stil)

Waarom dit gevaarlijk is:

OT-incidenten kunnen fysieke schade veroorzaken. Denk aan de Oldsmar waterzuiveringsinstallatie (Florida, 2021) waar een aanvaller via remote access gif in het drinkwater probeerde te injecteren.

Of dichter bij huis: productielijnen die dagenlang stilliggen door ransomware. Niet omdat IT getroffen is, maar omdat de OT-omgeving niet gesegmenteerd was.

3. HR en directie: "Informatiebeveiliging? Dat is toch iets voor IT?"

Wat ik hoor:

Directie: "Wij hebben een IT-manager. Die regelt dat toch?"

HR: "Wij werken met een HR-systeem. Verder hebben we er weinig mee te maken."

Het probleem:

Informatiebeveiliging wordt gezien als een technisch vraagstuk. Maar in werkelijkheid is het een managementvraagstuk.

Voorbeelden waar HR en directie wél verantwoordelijk zijn:

HR:

• Wie borgt dat nieuwe medewerkers awareness-training krijgen?

• Wie checkt of vertrekkende medewerkers uit alle systemen worden gehaald?

• Wie beheert de toegang tot salarisgegevens en personeelsdossiers?

Directie:

• Wie besluit welke risico's we accepteren en welke we mitigeren?

• Wie stelt budget beschikbaar voor security-maatregelen?

• Wie is aanspreekpunt bij een ernstig incident (zoals een datalek)?

Waarom dit gevaarlijk is:

Als de directie security ziet als "iets voor IT", krijgt het geen prioriteit. Risico's worden niet besproken in MT-overleggen. En als er een incident is? Dan staat de directie er - juridisch én reputationeel.

De rol van de directie bij NIS2:

NIS2 maakt dit expliciet: de directie is persoonlijk aansprakelijk bij nalatigheid. Niet de IT-manager. Niet de security officer. De directie.

Dat maakt informatiebeveiliging ineens een boardroom-issue. En terecht.

4. De security officer: "Dat is toch de IT-manager?"

Wat ik hoor:

"We hebben toch een IT-manager? Die kan dat er wel bij doen."

Het probleem:

Een goede security officer moet de hele organisatie overzien:

• IT-infrastructuur

• SaaS-toepassingen

• OT-omgevingen

• HR-processen

• Contractbeheer met leveranciers

• Awareness bij medewerkers

• Toezicht op de Operationele Planning

Dat is geen IT-functie. Dat is een managementfunctie.

Technische affiniteit is handig - maar niet alles zeggend. Wat wél nodig is:

• Overzicht over domeinen heen

• Communicatieve vaardigheden (richting directie, MT, werkvloer)

• Projectmanagement (roadmaps, prioriteiten, budget)

• Risicomanagement (keuzes maken: wat accepteren we, wat niet?)

Waarom de IT-manager niet altijd de juiste keuze is:

1. Tunnelvisie: IT-managers zijn gewend aan technische vraagstukken, niet aan organisatiebrede governance

2. Onvoldoende mandaat: Security gaat over álle afdelingen. Heeft je IT-manager genoeg gezag om HR, verkoop, en de Technische Dienst aan te spreken?

3. Tijdsdruk: Je IT-manager heeft al een fulltime baan. Security erbij is een recept voor "het komt er niet van"

4. Belangenverstrengeling: De IT-Manager wordt vaak afgerekend op concrete doelen, zoals de 'go-live' van systeem X. Wie moet ingrijpen als die 'go-live' niet verantwoord is vanuit cybersecurity (risico) perspectief?

Alternatieve profielen die ik succesvol heb gezien:

• Kwaliteitsmanagers (gewend aan managementsystemen, procesdenken, controls)

• Risk & compliance officers

• (Interim) projectmanagers met security-affiniteit

Waarom food- en productieorganisaties hier vaak beter in zijn dan tech-bedrijven

Dit klinkt paradoxaal, maar ik zie het elke keer terug.

Organisaties in de foodsector begrijpen NIS2 intuïtief beter dan IT-bedrijven.

Waarom?

Omdat ze al jaren werken met managementsystemen:

• ISO 22000 (voedselveiligheid)

• HACCP (kritische controlepunten)

• IFS / BRC (kwaliteitsborging voor retail)

Deze systemen draaien om:

• Procesdenken (wie doet wat, wanneer, waarom)

• Controls (hoe borgen we dat het goed gaat?)

• Eigenaarschap per domein (productie, inkoop, kwaliteit, logistiek)

• Auditcultuur (interne checks, externe audits, management reviews)

Dat is precies wat NIS2 vraagt.

Concrete parallel:

HACCP	NIS2
Identificeer kritieke controlepunten	Identificeer kritieke IT-systemen
Stel limieten vast (temperatuur, pH)	Stel risicolimieten vast (downtime, datalekken)
Monitor continu	Monitor security events
Corrigerende actie bij afwijking	Incident response bij security-event
Documenteer alles	Loggen, rapporteren, audits

Wat ik vaak zie:

IT-afdelingen worstelen met ISO 27001 omdat ze geen ervaring hebben met managementsystemen. Ze denken in techniek, niet in processen.

Kwaliteitsafdelingen snappen het binnen een uur. "Oh, dit is gewoon HACCP voor IT."

Mijn advies aan directies:

Betrek je kwaliteitsafdeling bij je NIS2-traject. Niet om de techniek te doen, maar om het managementsysteem op te zetten.

Techniek kun je uitbesteden. Governance niet.

Waarom onduidelijk eigenaarschap alles verlamt

Dit is waar NIS2-trajecten vastlopen.

Niet bij de gap-analyse. Niet bij de roadmap. Maar bij de vraag: "Wie pakt dit op?"

Wat ik zie gebeuren:

1. We identificeren een risico (bijvoorbeeld: geen MFA op SaaS-tools)

2. We formuleren een maatregel (MFA verplicht stellen)

3. We zetten het op de roadmap

4. En dan... niets

Waarom?

Omdat niemand zich eigenaar voelt.

IT zegt: "Die tool is niet van ons, dat heeft marketing aangeschaft." Marketing zegt: "Wij snappen daar niets van, dat is toch iets voor IT?"

Het resultaat:

De maatregel blijft liggen. Niet door onwil, maar door onduidelijkheid.

De oplossing:

Elke maatregel heeft een naam nodig. Een persoon die verantwoordelijk is.

Niet "IT lost dit op". Maar: "Jan (IT-manager) regelt MFA voor alle SaaS-tools, in overleg met Anne (HR) en Pieter (verkoop)." De Business eigenaar, IT en de security officer moeten samenwerken in plaats van elkaar tegenwerken.

Zo wordt het concreet.

Drie vragen die ik altijd stel aan het begin van een traject

1. Wie is hier eigenaar?

Voor elk kritiek systeem, voor elke maatregel, voor elk proces: wie is verantwoordelijk?

Niet "de afdeling". Een naam (of functie).

2. Wat accepteren we bewust als risico?

Je kunt niet alles beveiligen. Sommige risico's zijn te klein, te duur, of te complex om nu aan te pakken.

Maar dan moet je het wél benoemen. En de directie moet het expliciet accepteren.

Anders blijf je eindeloos in discussie.

3. Wanneer is het goed genoeg?

NIS2 vraagt om "passende en evenredige maatregelen". Niet om perfectie.

Maar wat is passend? Wanneer is het klaar?

Als je die lat niet stelt, wordt elk traject een bodemloze put.

Eigenaarschap is geen formaliteit. Het is het fundament.

Organisaties die eigenaarschap goed beleggen, komen verder dan ze verwachten - en sneller dan ze denken.

Niet omdat de techniek makkelijker is. Maar omdat duidelijk is wie wat doet.

En dat maakt het verschil tussen:

• Een NIS2-traject dat vastloopt in discussies

• Een NIS2-traject dat daadwerkelijk security verbetert

Hulp nodig bij het beleggen van eigenaarschap in jouw NIS2-traject?

Als Interim CIO en NIS2-specialist begeleid ik organisaties bij kortdurende implementatietrajecten. Dit omvat:

• Risico-analyse met de directie om kritieke systemen en processen te identificeren

• Gap-analyse en roadmap op basis van ISO 27001 + NIS2-vereisten

• Beleid op maat (geen templates, maar écht passend bij jouw organisatie)

• Operationele Planning om de werking van je maatregelen te toetsen (immers: Plan- Do -Check - Act)

• Eigenaarschap faciliteren tussen IT, OT, kwaliteit, HR en directie

• Interim security officer-rol voor organisaties die deze functie (nog) niet intern hebben (optioneel)

Benieuwd wat ik voor jouw organisatie kan betekenen, bij voorkeur in Overijssel en Gelderland? Actief in Overijssel en Gelderland — Zwolle, Apeldoorn, Enschede, Arnhem, Nijmegen en omgeving.

Neem contact op voor een vrijblijvend gesprek

Eigenaarschap is een van de belangrijkste thema's binnen NIS2