Compliance by proxy schaalt niet

De Cyberbeveiligingswet trad op 15 augustus 2026 in werking en legt daarmee nieuwe verplichtingen vast voor ruwweg 8.000 organisaties in Nederland (Rijksoverheid, 2026). De adviesmarkt had maanden nodig om zich op deze datum voor te bereiden, en vrijwel al die voorbereiding ging naar één groep: de essentiële en belangrijke entiteiten die nu rechtstreeks onder de nieuwe wet vallen. Consultants zaten volgeboekt om die organisaties te helpen hun zorgplichtmaatregelen in kaart te brengen, zich bij het NCSC te registreren en hun governance op orde te krijgen.

Ga er, voorzichtig geschat, van uit dat elk van die 8.000 organisaties op minstens twintig leveranciers leunt, en het aantal bedrijven dat nu door deze wet met een compliance-vraag wordt geconfronteerd, zonder zelf rechtstreeks gereguleerd te zijn, loopt al ruim voorbij de 100.000.

NFIR merkte nog iets anders op tijdens precies dat advieswerk. Zittend middenin die gesprekken kwam telkens weer dezelfde kloof naar boven: de verplichte organisatie zelf was doorgaans redelijk op orde, vaak al ISO 27001 gecertificeerd of goed op weg, maar haar leveranciers niet. Die leveranciers hadden geen certificaat om naar te wijzen, geen gedeelde manier om hun beveiligingsstatus aan te tonen, en geen idee hoe ze de compliance-vraag moesten beantwoorden die op het punt stond in hun inbox te landen, van meerdere klanten tegelijk.

Bizway zag hetzelfde probleem vanaf de andere kant. Als leverancier had Bizway zelf al een toename gemerkt van precies dit soort verzoeken: klanten die vroegen, soms formeel en soms als bijzaak in een accountreview, hoe Bizway kon aantonen dat het aan de NIS2-gerelateerde verwachtingen voldeed. Twee organisaties, twee gezichtspunten, dezelfde waarneming: de druk van deze wet zou nooit binnen de 8.000 rechtstreeks gereguleerde bedrijven blijven. Die zou altijd een laag lager landen, bij de mensen die aan hen leveren.

Waarom vraagt je klant je opeens om een compliance-verklaring?

Dit is geen toeval, en het is geen overijverig accountmanagement. Artikel 21 van de NIS2-richtlijn verplicht essentiële en belangrijke entiteiten om de beveiliging van hun toeleveringsketen te beheren, inclusief de beveiligingsgerelateerde aspecten van hun relaties met directe leveranciers (ENISA, 2023). In de praktijk kan die verplichting niet binnen de gereguleerde organisatie blijven. Ze moet naar beneden worden doorgegeven, in contracten, onboarding-checklists en, het meest zichtbaar, in een compliance-vraag gericht aan elke leverancier waarvan de organisatie afhankelijk is.

ENISA’s eigen analyse van cybersecurity in de toeleveringsketen, gepubliceerd in 2023 en nog altijd de meest geciteerde EU-referentie over dit mechanisme, stelde vast dat compromitteringen in de keten waren gegroeid van minder dan 1 procent van de inbraken in 2020 naar 17 procent in 2021. In 66 procent van de onderzochte incidenten wist de getroffen leverancier niet hoe hij was gecompromitteerd, of kon hij dat niet transparant uitleggen aan de klant die op hem leunde. Dat is precies de kloof die de Cyberbeveiligingswet moet dichten, en precies waarom een gereguleerde organisatie er nu alle belang bij heeft om haar leveranciers te vragen hun werk te laten zien in plaats van het op vertrouwen aan te nemen.

Is een certificaat niet het voor de hand liggende antwoord?

Het nette antwoord zou zijn dat elke leverancier ISO 27001 gecertificeerd raakt en de kwestie daarmee afsluit. Voor een handvol grotere leveranciers is dat een verstandige route, en sommige doen het al. Voor de meeste is het niet realistisch, en het is misschien ook niet nodig. Een certificaat is duur, kost maanden om te behalen, en is gebouwd voor organisaties van een bepaalde omvang en volwassenheid. Talloze leveranciers die geen noemenswaardig risico vormen voor de NIS2-compliance van hun klanten worden impliciet gevraagd zich te gedragen alsof ze dat wel doen.

Wat die leveranciers werkelijk nodig hebben is geen certificaat. Het is een geloofwaardige, met bewijs onderbouwde manier om de vraag te beantwoorden die hun gesteld wordt, gesteund door iets steviger dan een geruststellende e-mail.

Wat gebeurt er wanneer één leverancier vijftig keer dezelfde vraag krijgt?

Hier stapelt het probleem zich op. Een leverancier heeft zelden één klant die deze vraag stelt; het zijn er meerdere, elk met een net iets ander formulier, een andere deadline en een andere set verwachte antwoorden. ISACA’s brancheanalyse van mei 2026 beschrijft dit rechtstreeks als een verschuiving van vragenlijstmoeheid naar de behoefte aan contextuele, met bewijs onderbouwde zekerheid, en merkt op dat het oude model van ad-hoc, eenmalige vragenlijsten simpelweg niet schaalt zodra elke klant onafhankelijk begint te vragen (ISACA, 2026). Vermenigvuldig dat met het aantal klanten dat een middelgrote leverancier bedient, en de leverancier is uiteindelijk meer tijd kwijt aan het invullen van formulieren dan aan het daadwerkelijk verbeteren van zijn beveiliging.

Dat is geen tekortschieten in de zorgvuldigheid van enige individuele leverancier. Het is een structureel falen van een model dat gebouwd is voor incidentele vragen, en nu continu en gelijktijdig door iedereen tegelijk wordt gesteld.

Zou een maatwerkvragenlijst van elke klant niet grondiger zijn?

Er valt iets te zeggen voor de huidige aanpak. Een klant die zijn eigen vragenlijst opstelt kan die precies afstemmen op het risico dat de leverancier voor hem vertegenwoordigt: een leverancier die met gevoelige data werkt krijgt andere vragen dan een leverancier die kantoormeubilair levert met een internetverbonden badgelezer. Maatwerkvragenlijsten houden eigenaarschap en verantwoordelijkheid ook precies daar waar NIS2 die legt, bij de gereguleerde organisatie zelf, en niet bij een gedeeld sjabloon dat niemand heeft beoordeeld.

Het probleem is dat die grondigheid alleen werkt op kleine schaal. Zodra een organisatie tientallen of honderden leveranciers moet beoordelen, en zodra elk van die leveranciers hetzelfde verzoek van meerdere klanten parallel ontvangt, wordt een handmatig maatwerkproces niet nauwkeuriger met het volume. Het wordt trager, inconsistenter, en waarschijnlijker oppervlakkig beantwoord, alleen maar om het van iemands bureau af te krijgen. Precisie die ten koste gaat van afronding heeft niemand veel aan.

Hoe ziet “je werk laten zien” er eigenlijk uit?

Dit is het probleem waar de nieuwe compliance-vragenlijstenfunctie van Lighthouse, gebouwd samen met NFIR en Bizway, op is gericht. Het geeft een organisatie standaard NIS2/Cbw-vragenlijsten, in varianten geschaald naar of de klant een essentiële of een belangrijke entiteit is, zodat een leverancier iets kan invullen dat in verhouding staat tot de werkelijke verplichting in plaats van een maximalistisch worstcasescenario. Antwoorden worden niet teruggebracht tot ja of nee; elk antwoord draagt bewijs, een toelichting, of een verwachte datum waar iets nog in uitvoering is, en elk antwoord is voorzien van een tijdstempel met een audit trail.

De nuttigere verschuiving is wat er gebeurt na het eerste antwoord. Een leverancier kan één keer antwoorden, het bewijs bijvoegen, en dat geattesteerde bewijs hergebruiken de volgende keer dat een andere klant dezelfde vraag stelt, in plaats van elke keer bij een leeg formulier te beginnen. Sterker nog: een leverancier hoeft helemaal niet op het verzoek te wachten: dezelfde ingevulde vragenlijst kan proactief met alle klanten tegelijk worden gedeeld, en zo de vraag voor zijn dat die ooit landt.

Aan de klantkant kan een organisatie de leveranciers registreren waarvan ze afhankelijk is, elk de passende vragenlijst in eigen naam sturen, en een live-overzicht zien van waar de hele keten staat, met herbeoordeling op één klik afstand bij de volgende cyclus. De vragenlijsten zijn zonder meerkosten inbegrepen voor Guardian360-partners en hun klanten, dus budget is niet de reden om dit tot volgend kwartaal uit te stellen. Guardian360 is er duidelijk over dat dit een readiness-tool is, geen certificering: het vervangt geen formele audit of conformiteitsbeoordeling, en pretendeert dat ook niet. Wat het wel vervangt, zijn de vijftig aparte spreadsheets die niemand tijd had om te vergelijken.

Het ging nooit om de 8.000

Het is de moeite waard om terug te keren naar waar dit begon. NIS2, en de Cyberbeveiligingswet die haar omzet, gingen nooit echt over het weerbaarder maken van 8.000 organisaties in isolatie. De hele logica van de ketenverplichting in Artikel 21 is dat de beveiliging van een gereguleerde organisatie slechts zo goed is als de leveranciers daaronder. Behandel de wet als een compliance-oefening voor de bedrijven die in haar reikwijdte staan genoemd, en de werkelijke ambitie, het optrekken van de beveiligingsvloer over een hele toeleveringsketen van ruim boven de 100.000 bedrijven, faalt stilletjes bij de eerste schakel buiten die reikwijdte.

NFIR zag dit vanuit de adviesstoel, terwijl het toekeek hoe organisatie na organisatie haar eigen zaken op orde bracht terwijl haar leveranciers nergens terechtkonden. Bizway zag het vanaf de ontvangende kant, door dezelfde vraag steeds vaker en met steeds minder geduld te beantwoorden. De twee waarnemingen wijzen op dezelfde conclusie: compliance by proxy, één klant, één vragenlijst, één leverancier tegelijk, schaalt niet naar de omvang van het probleem dat NIS2 moest oplossen. Bouwen voor de laag onder de 8.000 is geen bijproject. Het ligt dichter bij het werkelijke doel van de wet dan de certificeringsrace ooit heeft gedaan.

Bronnen

• Rijksoverheid (7 July 2026). Cyberbeveiligingswet en Wet weerbaarheid kritieke entiteiten vanaf 15 augustus 2026 van kracht.
• NCSC. Cyberbeveiligingswet (NIS2).
• ENISA (June 2023). Good Practices for Supply Chain Cybersecurity.
• ISACA (4 May 2026). Enhancing Third Party Risk Management: Moving From Questionnaire Fatigue to Contextual Assurance.