Een klantvraag over NIS2 is niet hetzelfde als een wettelijke aanwijzing dat jouw organisatie onder de Cyberbeveiligingswet valt. Eerst moet duidelijk zijn welke positie je zelf onder de wet hebt en welk ketenrisico de klant via jouw dienstverlening wil beheersen.
De term NIS2 voor leveranciers wordt vaak gebruikt voor deze indirecte impact via de klantrelatie.
Waarom stelt een NIS2-organisatie eisen aan haar leveranciers?
Een organisatie haalt een deel van haar digitale risico's binnen via andere partijen. IT-beheer, software, SaaS, cloud, hosting en netwerkcomponenten zijn duidelijke voorbeelden. Hetzelfde geldt voor een leverancier die gegevens verwerkt, toegang heeft tot systemen of een proces ondersteunt dat niet lang mag uitvallen.
De zorgplicht van de Cyberbeveiligingswet verlangt van de organisatie dat zij ook de beveiliging van haar toeleveringsketen risicogestuurd behandelt. Artikel 21 van de Europese NIS2-richtlijn noemt daarbij expliciet de beveiligingsaspecten van relaties met rechtstreekse leveranciers en dienstverleners.
De praktische kernvraag voor je klant is: welk risico vertegenwoordigt deze leverancier voor onze bedrijfsvoering en kunnen we onderbouwen dat dit risico voldoende wordt beheerst?
Daarom verschijnen cybersecurity-eisen in leveranciersbeleid, inkoopvoorwaarden, contracten, assessments, auditafspraken en beveiligingsvragenlijsten. De eisen komen dan via de zakelijke relatie bij je terecht.
Word je als leverancier daardoor zelf NIS2-plichtig?
Nee, niet automatisch.
Of de Cyberbeveiligingswet rechtstreeks op jouw organisatie van toepassing is, volgt uit de criteria van de wet. De wettelijke positie van je klant verandert die beoordeling niet. Een klant kan intussen wel passende beveiliging en aantoonbaarheid verlangen wanneer jouw dienstverlening een relevant risico vormt.
| Situatie | Wat betekent dit? |
|---|---|
| Je organisatie valt zelf onder de Cyberbeveiligingswet | De wettelijke verplichtingen gelden rechtstreeks voor je organisatie. |
| Je valt niet onder de wet, maar levert een relevante dienst aan een Cbw-organisatie | De klant kan beveiligings- en bewijseisen stellen die passen bij het ketenrisico en de contractuele relatie. |
| Je levering veroorzaakt nauwelijks digitaal of fysiek risico voor de beschermde systemen | De noodzakelijke eisen zullen doorgaans beperkter zijn. De klant hoort dit op basis van risico te beoordelen. |
De formulering “jullie moeten NIS2-compliant zijn” is dus vaak te grof. Vraag welke risico's de klant ziet, welke uitkomst nodig is en welk bewijs daarvoor wordt verwacht.
Twijfel je over je eigen wettelijke positie? Een NIS2 Quickscan helpt om de toepasselijkheid eerst apart vast te stellen.
Welke leveranciers krijgen hiermee vooral te maken?
Het risico verschilt per levering. Een leverancier van kantoorartikelen heeft normaal gesproken een andere invloed op netwerk- en informatiesystemen dan de IT-partij die met beheerdersrechten in Microsoft 365 werkt.
Aanvullende eisen liggen vooral voor de hand bij leveranciers die:
- toegang hebben tot systemen of digitale omgevingen;
- beheerrechten of andere verhoogde bevoegdheden gebruiken;
- persoonsgegevens of andere gevoelige informatie verwerken;
- software, SaaS-, cloud- of hostingdiensten leveren;
- ICT-componenten leveren die onderdeel zijn van belangrijke systemen;
- een belangrijk bedrijfsproces ondersteunen;
- grote invloed hebben op beschikbaarheid, herstel of continuïteit.
Ook omvang is niet de enige maatstaf. Een kleine specialist met vergaande toegang kan een groter ketenrisico vormen dan een veel grotere leverancier zonder toegang tot kritieke processen of gegevens.
Welke eisen kan een klant stellen?
De precieze set hoort aan te sluiten op de dienst, de afhankelijkheid en mogelijke gevolgen van een incident. Een vragenlijst is bruikbaar als startpunt, zolang de beoordeling niet ontaardt in dezelfde standaardlijst voor iedere leverancier.
Informatiebeveiligingsbeleid en verantwoordelijkheid
De klant kan willen weten hoe informatiebeveiliging is georganiseerd, wie beslissingen neemt en wie aanspreekbaar is wanneer een maatregel ontbreekt of een incident ontstaat.
Risicoanalyse
Je moet kunnen uitleggen welke risico's relevant zijn voor de geleverde dienst en waarom gekozen maatregelen daarbij passen. Een risicoanalyse informatiebeveiliging verbindt techniek, processen en bedrijfsgevolgen.
Toegangsbeheer
Vragen gaan vaak over multifactorauthenticatie (MFA), autorisaties, beheerdersaccounts, periodieke controles en het tijdig intrekken van rechten. Bij externe beheerrechten wil een klant ook weten hoe gebruik wordt gelogd en beoordeeld.
Kwetsbaarheden en updates
De leverancier kan moeten beschrijven hoe beveiligingsupdates worden gevolgd, getest en uitgevoerd, hoe kwetsbaarheden worden geregistreerd en wanneer ernstige bevindingen worden opgelost of gemeld.
Incidentmanagement en melding
Een klant wil vooraf weten hoe incidenten worden ontdekt en behandeld, via welk contactpunt wordt opgeschaald en binnen welke afgesproken termijn relevante informatie beschikbaar komt. Die contractuele meldafspraak moet passen bij de informatie die de klant nodig heeft voor zijn eigen incidentrespons en mogelijke wettelijke meldplicht.
Back-up, herstel en continuïteit
Een back-upbeleid zegt weinig over het feitelijke herstelvermogen. Daarom kan de klant hersteltests, uitwijkafspraken, hersteldoelen en resultaten van oefeningen opvragen, zeker wanneer zijn bedrijfsvoering sterk van de dienst afhankelijk is.
Medewerkers en veilig gedrag
Voor mensen met klanttoegang of beheerrechten kunnen opleiding, phishingweerbaarheid, geheimhouding, screening en zorgvuldig accountgebruik relevant zijn. Ook hier bepaalt het risico welke diepgang redelijk is.
Eigen leveranciers
Veel diensten steunen op cloudpartijen, onderaannemers en softwareleveranciers. Je klant kan vragen welke partijen je inzet, welke gegevens zij verwerken, hoe wijzigingen worden beheerst en wat er gebeurt bij uitval van een kritieke onderleverancier.
Wat betekent aantoonbaarheid voor een leverancier?
Aantoonbaarheid betekent dat je met passend bewijs kunt laten zien dat belangrijke beveiligingsmaatregelen zijn ingericht en uitgevoerd. Alleen zeggen “ja, dat hebben we geregeld” geeft een klant weinig zekerheid.
Bewijs kan bestaan uit beleid, registraties, rapportages, testresultaten, hersteltests, auditrapportages, pentest- of kwetsbaarhedenrapportages, incidentoefeningen, periodieke reviews en relevante certificeringen. Niet ieder bewijsstuk hoeft integraal te worden gedeeld. Gevoelige rapporten kunnen soms via een managementsamenvatting, assuranceverklaring of gecontroleerde inzage worden beoordeeld.
De vraag verschuift van alleen maatregelen nemen naar ook kunnen laten zien dat belangrijke maatregelen daadwerkelijk werken.
Dat sluit aan op opzet, bestaan en werking: een afspraak op papier, een feitelijk ingevoerde maatregel en aantoonbare werking zijn verschillende niveaus van zekerheid.
Is ISO 27001 verplicht voor een leverancier?
Nee. Een leverancier hoeft op grond van de Cyberbeveiligingswet niet automatisch ISO 27001-gecertificeerd te zijn.
ISO 27001 en een ISMS kunnen wel structuur geven aan risicomanagement, verantwoordelijkheden, maatregelen en bewijs. Dat maakt beantwoording van vragen van meerdere klanten vaak eenvoudiger. Een specifieke opdrachtgever kan certificering daarnaast contractueel verlangen.
Controleer in dat geval of de scope van het certificaat werkelijk aansluit op de dienst, systemen en locaties die voor de klant van belang zijn. Een certificaat is geen doel op zichzelf en dekt niet zonder verdere beoordeling ieder ketenrisico af.
Wat als je de leveranciersvragenlijst niet goed kunt beantwoorden?
Een ontbrekend antwoord leidt niet automatisch tot één vaste uitkomst. De klant kan aanvullende vragen stellen, gerichte maatregelen verlangen, een securityassessment of audit uitvoeren en afspraken opnemen in het contract. Ook kan het leveranciersrisico intern worden geëscaleerd.
Blijft een belangrijk risico onvoldoende beheerst of te onzeker, dan kan de klant besluiten de dienstverlening anders in te richten of een andere leverancier te kiezen. Informatiebeveiliging wordt daarmee onderdeel van leveranciersselectie en zakelijk vertrouwen.
Wees precies over wat al werkt, wat nog ontbreekt en wanneer een verbetering gereed kan zijn. Een eerlijk verbeterplan met eigenaarschap en bewijs is bruikbaarder dan een algemeen positief antwoord dat later niet houdbaar blijkt.
Wat kan je als leverancier nu al doen?
- Bepaal eerst of de Cyberbeveiligingswet rechtstreeks geldt. Maak onderscheid tussen je eigen wettelijke positie en eisen die via klanten binnenkomen.
- Kijk naar je klanten en diensten. Welke klanten kunnen onder de Cbw vallen, welke toegang heb je en hoe afhankelijk zijn zij van jouw dienstverlening?
- Breng je eigen risico's in beeld. Begin bij processen, gegevens, systemen, mensen en externe afhankelijkheden die voor de levering belangrijk zijn.
- Controleer of belangrijke maatregelen werken. Kijk naast beleid naar technische inrichting, uitvoering, tests, afwijkingen en opvolging.
- Organiseer de aantoonbaarheid. Maak documentatie, verantwoordelijkheden, testresultaten en procedures vindbaar en actueel.
Bouw een herbruikbaar leveranciers- of assurancedossier op. Neem daarin een korte beschrijving van de dienst, de belangrijkste risico's, kernmaatregelen, contactpersonen, relevante rapportages en geldigheidsdata op. Zo begint niet bij iedere klant opnieuw dezelfde zoektocht.
Wil je de eisen van een klant systematisch naast je bestaande inrichting leggen, bekijk dan de NIS2 GAP-analyse. Het bestaande artikel over NIS2 supply chain en ketenverantwoordelijkheid legt de andere kant van de relatie uit: hoe een Cbw-organisatie haar leveranciersrisico bestuurlijk beheerst.
Kan je deze vragen van een klant beantwoorden?
- Weten we of de Cyberbeveiligingswet rechtstreeks op ons van toepassing is?
- Kennen we onze belangrijkste cyberrisico's?
- Zijn verantwoordelijkheden voor informatiebeveiliging vastgelegd?
- Gebruiken we MFA waar dat nodig is?
- Beheren en controleren we toegang en beheerdersrechten?
- Worden systemen en software tijdig bijgewerkt?
- Hebben we een werkbare incidentprocedure?
- Weten we wanneer en hoe een klant bij een incident wordt geïnformeerd?
- Maken en testen we back-ups van de relevante systemen en gegevens?
- Kennen we onze kritieke leveranciers en onderaannemers?
- Besteden we gericht aandacht aan medewerkers en veilig gedrag?
- Kunnen we aantonen dat belangrijke maatregelen worden uitgevoerd en beoordeeld?
Passende vervolgstap
Wil je weten wat je werkelijk moet kunnen aantonen?
Stel eerst vast of de Cyberbeveiligingswet rechtstreeks geldt, welke eisen klanten aan de dienstverlening stellen, welke risico's relevant zijn en welke bestaande maatregelen al aantoonbaar werken. Een risicoanalyse maakt die samenhang concreet zonder automatisch een volledig normenkader op iedere leverancier te leggen.
Bekijk de risicoanalyse informatiebeveiliging →