Terug naar kennisbank

Hoe beantwoord je een NIS2-leveranciersvragenlijst? Een praktische gids voor het MKB

Gepubliceerd op 12 juni 2026 · Bijgewerkt op 21 juli 2026

Dit artikel is algemene informatie over wet- en regelgeving en geen juridisch advies.

Het begint vaak met een e-mail van de inkoopafdeling van een grote klant. Onderwerp: "Vendor Security Assessment" of "Uitvraag informatiebeveiliging leveranciers". In de bijlage: een uitgebreide vragenlijst over jouw cyberbeveiliging, met het vriendelijke maar dringende verzoek die ingevuld te retourneren — met een deadline van enkele weken.

Die vragenlijst is geen wantrouwen en geen formaliteit. Je klant valt onder NIS2 en moet de risico's in zijn toeleveringsketen beoordelen: de ketenzorgplicht die wij eerder beschreven. In Nederland wordt die verplichting op 15 augustus 2026 afdwingbaar via de Cyberbeveiligingswet (nieuwsbericht Rijksoverheid, 7 juli 2026); grote organisaties richten hun leveranciersbeoordeling hier naar verwachting op in. Jouw antwoorden bepalen mede of je klant zijn eigen compliance kan aantonen. En dus, heel praktisch: of jij die klant houdt. Twijfel je wat NIS2 nu écht van je eist, en wat juist een mythe is? Lees dan eerst wat is écht verplicht onder de NIS2-ketenzorgplicht.

Deze gids behandelt vier thema's die rechtstreeks volgen uit de NIS2-maatregelen van artikel 21 lid 2 — patchmanagement en kwetsbaarhedenbeheer, toegangsbeveiliging met MFA, incidentafhandeling en de toeleveringsketen — en, belangrijker, hoe je een antwoord geeft dat de beoordelaar bij je klant — inkoop, security of een auditor — serieus neemt.

Waarom jouw grote klanten deze vragen (moeten) stellen

NIS2 verplicht essentiële en belangrijke entiteiten om de beveiligingsrisico's van hun directe leveranciers te beoordelen en daar passende eisen aan te stellen — dat volgt uit artikel 21 lid 2 sub d, de bepaling over de beveiliging van de toeleveringsketen waar leveranciersvragenlijsten vaak naar verwijzen, gelezen met lid 3, dat entiteiten verplicht rekening te houden met de kwetsbaarheden van elke directe leverancier. De redenering is simpel: een aanvaller die niet door de voordeur van het ziekenhuis of de netbeheerder komt, probeert het via een leverancier. De toezichthouder kijkt daarom niet alleen naar de organisatie zelf, maar ook naar hoe zij haar keten beheerst. Wat die zorgplicht precies inhoudt, lees je op NIS2-ketenzorgplicht.

Voor jou als leverancier betekent dat twee dingen. Ten eerste: reken op een terugkerende cyclus — vaak jaarlijks — en bij nieuwe contracten kan de uitvraag meteen onderdeel van de afspraken zijn; de frequentie verschilt per klant. Ten tweede: je antwoorden worden onderdeel van het compliance-dossier van je klant. Een vaag antwoord ("wij nemen beveiliging serieus") is voor de auditor van je klant onbruikbaar en nodigt uit tot doorvragen. Een concreet, onderbouwd antwoord maakt jou juist een leverancier waarmee inkoop graag verlengt.

Aan de inkoopkant is de boodschap inmiddels expliciet: een ingevulde vragenlijst alleen volstaat niet — het is papier, een momentopname. Het NCSC adviseert inkopende organisaties dan ook om antwoorden na te vragen en met eigen onderzoek te verifiëren. Wie als leverancier zelf een externe meting meestuurt, geeft de auditor wat de vragenlijst niet kan geven — een onafhankelijke waarneming in plaats van een zelfverklaring.

Moet je antwoorden — en wat als je het niet doet?

Strikt juridisch gezien niet: NIS2 — in Nederland de Cyberbeveiligingswet — legt de verplichting van artikel 21 lid 2 sub d bij je klant, niet rechtstreeks bij jou. Jouw plicht om te antwoorden ontstaat via het contract en het inkoopbeleid van die klant.

Praktisch ligt het anders. Een klant die geen of vage antwoorden krijgt, kan weinig anders dan je als verhoogd risico inschalen — met mogelijke gevolgen bij contractverlenging en nieuwe tenders.

Tactisch is er ruimte: uitstel of verduidelijking vragen mag. Een goed onderbouwd antwoord twee weken later is meer waard dan een leeg formulier op tijd.

De 4 thema's in een Vendor Security Assessment die rechtstreeks uit de NIS2-eisen volgen

1. Hoe is uw patchmanagement en kwetsbaarhedenbeheer geregeld?

Wat ze echt vragen: weet u welke systemen u aan het internet heeft hangen, hoe snel dicht u bekende kwetsbaarheden, en kunt u dat aantonen?

Zwak antwoord: "Updates worden regelmatig geïnstalleerd."

Sterk antwoord: beschrijf je proces in drie zinnen en voeg bewijs toe. Bijvoorbeeld: "Onze externe systemen worden maandelijks gescand op kwetsbaarheden. Kritieke bevindingen herstellen we binnen 14 dagen, overige binnen 30 dagen. Bijgevoegd: de scanrapportage van afgelopen maand met herstelstatus." (termijnen ter illustratie) Een gedateerde rapportage van een onafhankelijke scan zegt meer dan een pagina proza. Begin met te begrijpen wat een aanvaller van jouw domein ziet. Dat is exact dezelfde buitenkant die de auditor van je klant beoordeelt.

2. Maakt u gebruik van Multi-Factor Authentication (MFA) op alle systemen?

Wat ze echt vragen: kan een gestolen of gelekt wachtwoord van een van uw medewerkers leiden tot toegang tot systemen, en daarmee mogelijk tot onze gegevens?

Sterk antwoord: wees specifiek over waar MFA wél en niet aanstaat. "MFA is verplicht op e-mail, VPN, ons administratiesysteem en alle beheerinterfaces. Voor [systeem X] is MFA nog niet beschikbaar; dit systeem is alleen bereikbaar vanaf kantoor-IP's." Eerlijkheid over een uitzondering, mét compenserende maatregel, komt geloofwaardiger over dan een ongeclausuleerd "ja, overal". Een ervaren auditor zal doorvragen.

3. Wat is uw procedure bij een datalek of ransomware-aanval?

Wat ze echt vragen: als u geraakt wordt, hoe snel weten wíj dat dan? NIS2-organisaties hebben zelf strakke meldtermijnen — een vroegtijdige waarschuwing binnen 24 uur en een incidentmelding binnen 72 uur (artikel 23 van de NIS2-richtlijn) — en kunnen die bij een incident in de keten alleen halen als hun leveranciers snel melden.

Sterk antwoord: noem je interne responsplan, maar vooral de afspraak richting de klant: "Bij een incident dat uw gegevens of dienstverlening kan raken, informeren wij uw aangewezen contactpersoon binnen 24 uur via [kanaal]. Ons incidentresponsplan is op verzoek in te zien; we oefenen het jaarlijks." Als je nog geen responsplan hebt: het NCSC (waarin het Digital Trust Center begin 2026 is opgegaan) publiceert een gratis stappenplan voor een incidentresponsplan dat voor het MKB goed bruikbaar is.

4. Hoe controleert u de veiligheid van uw eigen (sub)leveranciers?

Wat ze echt vragen: de keten stopt niet bij u. Uw hostingpartij, uw softwareleveranciers en uw IT-beheerder zijn voor onze risicoanalyse net zo relevant.

Sterk antwoord: maak een simpele lijst van je kritieke leveranciers (hosting, e-mail, boekhoudsoftware, IT-beheer) en beschrijf per leverancier hoe je de veiligheid borgt: certificeringen (ISO 27001, SOC 2), verwerkersovereenkomsten, of je eigen periodieke controle. Je hoeft geen audits uit te voeren bij Microsoft: verwijzen naar hun certificeringen is in de praktijk een gebruikelijke aanpak.

Naast deze vier thema's kun je vragen verwachten over back-ups en herstel, encryptie, toegangsbeheer en offboarding, security-awareness, certificeringen, cyberverzekering en bedrijfscontinuïteit. Bouw daarom een herbruikbaar basisdossier op met je standaardantwoorden en bewijsstukken, zodat de volgende vragenlijst geen nieuw project is. Ben je zelf ISO 27001-gecertificeerd, dan is je certificaat het startpunt en dient het bovenstaande als aanvullend, actueel bewijs.

Hoe geef je een antwoord dat de beoordelaar van je klant serieus neemt?

Drie principes maken het verschil tussen een vragenlijst die rondzingt tussen afdelingen en een vragenlijst die in één keer wordt geaccepteerd:

Let op: je antwoorden kunnen als bijlage bij het contract worden gevoegd en daarmee contractuele werking krijgen. Neem dus alleen termijnen op die je intern aantoonbaar haalt, en niet de voorbeeldtermijnen uit dit artikel als die niet bij jouw organisatie passen.

Het patroon achter alle vier de vragen is steeds hetzelfde: aantonen, niet beweren. En precies daarom loont het om de bewijslast niet per vragenlijst bij elkaar te zoeken, maar structureel op te bouwen. Wie maandelijks een gedateerde, onafhankelijke rapportage van zijn externe aanvalsoppervlak ontvangt, beantwoordt vraag 1 voortaan met één bijlage, en heeft voor vraag 2 ondersteunend bewijs dat er op de scandatum geen beheerinterfaces open aan het internet zijn aangetroffen — het MFA-beleid zelf blijft je eigen documentatie.

Conclusie

Een NIS2-leveranciersvragenlijst is geen examen waarvoor je kunt zakken, maar een kans om je te onderscheiden. Wie concrete processen beschrijft en gedateerd bewijs meelevert, valt positief op bij je klant.

Exposentry levert dat bewijs als dienst: maandelijkse, onafhankelijke scanrapportages van je domein en infrastructuur die je rechtstreeks als bijlage bij de vragenlijst voegt. Geen compliance-stempel, wel verdedigbaar bewijs van je basishygiëne. De rapportages zijn gebouwd op OpenKAT, de open-source securityscanner die uit de Nederlandse overheid voortkomt en waaraan Edward Hasekamp bijdraagt — de auditor van je klant kan dus nazien hoe de meting tot stand komt. Bekijk de pakketten en tarieven of start vandaag met een eerste scan, zodat je het rapport al hebt liggen vóór de volgende vragenlijst binnenkomt.

Krijg jij als grote organisatie juist vragenlijsten van leveranciers terug die je wilt verifiëren? Bekijk dan leveranciersmonitoring.

Geschreven door Edward Hasekamp, oprichter van Exposentry en core-maintainer van het open-source OpenKAT-project. Zie het project op GitHub en het profiel op github.com/hasecon. Exposentry levert EU-soevereine, forensisch onderbouwde vulnerability monitoring op basis van OpenKAT. Meer artikelen in de Kennisbank.