Gehackt via je leverancier: wat je vraagt, wat NIS2 eist en wat je laat testen

TL;DR

• Drie recente incidenten in België en Nederland begonnen bij een leverancier van het slachtoffer.
• NIS2 zet de beveiliging van je toeleveringsketen op jouw lijst. Je leverancier draagt die plicht niet in jouw plaats.
• De juiste vragen aan een leverancier helpen. De toegang en de koppelingen aan jouw kant kun je zelf laten testen.
• Begin met een lijst: wie heeft toegang, langs welke weg, en hoe zet je die dicht als het misloopt.

Eind oktober kregen inwoners van een aantal Belgische gemeenten een waarschuwing voor phishing. De gemeenten zelf waren niet gehackt. Een module van hun softwareleverancier wel. Dat patroon kwam dit jaar vaker terug: de aanvaller gaat langs de partij die al binnen mag. Dit stuk legt uit langs welke wegen dat gebeurt, wat NIS2 ervan vraagt en welk deel je zelf laat testen. Dat laatste is meestal een netwerk pentest op de toegang van je leveranciers, of een API pentest op de koppelingen tussen jouw systemen en die van hen.

Drie incidenten, een patroon

Een handtekeningmodule bij lokale besturen

Op 27 oktober 2026 meldde Vanden Broele dat een hacker op 22 en 23 oktober toegang had tot eSignFlow. Met die module laten lokale besturen documenten digitaal ondertekenen, onder meer binnen de pakketten van C-Smart en Cipal. Buitgemaakt werden vooral metadata: de naam van wie tekende, soms met de titel van het document. Vanden Broele meldde het incident bij het Centrum voor Cybersecurity België en de Gegevensbeschermingsautoriteit, sloot de toegang en verving alle sleutels en koppelingen.

Een naam en een documenttitel klinken onschuldig. Voor een phishingmail zijn ze precies wat een bericht geloofwaardig maakt. 'Je document wacht nog op je handtekening' werkt het best als het klopt.

Een beheerplatform voor diensttelefoons

In juni 2026 werd de Belgische Staatsveiligheid getroffen via Ivanti Endpoint Manager Mobile, het platform waarmee diensttelefoons beheerd worden. Volgens de berichtgeving draaide die software bij een externe partner. Namen, telefoonnummers en mailadressen van medewerkers werden buitgemaakt.

Een patiëntendossier en de VPN die dicht moest

In april 2026 werd ChipSoft getroffen door ransomware. Naar schatting 70 tot 75 procent van de Nederlandse ziekenhuizen draait op software van dat bedrijf. Verschillende ziekenhuizen verbraken hun VPN-verbindingen met de systemen van ChipSoft, zodat de aanval zich niet naar hun eigen netwerk kon verspreiden. Minstens elf ziekenhuizen haalden op advies van Z-CERT en het NCSC hun patiëntenportaal offline.

Dat detail is het belangrijkste van de drie verhalen. Die ziekenhuizen wisten welke koppeling er lag en konden ze dichtzetten. Dat is minder vanzelfsprekend dan het klinkt.

Vier manieren waarop een leverancier je ingang wordt

Software die bij jou draait of jouw gegevens bewaart

Een pakket op je eigen servers, of een SaaS-dienst die jouw gegevens bewaart. Wordt de leverancier geraakt, dan zit het lek in software die je niet zelf patcht en soms niet eens ziet draaien.

Beheertoegang op afstand

Je IT-partner beheert je omgeving via een RMM-tool, een VPN of een eigen beheeraccount. Dat is normaal en vaak nodig. Het betekent wel dat één gekaapt account bij die partner een sleutel tot jouw netwerk is. Kijk daarom hoe dat account ingericht is: met MFA, met alleen de rechten die nodig zijn, en weg zodra de samenwerking stopt.

Koppelingen en API-sleutels

Je boekhouding praat met je bank, je CRM met je mailplatform, je webshop met je logistieke partner. Elke koppeling draait op een sleutel of token. Heeft die sleutel te ruime rechten, of is hij nooit vervangen, dan is wie hem bemachtigt binnen zonder ooit in te loggen. Vanden Broele verving na het incident niet voor niets alle sleutels en koppelingen.

Gegevens die bij de leverancier liggen

Soms is er geen toegang tot je netwerk nodig. Gegevens over jouw organisatie bij een leverancier volstaan om een overtuigende phishingmail te bouwen. Het incident met eSignFlow is daar een schoolvoorbeeld van: geen wachtwoorden, wel context.

Wat NIS2 hierover echt vraagt

NIS2 noemt de beveiliging van de toeleveringsketen uitdrukkelijk als een van de maatregelen die je moet nemen (artikel 21, lid 2, punt d). Het gaat om de beveiligingsaspecten van de relatie met je directe leveranciers en dienstverleners. Lid 3 voegt toe dat je daarbij rekening houdt met de specifieke kwetsbaarheden van elke leverancier en met de kwaliteit van hun producten en beveiligingspraktijken, ook van hoe veilig ze ontwikkelen.

Twee dingen vallen op. De plicht ligt bij jou, de organisatie die onder NIS2 valt. En het gaat om je directe leveranciers, niet om de leverancier van je leverancier.

In België werkt het CCB dit uit met het raamwerk CyberFundamentals, in Nederland heet de uitwerking de Cyberbeveiligingswet. Wat een inspectie per sector precies vraagt, verschilt en is nog in beweging. Wat je wel kunt aantonen: dat je weet wie toegang heeft, dat je ernaar gevraagd hebt en dat je getest hebt wat aan jouw kant ligt. Hoe dat bewijs eruitziet, lees je in onze NIS2 pentest checklist.

Vragen die je een leverancier stelt

Een vragenlijst van veertig pagina's levert vooral een ingevulde vragenlijst op. Vier vragen zeggen meer:

• Wie van jullie heeft toegang tot onze omgeving, langs welke weg, en met MFA?
• Hoe snel horen wij het bij een incident, en van wie?
• Wanneer is jullie product of platform voor het laatst getest, en wat is er daarna opgelost?
• Welke gegevens van ons bewaren jullie, en hoe lang?

Let vooral op hoe concreet het antwoord is. 'We nemen security zeer serieus' is geen antwoord op de eerste vraag.

Wat je zelf laat testen

De koppeling aan jouw kant

VPN-toegang van leveranciers, beheeraccounts, API-sleutels en de rechten die een koppeling in je omgeving krijgt. Dat is jouw kant van de relatie, en die mag je testen. Een netwerk pentest kijkt naar de toegangen en rechten in je netwerk, een API pentest naar de koppelingen en sleutels tussen systemen.

Wat een aanvaller kan als de leverancier al binnen is

De nuttigste vraag: wat kan iemand met het account van je IT-partner of de sleutel van een koppeling? Hoe ver komt die, wat ziet die, en merk je het? Dat scenario test je met een interne test vanuit de positie van de leverancier, of breder met een red team.

Wat je niet zelf test

Het platform van je leverancier test je niet zonder hun schriftelijke toestemming. Dat geldt zeker voor SaaS-diensten, die op de infrastructuur van de leverancier draaien. Wil je dat portaal toch laten testen, vraag dan eerst die toestemming. Een webapplicatie pentest kan dan, met duidelijke afspraken over scope en testomgeving.

Zo begin je deze week

• Maak een lijst van leveranciers met toegang tot je omgeving of een koppeling met je systemen, met een eigenaar per lijn.
• Noteer per lijn hoe je die toegang dichtzet als het misloopt. Dat moesten de ziekenhuizen bij ChipSoft op korte tijd doen.
• Ruim de toegangen op van leveranciers waarmee je niet meer werkt.
• Zet per leverancier een incidentcontact in je incident response plan.

Conclusie

Je leverancier is meestal geen zwakke partij. Die heeft wel toegang, en toegang is wat een aanvaller zoekt. Werk de lijst daarom samen met je IT-partner uit. Weet wie binnen mag, vraag hoe dat beveiligd is en test wat aan jouw kant ligt. Dan blijft een incident bij een leverancier vervelend, en hoeft het geen inbraak bij jou te worden.

Veelgestelde vragen

Ben ik verantwoordelijk als mijn leverancier gehackt wordt?

Voor het incident bij je leverancier niet. Wel voor wat je zelf moest regelen: wie toegang heeft, hoe die beveiligd is en hoe je reageert. Valt je organisatie onder NIS2, dan hoort de beveiliging van je toeleveringsketen bij je eigen maatregelen.

Wat vraagt NIS2 precies over leveranciers?

Artikel 21 vraagt maatregelen voor de beveiliging van je toeleveringsketen, voor je directe leveranciers en dienstverleners. Je houdt rekening met de kwetsbaarheden per leverancier en met de kwaliteit van hun producten en beveiligingspraktijken. Hoe dat per sector gecontroleerd wordt, verschilt per land.

Mag ik de systemen van mijn leverancier laten pentesten?

Niet zonder hun schriftelijke toestemming. Wat aan jouw kant ligt, zoals VPN-toegang, beheeraccounts en API-sleutels, mag je wel laten testen met een netwerk pentest of een API pentest.

Volstaat een ISO 27001-certificaat van mijn leverancier?

Het is een goed teken: de leverancier heeft een beheersysteem voor informatiebeveiliging. Kijk wel wat binnen de scope van het certificaat valt. Over de toegang die de leverancier tot jouw omgeving heeft, of over de koppeling tussen jullie systemen, zegt het weinig. Die kant blijft van jou.

Wat doe ik als mijn leverancier een datalek meldt?

Vraag welke gegevens en welke toegangen betrokken zijn. Vervang de sleutels en wachtwoorden van koppelingen met die leverancier en waarschuw je mensen voor phishing die op de gelekte gegevens inspeelt. Valt je organisatie onder NIS2 of gaat het om persoonsgegevens, kijk dan na of je zelf een meldplicht hebt.

Hoe vaak herzie ik de toegang van leveranciers?

Minstens een keer per jaar, en altijd wanneer een samenwerking stopt of je van IT-partner wisselt. Een toegang van een leverancier die al lang weg is, staat zelden op iemands lijst.

Geldt dit ook voor mijn eigen IT-partner?

Ja. Je IT-partner heeft vaak de ruimste toegang van allemaal. Dat is geen reden tot wantrouwen, wel een reden om samen af te spreken hoe die toegang beveiligd is en hoe jullie reageren als er iets misloopt.

Gerelateerde diensten en bronnen

Wil je weten hoe ver iemand komt met de toegang van een leverancier, begin dan met een netwerk pentest of, voor koppelingen tussen systemen, een API pentest. Moet je dat bewijs ook voorleggen in een NIS2-traject, dan helpt een auditklare pentest, en onze pagina over NIS2 compliance zet de andere maatregelen op een rij. Wil je het scenario van een leverancier die al binnen is volledig uitspelen, dan is een red team de juiste vorm. Verder lezen: de NIS2 pentest checklist, het incident response plan voor de eerste uren na een incident, externe of interne pentest over welke test eerst komt, en beveiliging van de AI supply chain voor de variant waarin de leverancier een plugin of skill van je AI-agent is.