NIS2 verplicht organisaties en hun IT-leveranciers tot aantoonbare monitoring van netwerk- en informatiesystemen. Dat staat expliciet in artikel 21 van de NIS2-richtlijn (EU 2022/2555), niet als aanbeveling, maar als verplichting.
De grootste technische impact zit niet in preventieve maatregelen zoals firewalls of antivirus. Die heb je al. De impact zit in de 24-uurs meldplicht: je moet een significant incident binnen 24 uur na ontdekking melden bij het CSIRT. Dat vereist dat je het incident ook daadwerkelijk binnen die 24 uur detecteert. Zonder adequate logging en detectie is dat onmogelijk.
Voor MSPs die meerdere klantomgevingen beheren geldt dit dubbel: je hebt logging en detectie nodig op elk systeem dat je beheert, niet alleen op je eigen infrastructuur.
Waarom de 24-uurs meldplicht de technische lat volledig verandert
Veel MSPs hebben beveiliging ingericht op preventie: firewalls, EDR, patchbeleid. Maar NIS2 voegt een tweede vereiste toe die preventie alleen niet kan invullen: je moet incidenten ook detecteren en kunnen melden.
Volgens het Verizon Data Breach Investigations Report (DBIR 2024) duurt het bij gecompromitteerde organisaties gemiddeld 197 dagen voordat een aanval wordt ontdekt. Dat staat haaks op de NIS2-meldplicht van 24 uur na ontdekking.
De keten is simpel: geen logging → geen detectie → geen melding binnen 24 uur → non-compliant, ongeacht hoe goed je andere maatregelen zijn. Voor MSPs die meerdere klantomgevingen beheren is dit bijzonder kritiek: je hebt logging nodig op elk systeem dat je beheert, niet alleen op je eigen infrastructuur.
De vijf technische verplichtingen van NIS2 voor informatiesystemen
Artikel 21 van de NIS2-richtlijn somt de verplichte maatregelen op. Voor informatiesystemen zijn vijf verplichtingen direct technisch vertaalbaar.
1. Toegangsbeveiliging en identity management
NIS2 vereist “toegangsbeveiliging” als basismaatregel. Concreet voor MSPs:
Multi-factor authenticatie (MFA) is de minimumstandaard voor alle beheertoegang — op het RMM-platform, VPN-gateways, cloud management consoles en e-mail. Een beheerder die zonder MFA toegang heeft tot tientallen klantomgevingen, vormt een enkelvoudig punt van falen.
Least-privilege principe: elk account heeft alleen de rechten die noodzakelijk zijn voor de specifieke functie. Geen gedeelde beheerdersaccounts voor meerdere klanten. Geen permanent verhoogde rechten — gebruik Just-in-Time toegang voor beheeractiviteiten.
Toegangsreviews: periodiek (minimaal jaarlijks) controleren welke accounts actief zijn en of de toegangsrechten nog correct zijn. Accounts van vertrokken medewerkers of ex-klanten direct intrekken.
2. Logging en monitoring — de kern van NIS2-aantoonbaarheid
Dit is de technische pijler die de meeste MSPs nog niet op orde hebben. NIS2 vereist “monitoring van netwerk- en informatiesystemen” — dat betekent aantoonbare logging van alle relevante activiteiten.
Wat je minimaal logt:
- Alle authenticatiepogingen (geslaagd én mislukt)
- Alle beheerdersactiviteiten op kritieke systemen
- Netwerkverbindingen van en naar kritieke systemen
- Wijzigingen in gebruikersrechten en systeemsettings
- Activiteit op databases met gevoelige data
Retentie: logs moeten minimaal 12 maanden bewaard worden, bij voorkeur 3 jaar voor NIS2-audit-doeleinden.
SIEM als fundament: een Security Information and Event Management systeem centraliseert logs van alle beheerde omgevingen en detecteert afwijkingen automatisch. Zonder SIEM is monitoring van tientallen klantomgevingen praktisch onschaalbaar.
3. Kwetsbaarheidsbeheer en patchmanagement
“Het beheer van kwetsbaarheden en patches” is een expliciete NIS2-verplichting. Voor informatiesystemen betekent dit:
Continue vulnerability scanning op alle beheerde systemen — wekelijks voor publiek bereikbare systemen, maandelijks voor intern bereikbare systemen.
CVSS-gebaseerde prioritering: kritieke kwetsbaarheden (CVSS ≥ 9.0) binnen 24-72 uur patchen, hoge kwetsbaarheden (CVSS 7.0-8.9) binnen 30 dagen.
Documentatie: per systeem vastleggen welke kwetsbaarheden bekend zijn, wanneer patches zijn uitgerold, en bij uitstel: waarom en welke compenserende maatregel is genomen.
Scope: niet alleen servers en werkstations — ook netwerkapparatuur, firewalls, VPN-concentrators en IoT-apparaten. NIS2 maakt geen onderscheid.
4. Netwerksegmentatie en architectuurmaatregelen
NIS2 vereist “beveiliging van netwerken en informatiesystemen” als technische maatregel. Voor MSPs heeft dit een specifieke invulling:
Segmentatie van klantomgevingen: een aanvaller die één klantomgeving compromitteert via jouw beheerplatform, mag niet automatisch bij andere klanten kunnen komen. Dit vereist strikte netwerksegmentatie en aparte privileged accounts per klant.
Zero trust architectuur: verifieer elke toegangsaanvraag ongeacht de netwerklocatie. Interne netwerktoegang is geen impliciete autorisatie.
Encryptie: alle data in transit versleuteld via TLS 1.2 minimaal (1.3 aanbevolen). Data in rust versleuteld op systemen die gevoelige klantdata bevatten.
5. Business continuity en herstelcapaciteit
Artikel 21 NIS2 verplicht tot “bedrijfscontinuïteit en crisisbeheer.” Voor informatiesystemen:
Gedocumenteerde RTO en RPO per kritieke dienst: hoe lang mag een systeem maximaal offline zijn (Recovery Time Objective) en hoeveel dataverlies is acceptabel (Recovery Point Objective)?
Immutable backups: offline of air-gapped backupkopieën die een ransomware-aanvaller niet kan versleutelen of verwijderen.
Geteste herstelplannen: een backup die nooit is getest, is geen backup. Minimaal kwartaals een hersteltest op representatieve systemen.
De 24-uurs meldplicht technisch invullen
De meldplicht is de meest onderschatte technische uitdaging van NIS2. De vereiste is: binnen 24 uur na ontdekking een early warning naar het CSIRT. Dat klinkt eenvoudig — maar stelt hoge eisen aan detectiecapaciteit.
Wat “ontdekking” betekent in de praktijk
De 24-uurs klok begint te lopen op het moment dat je redelijkerwijs op de hoogte kunt zijn van het incident. Niet pas als alle details bekend zijn. Als een SIEM-alert aangeeft dat er verdachte activiteit is op een klantomgeving, begint de klok — ook als het onderzoek nog loopt.
Technische vereisten voor tijdige detectie
EDR op alle endpoints: gedragsanalyse die ransomware-activiteit, lateral movement en credential theft detecteert voor de schade volledig is aangericht.
SIEM met alerting: gecentraliseerde loganalyse met automatische alerts op afwijkend gedrag. Zonder geautomatiseerde alerting mis je incidenten tot medewerkers handmatig in logs duiken.
Network monitoring: detectie van ongebruikelijk netwerkverkeer — grote data-overdrachten, verbindingen met bekende malafide IP-adressen, onverwachte externe communicatie.
CTI-integratie: Indicators of Compromise (IoCs) van het NCSC en dreigingsintelligence-feeds automatisch inladen in SIEM en EDR.
Het meldproces voorbereiden
Wachten tot een incident plaatsvindt om dan pas een procedure op te stellen, is te laat. Stel vooraf in:
| Stap | Termijn | Inhoud |
|---|---|---|
| Early warning CSIRT | 24 uur na ontdekking | Wat is er aan de hand, vermoeden kwade opzet, getroffen systemen |
| Incident notification | 72 uur | Ernst, omvang, eerste IoCs, genomen maatregelen |
| Eindrapport | 1 maand | Rootcause, volledige tijdlijn, structurele maatregelen |
Vergelijkingstabel: technische NIS2-maatregelen voor informatiesystemen
| Maatregel | NIS2-vereiste | Tooling | Prioriteit |
|---|---|---|---|
| MFA op alle beheertoegang | Verplicht (art. 21) | Microsoft Authenticator, hardware tokens | Direct |
| Centralized logging (SIEM) | Verplicht | Splunk, Microsoft Sentinel, Elastic | Direct |
| EDR op alle endpoints | Verplicht | CrowdStrike, SentinelOne, Defender for Endpoint | Direct |
| Vulnerability scanning | Verplicht | Nessus, Qualys, OpenVAS | Week 1-2 |
| Netwerksegmentatie klanten | Verplicht | VLAN, firewall rules, Zero Trust | Week 2-4 |
| Immutable backups | Verplicht | Veeam + object lock, Datto | Week 1-2 |
| Patch management gedocumenteerd | Verplicht | NinjaRMM, Automox, ConnectWise | Week 1-2 |
| Incident response plan | Verplicht | Documentatie + oefening | Maand 1 |
Een gap analyse brengt in kaart waar jouw huidige technische maatregelen tekortschieten ten opzichte van de NIS2-verplichtingen uit artikel 21.
NIS2 en de verantwoordelijkheid van MSPs als IT-leverancier
MSPs hebben een dubbele verantwoordelijkheid onder NIS2. Ten eerste als organisatie die mogelijk zelf onder de Cyberbeveiligingswet valt (MSPs met meer dan 50 medewerkers en meer dan €10M omzet die IT-diensten leveren aan essentiële sectoren). Ten tweede als leverancier in de supply chain van NIS2-plichtige klanten.
In de tweede rol zijn je klanten verplicht hun leveranciers te beoordelen op beveiligingsniveau. Dat betekent dat klanten jou zullen vragen om te bewijzen dat jouw informatiesystemen voldoen aan NIS2-eisen. De technische maatregelen die je implementeert voor je eigen compliance, zijn tegelijkertijd het bewijs dat klanten van je vragen.
Veelgestelde vragen over NIS2 en informatiesystemen
Welke informatiesystemen vallen onder NIS2?
Alle systemen die worden gebruikt voor de levering van de diensten waarvoor de organisatie onder NIS2 valt. Voor MSPs: de beheerplatforms, RMM-tools, ITSM-systemen, en de klantomgevingen die je beheert. Er is geen minimumdrempel — ook kleine systemen die relevant zijn voor de dienstverlening vallen in scope.
Is een SIEM verplicht onder NIS2?
De wet verplicht geen specifiek product, maar wel “monitoring van netwerk- en informatiesystemen.” In de praktijk is een SIEM de enige schaalbare manier om die monitoring aantoonbaar te maken voor meerdere klantomgevingen tegelijk. Auditors verwachten een geautomatiseerde monitoring-oplossing.
Hoe lang moet ik logs bewaren voor NIS2?
De NIS2-richtlijn specificeert geen exacte bewaartermijn voor logs. De praktijknorm die auditors hanteren: minimaal 12 maanden online beschikbaar, 3 jaar archief. Dit sluit aan bij de bewaarplichten onder de AVG en de Cbw.
Wat als een incident bij een klant plaatsvindt via mijn beheerplatform?
Als jouw systemen of toegang betrokken zijn bij een incident bij een klant, ben je als MSP medeverantwoordelijk voor de detectie en melding. Jij hebt doorgaans de beste technische positie om het incident te detecteren — via SIEM, EDR of netwerk-monitoring. Informeer de klant onverwijld en coördineer de melding bij het CSIRT.
Hoe bewijs ik NIS2-compliance aan klanten voor informatiesystemen?
Vier typen bewijs die auditors en klanten verwachten: (1) SIEM-rapportages die aantonen dat monitoring actief is, (2) patchrapporten per klantomgeving, (3) toegangsreviews gedocumenteerd, (4) incidentlog inclusief gevallen waarbij geen melding nodig was met de motivatie daarvoor.
Zie ook de ISO 27001 checklist voor een volledig overzicht van de controls die de meeste NIS2-verplichtingen afdekken.
Weet je niet zeker of jouw monitoring- en detectiecapaciteit voldoet aan de NIS2-technische eisen? Doe de gratis NIS2-quickscan of lees de volledige gids: NIS2 MSP compliance.