Hoe voldoe je aan de NIS2-eisen voor ketenbeveiliging?

Wat vereist NIS2 voor ketenbeveiliging?

NIS2 verplicht je de beveiligingsrisico's te beheersen die van je leveranciers en dienstverleners komen. Je baseert je maatregelen op de specifieke risico's van elke directe leverancier. Het is een van de tien maatregelen uit artikel 21 die we beschrijven in onze gids over NIS2 Compliance.

• Artikel 21(2)(d) van Richtlijn (EU) 2022/2555: "beveiliging van de toeleveringsketen, met inbegrip van beveiligingsgerelateerde aspecten met betrekking tot de relaties tussen elke entiteit en haar rechtstreekse leveranciers of dienstverleners".
• Artikel 21(3): entiteiten moeten rekening houden met "de kwetsbaarheden die specifiek zijn voor elke rechtstreekse leverancier en dienstverlener en met de algehele kwaliteit van de producten en de cyberbeveiligingspraktijken van hun leveranciers en dienstverleners, met inbegrip van hun veilige ontwikkelingsprocedures", en met de resultaten van de gecoördineerde EU-risicobeoordelingen van kritieke toeleveringsketens uit artikel 22(1).
• Uitvoeringsverordening (EU) 2024/2690 stelt gedetailleerde technische eisen aan digitale aanbieders, zoals aanbieders van cloud, datacenters, managed services en managed security services. Volgens de technische uitvoeringsrichtlijn van ENISA (juni 2025) horen daar een beleid voor ketenbeveiliging en een register van leveranciers en dienstverleners bij. Lees de verordening op EUR-Lex.

Het bestuur draagt de verantwoordelijkheid. Onder artikel 20 keurt het bestuur de maatregelen voor risicobeheer goed, ziet het toe op de uitvoering en kan het aansprakelijk worden gesteld. Onder artikel 34 liggen de maximale boetes voor het schenden van artikel 21 op ten minste € 10 miljoen of 2% van de wereldwijde omzet voor essentiële entiteiten, en op € 7 miljoen of 1,4% voor belangrijke entiteiten. Zie de tien maatregelen uit artikel 21 en of je binnen de scope valt.

Waarom zijn aanvallen via de toeleveringsketen zo moeilijk te stoppen?

Omdat de kwaadaardige code binnenkomt via een kanaal dat je vertrouwt: een ondertekende update, een beheeragent of een softwarepakket. Je beveiligingsmaatregelen zijn gebouwd om die door te laten.

Je monitoringagent installeert op elke server zijn gebruikelijke, ondertekende nachtelijke update. Deze keer bevat die code die een remote shell opent. Niets lijkt mis totdat bestanden beginnen te veranderen.

• Kaseya VSA, juli 2021. Aanvallers gebruikten zero-day-kwetsbaarheden in de software van Kaseya voor beheer op afstand om REvil-ransomware te verspreiden. Kaseya meldde dat ongeveer 50 directe klanten waren getroffen en 800 tot 1.500 bedrijven verderop in de keten (BleepingComputer).
• npm "Shai-Hulud", september 2025. Een zichzelf kopiërende worm besmette meer dan 500 npm-pakketten en verzamelde tokens van ontwikkelaars en API-sleutels voor de cloud. CISA adviseerde afhankelijkheden te controleren, pakketten vast te zetten op versies van vóór 16 september 2025 en alle inloggegevens van ontwikkelaars te vervangen.

De cijfers lopen op. Volgens het Verizon 2025 Data Breach Investigations Report verdubbelde het aandeel datalekken waarbij derden betrokken waren tot 30%. De Verizon 2026 DBIR, samengevat door Help Net Security, meldt dat derden nu bij 48% van de datalekken een rol spelen.

Hoe beoordeel en beheer je leveranciers onder NIS2?

Begin met een register van elke leverancier die bij je netwerk en informatiesystemen kan. Rangschik ze op kritiekheid en steek de meeste energie in de paar die je diensten kunnen stilleggen of in gevaar brengen.

1. Bouw het register. Noteer leveranciers, de diensten en systemen die ze ondersteunen, de toegang die ze hebben (beheeragenten, VPN, API-sleutels) en waar je data staat.
2. Rangschik op kritiekheid. Vraag je af wat er gebeurt als deze leverancier wordt gecompromitteerd of een week niet beschikbaar is.
3. Beoordeel kritieke leveranciers. Vraag om certificeringen zoals ISO 27001, hun omgang met kwetsbaarheden en hun veilige ontwikkelproces, hun incidentgeschiedenis en hoe ze hun eigen beheertoegang beschermen.
4. Stel contracteisen. Melding van incidenten aan jou binnen een vaste termijn, recht op audits of bewijs, locatie van de data, regels voor onderaannemers en een exitplan.
5. Monitor en evalueer op vaste momenten en na elk significant incident, bij de leverancier of in de bredere markt.

Let op concentratierisico: staan back-ups, identiteit en e-mail bij één aanbieder, dan raakt één incident alles. In het model van gedeelde verantwoordelijkheid van Microsoft 365 zie je waar de taken van een aanbieder ophouden.

Wat hoort in een draaiboek voor incidenten in de toeleveringsketen?

Een draaiboek maakt van een compromittering bij een leverancier een procedure in plaats van improvisatie. Het bestaat uit zes onderdelen, opgeschreven en afgestemd voordat je ze nodig hebt.

1. Afhankelijkhedenkaart. Per kritieke leverancier: welke agenten, accounts en koppelingen die heeft, en op welke systemen.
2. Isolatiestappen per leverancier. Hoe je de agent uitschakelt, de inloggegevens intrekt en de netwerkpaden blokkeert, en wat er voor het bedrijf stukgaat als je dat doet.
3. Beslisrechten. Wie mag om 02.00 uur een leverancier afsluiten zonder op een vergadering te wachten.
4. Een onafhankelijke herstelroute. Back-ups en herstelsoftware die de gecompromitteerde leverancier niet kan bereiken, met bekende hersteldoelen per systeem.
5. Communicatiesjablonen. Interne escalatie, berichten aan klanten en de vroegtijdige waarschuwing binnen 24 uur en de melding binnen 72 uur volgens NIS2-artikel 23.
6. Testschema. Minstens één keer per jaar een tabletop-oefening (het scenario aan tafel doorlopen) per kritieke leverancier, waarbij je meet hoe lang isolatie en herstel echt duren.

Herstel is het onderdeel dat de meeste draaiboeken overslaan. Kwam de aanvaller binnen via je beheertooling, ga er dan van uit dat hij alles kon zien en mogelijk verwijderen wat die tooling kon bereiken.

Hoe werken detectie, isolatie en herstel samen?

Elke laag vangt op wat de vorige miste. Detectie ziet dat een vertrouwd proces zich slecht gedraagt, isolatie beperkt de verspreiding en herstel brengt je terug als de eerste twee te laat waren.

Voor MSP's levert het EDR Platform van Mindtime Security de detectietooling: kwetsbaarheidsbeheer, malwaredetectie, CIS-configuratiecompliance, bewaking van bestandsintegriteit, threat hunting, MITRE ATT&CK-mapping en geautomatiseerde reactie op basis van regels die de MSP zelf instelt. Mindtime levert het platform. De MSP draait de dienst en reageert.

Zie ook: als MFA faalt, is back-up de laatste verdedigingslinie.

Wat betekent NIS2-ketenbeveiliging voor MSP's?

MSP's zitten aan beide kanten. Ze zijn zelf een entiteit, vermeld in bijlage I van NIS2 onder beheer van ICT-diensten, en ze zijn de kritieke leverancier die hun klanten moeten beoordelen.

• Als entiteit: een MSP die binnen de scope valt, moet voldoen aan artikel 21. Dat omvat ketenbeveiliging voor de eigen leveranciers, zoals RMM-, PSA-, EDR- en back-upplatforms, en de gedetailleerde eisen van Uitvoeringsverordening (EU) 2024/2690.
• Als leverancier: klanten vragen om certificeringen, voorwaarden voor incidentmelding, bewijs van MFA op beheertoegang en bewijs dat hun data onafhankelijk kan worden hersteld.
• Als doelwit: één gecompromitteerd beheerplatform kan alle klanten tegelijk bereiken, zoals Kaseya liet zien.

In Nederland geldt de Cyberbeveiligingswet (Cbw) vanaf 15 augustus 2026. Volgens het NCSC vallen ongeveer 8.000 organisaties in 18 sectoren eronder. Veel van hen leggen deze vragen voor aan hun IT-leveranciers. Zie ook onveranderbare back-up voor MSP's.

Wat je nu kunt doen

Ketenbeveiliging onder NIS2 komt neer op drie dingen: ken je leveranciers en hun toegang, stel eisen aan de kritieke leveranciers en controleer ze, en houd een herstelroute aan die van geen van hen afhangt. Schrijf het draaiboek nu en test het jaarlijks per kritieke leverancier.

Als leverancier is Mindtime ISO 27001- en NEN 7510-gecertificeerd en sluit het bij elk contract een verwerkersovereenkomst volgens de AVG. Back-ups staan alleen in onze eigen Tier III-datacenters in Nederland en Duitsland, onafhankelijk van Amerikaanse hyperscalers (grote cloudaanbieders), als onveranderbare kopieën (Object Lock) plus een air-gapped kopie. Voor beheeracties is MFA nodig en data is tijdens transport met AES-256 versleuteld. Mindtime dekt de laag van back-up en disaster recovery. In onze gids over NIS2 Compliance lees je hoe dat past bij artikel 21.

Wil je de herstelroute in je toeleveringsketen laten controleren? Vraag een gratis assessment aan. MSP's kunnen ook ons partnerprogramma bekijken.

Dit artikel is algemene informatie, geen juridisch advies.