NIS2 België: zero trust-checklist voor kmo's

De Belgische NIS2-wet is van toepassing sinds 18 oktober 2024. Voor een bedrijf met 50 tot 500 mensen is het moeilijkste deel een lijst wettelijke verplichtingen omzetten in werk dat een IT-team kan plannen en een raad van bestuur kan goedkeuren. Dit artikel legt uit wie onder de wet valt, wat de wet vraagt, hoe de Belgische route via CyberFundamentals (CyFun) werkt en waar zero trust-praktijken helpen om aan specifieke controles te voldoen. Het eindigt met een checklist.

Dit is algemene informatie en geen juridisch advies. De enige authentieke teksten zijn die welke in het Belgisch Staatsblad zijn bekendgemaakt. Gebruik voor je eigen situatie de tools en richtlijnen van het Centrum voor Cybersecurity België (CCB) en, waar nodig, een advocaat.

De Belgische NIS2-wet in het kort

De wet van 26 april 2024 tot vaststelling van een kader voor de cyberbeveiliging van netwerk- en informatiesystemen van algemeen belang voor de openbare veiligheid zet Richtlijn (EU) 2022/2555 om. Ze werd op 17 mei 2024 bekendgemaakt in het Belgisch Staatsblad, en artikel 98 legt de inwerkingtreding vast op 18 oktober 2024. Een koninklijk besluit van 9 juni 2024 voert de wet uit en wijst het CCB aan als nationale cyberbeveiligingsautoriteit.

Valt je organisatie onder de wet?

Volgens de NIS2-pagina van het CCB op Safeonweb@Work valt een organisatie in principe onder de wet als aan drie voorwaarden is voldaan. Ze levert een dienst die in bijlage I of II van de wet staat. Ze is minstens een middelgrote onderneming volgens Aanbeveling 2003/361/EG van de Commissie, wat betekent minstens 50 voltijdse equivalenten, of een jaaromzet en een balanstotaal die allebei boven EUR 10 miljoen liggen. En ze is gevestigd in België.

Bijlage I somt de sectoren met een hoge kriticiteit op: energie, vervoer, bankwezen, infrastructuur voor de financiële markt, gezondheidszorg, drinkwater, afvalwater, digitale infrastructuur, beheer van ICT-diensten (business-to-business), overheid en ruimtevaart. Bijlage II omvat post- en koeriersdiensten, afvalstoffenbeheer, chemische stoffen, levensmiddelen, verschillende deelsectoren van de industrie (medische hulpmiddelen, elektronica, elektrische apparatuur, machines, motorvoertuigen en andere transportmiddelen), digitale aanbieders en onderzoek.

De omvang wordt op groepsniveau berekend wanneer een bedrijf partnerondernemingen of verbonden ondernemingen heeft. Een dochter van 30 mensen binnen een grotere groep kan dus onder de wet vallen, ook al lijkt ze op zich klein. Sommige entiteiten vallen er ongeacht hun omvang onder, zoals gekwalificeerde verleners van vertrouwensdiensten en DNS-dienstverleners. Het CCB kan een organisatie ook als essentieel of belangrijk identificeren op grond van artikel 11 van de wet.

Volgens de artikelen 9 en 10 zijn entiteiten uit bijlage I die boven de drempels voor middelgrote ondernemingen uitkomen (in de praktijk grote ondernemingen) essentiële entiteiten. De meeste andere entiteiten uit bijlage I en II die onder de wet vallen, zijn belangrijke entiteiten. Het CCB wijst erop dat het verschil vooral zit in hoe streng ze worden gecontroleerd en gesanctioneerd.

Het CCB biedt een downloadbare NIS2-scopetest (een Excelbestand) en een quickstartgids in zeven stappen. Begin daar als je twijfelt.

Ook bedrijven buiten het toepassingsgebied kunnen geraakt worden. NIS2-entiteiten moeten de beveiliging van hun toeleveringsketen beheren, en het CCB raadt organisaties in de toeleveringsketen van een NIS2-entiteit aan om minstens CyFun Basic toe te passen.

Wat de wet vraagt

Registratie

Entiteiten registreren zich bij het CCB via Safeonweb@Work. Artikel 13 van de wet geeft daarvoor vijf maanden na de inwerkingtreding, waardoor de deadline op 18 maart 2025 viel. Bepaalde digitale aanbieders (onder meer DNS-, cloud-, datacenter- en beheerde dienstverleners) hadden tijd tot 18 december 2024. Entiteiten die later geïdentificeerd worden, hebben vijf maanden vanaf hun identificatie. Wijzigingen in de geregistreerde gegevens moeten aan het CCB worden gemeld.

Maatregelen voor risicobeheer

Artikel 30 van de Belgische wet, dat artikel 21 van de richtlijn omzet, vraagt passende en evenredige technische, operationele en organisatorische maatregelen, gebaseerd op een benadering die alle gevaren omvat. De minimale lijst bevat beleid voor risicoanalyse, incidentenbehandeling, bedrijfscontinuïteit en back-ups, beveiliging van de toeleveringsketen, beveiliging bij aankoop en onderhoud, het testen van de doeltreffendheid, cyberhygiëne en opleiding, cryptografie, beveiligingsaspecten ten aanzien van personeel met toegangsbeleid en beheer van activa, en, in artikel 21, lid 2, j), "het gebruik van multifactorauthenticatie of continue authenticatie" waar dat passend is.

Incidentmelding

Significante incidenten worden gemeld aan het nationale CSIRT, en dat is het CCB. Artikel 35 legt de fasen vast: een vroegtijdige waarschuwing binnen 24 uur nadat je kennis kreeg van het incident, een incidentmelding binnen 72 uur, een tussentijds verslag op verzoek, en een eindverslag uiterlijk een maand na de incidentmelding. Meldingen gebeuren op het meldingsplatform van het CCB, en het CCB publiceert een meldingsgids.

Verantwoordelijkheid van het bestuur

Volgens artikel 31 keurt het leidinggevend orgaan de maatregelen voor risicobeheer goed, houdt het toezicht op de uitvoering ervan en is het aansprakelijk voor inbreuken. De leden moeten een opleiding volgen zodat ze risico's kunnen herkennen en cyberbeveiligingspraktijken kunnen beoordelen. Het CCB vermeldt administratieve geldboetes tot EUR 10 miljoen of 2% van de wereldwijde omzet voor essentiële entiteiten, en tot EUR 7 miljoen of 1,4% voor belangrijke entiteiten.

De conformiteitsroute: CyFun of ISO/IEC 27001

Het CyberFundamentals-raamwerk heeft drie zekerheidsniveaus: Basic, Important en Essential. CyFun 2025 is afgestemd op NIST CSF 2.0, en daarom zien de controlereferenties eruit als PR.AA-03.2. CyFun 2023 en CyFun 2025 zijn allebei beschikbaar tijdens een overgangsperiode, waarna alleen de versie van 2025 nog aanvaard wordt. Het CCB stelt dat een gevalideerde CyFun-implementatie NIS2-entiteiten een vermoeden van conformiteit geeft. Het koninklijk besluit aanvaardt ook ISO/IEC 27001, met een toepassingsgebied dat alle netwerk- en informatiesystemen van de entiteit dekt.

Essentiële entiteiten moeten regelmatig een conformiteitsbeoordeling ondergaan. Op belangrijke entiteiten wordt in principe achteraf toezicht gehouden, bijvoorbeeld na een incident, maar ze kunnen vrijwillig voor hetzelfde regime kiezen. De FAQ van het CCB zegt uitdrukkelijk dat belangrijke entiteiten toch alle beveiligingsmaatregelen moeten uitvoeren.

Deadlines voor essentiële entiteiten

Deze data komen uit artikel 22 van het koninklijk besluit van 9 juni 2024 (18 en 30 maanden na de inwerkingtreding, of na de identificatie), zoals verwoord in de NIS2-tijdlijn van het CCB en de FAQ over NIS2 en CyFun:

Tegen 18 april 2026 hadden entiteiten op de CyFun-route minstens een verificatie CyFun Basic of Important nodig door een geaccrediteerde conformiteitsbeoordelingsinstantie (CAB) die door het CCB is erkend. Entiteiten op de ISO/IEC 27001-route moesten het CCB het toepassingsgebied van hun certificering, hun verklaring van toepasselijkheid en hun laatste interne audit bezorgen.
Tegen 18 april 2027 moeten CyFun-entiteiten een certificering CyFun Essential hebben, tenzij een gedocumenteerde risicobeoordeling een lager niveau rechtvaardigt volgens artikel 7 van het koninklijk besluit. ISO/IEC 27001-entiteiten moeten hun certificering hebben, met een verklaring van toepasselijkheid die maatregelen toont die gelijkwaardig zijn aan het CyFun-niveau dat voor hen geldt.
Entiteiten die in plaats daarvan voor inspectie door het CCB kozen, sturen een zelfbeoordeling (of ISO-documenten) tegen 18 april 2026 en een voortgangsrapport tegen 18 april 2027.

Op 11 augustus 2026 publiceerde de inspectiedienst van het CCB een mededeling (ref. NCCA/JK/INS/2026-002) over wat er gebeurt als een essentiële entiteit Essential niet haalt tegen 18 april 2027. Ze vraagt zulke entiteiten een herstelplan in te dienen, bij voorkeur met bewijs van CyFun Important en een beschrijving van hoe Essential tegen 18 april 2028 bereikt wordt. De mededeling stelt dat ze niets verandert aan de wettelijke verplichtingen. Ze merkt ook op dat het gebruik van geavanceerde AI nieuwe vragen oproept voor governance, risicobeoordeling, beveiliging van de toeleveringsketen, monitoring en incidentrespons.

Waar zero trust past

NIS2 noch CyFun eist "zero trust" bij naam. In een zero trust-opzet wordt elk verzoek afzonderlijk geauthenticeerd en geautoriseerd, wordt toegang per applicatie verleend en wordt niets vertrouwd omdat het op het interne netwerk staat. Verschillende van die praktijken sluiten aan bij concrete controles. De referenties hieronder komen uit de CyFun 2025-mapping van het CCB (bestand van 23 september 2026), die elke controle koppelt aan de richtlijn.

Zet MFA op elke toegang van buitenaf. CyFun Basic PR.AA-03.2 vereist MFA voor netwerktoegang op afstand, en de mapping koppelt die controle aan artikel 21, lid 2, j). Een zero trust-gateway kan MFA voor elke applicatie plaatsen, ook voor oude applicaties die zelf geen MFA kunnen.
Geef toegang per applicatie, met zo weinig rechten als nodig. PR.AA-05.3 beperkt de toegang tot de systemen en informatie die nodig zijn voor de taak, en PR.AA-05.4 verbiedt beheerdersrechten voor routinewerk. Beleid per applicatie is makkelijker na te kijken dan brede VPN-groepen.
Segmenteer het netwerk. PR.IR-01.2 vraagt een segmentatie die aansluit bij vertrouwensgrenzen en de kriticiteit van activa. Een VPN die een laptop op het hele kantoornetwerk zet, maakt dat moeilijker. Toegang per applicatie houdt elke verbinding binnen één grens.
Houd beheerinterfaces weg van het internet. Consoles voor firewall, hypervisor en back-up horen achter geauthenticeerde toegang. Dat ondersteunt PR.IR-01 en, op niveau Essential, PR.PS-01.3, dat organisaties vraagt poorten en diensten uit te schakelen die niet nodig zijn.
Houd een inventaris van activa bij. ID.AM-01.1 en ID.AM-02.1 vereisen inventarissen van infrastructuur en software. Je kunt geen toegangsbeleid schrijven voor systemen die je niet hebt opgelijst.
Log toegang met de deadline van 24 uur in gedachten. PR.PS-04.1 en DE.AE-03.1 vereisen dat logs bewaard en nagekeken worden. Een centraal toegangslog dat bijhoudt wie welk systeem wanneer bereikte, helpt je binnen enkele uren te beslissen of een incident significant is.
Beheers de toegang van leveranciers. Op niveau Important vereist ID.AM-08.11 dat onderhoud op afstand vooraf goedgekeurd en gelogd wordt, en GV.SC-07.1 behandelt leveranciersrisico. Tijdelijke sessies voor een leverancier naar één host vervangen een permanent open RDP-poort of een gedeeld VPN-account.
Behandel serviceaccounts en AI-agents als identiteiten. PR.AA-01.1 vereist dat identiteiten en inloggegevens beheerd worden voor gebruikers, diensten en hardware. Een AI-agent die interne systemen aanroept, is een service-identiteit en heeft een eigenaar, afgebakende rechten en een audittrail nodig.

Een checklist voor Belgische kmo's

Voer de scopetest van het CCB uit en noteer het resultaat, inclusief de omvang op groepsniveau en elke dienst die je levert (wet, artikelen 9 en 10).
Controleer je registratie op Safeonweb@Work en of de contactgegevens actueel zijn (artikel 13).
Kies je raamwerk (CyFun of ISO/IEC 27001) en, voor CyFun, een doelniveau op basis van een gedocumenteerde risicobeoordeling (koninklijk besluit, artikelen 5 en 7).
Leg de maatregelen voor risicobeheer ter goedkeuring voor aan het bestuur en plan de opleiding voor het management (artikel 31).
Stel de inventaris van hardware, software en cloud op of werk hem bij (ID.AM-01.1, ID.AM-02.1).
Maak MFA verplicht voor alle toegang op afstand, te beginnen met mail, beheerportalen en remote desktop (PR.AA-03.2, artikel 21, lid 2, j) van de richtlijn).
Haal permanente beheerdersrechten weg van dagelijkse accounts en kijk toegangsrechten volgens een vaste cyclus na (PR.AA-05.1, PR.AA-05.4).
Vervang VPN-toegang tot het hele netwerk waar mogelijk door toegang per applicatie, en segmenteer kritieke systemen (PR.IR-01.2).
Controleer dat geen enkele beheerinterface vanaf het internet bereikbaar is, en sluit poorten die je niet nodig hebt (PR.IR-01, PR.PS-01.3).
Maak een lijst van elke leverancier met toegang op afstand, zet ze over naar persoonlijke, tijdelijke en gelogde sessies en documenteer het risico (ID.AM-08.11, GV.SC-07.1, artikel 21, lid 2, d) van de richtlijn).
Maak een lijst van serviceaccounts, API-sleutels en AI-agents, geef elk een eigenaar en beperk wat elk kan bereiken (PR.AA-01.1, PR.AA-05.3).
Centraliseer toegangs- en beveiligingslogs, leg een bewaartermijn vast en kijk ze na (PR.PS-04.1, DE.AE-03.1).
Schrijf een incidentresponsplan dat vastlegt wie de vroegtijdige waarschuwing binnen 24 uur en de melding binnen 72 uur indient op het platform van het CCB (RS.MA-01.1, artikel 35 van de wet).
Test back-ups en een herstelrun (PR.DS-11.1, RC.RP-01.1).
Ben je een essentiële entiteit, controleer dan je status tegenover de deadline van 18 april 2027 en de mededeling van het CCB van augustus 2026 voor je de volgende audit plant.

Over Flowplane

Bij Flowplane bouwen we een Europese zero trust-gateway voor mensen en AI-agents. Er is nog niets beschikbaar, en er zijn vandaag geen klanten of certificeringen. Zodra hij gelanceerd wordt, wil hij de toegang per applicatie, de MFA en de toegangslogging dekken die hierboven beschreven staan.

NIS2 en zero trust: een praktische checklist voor Belgische kmo's