De wet gaat op 15 augustus in zonder overgangstermijn. Wie eronder valt moet ook zijn leveranciers beoordelen, waardoor dezelfde vragen door de hele keten gaan.

Op 15 augustus 2026 treedt de Cyberbeveiligingswet in werking, de Nederlandse uitwerking van de Europese NIS2-richtlijn. De wet vervangt de Wet beveiliging netwerk- en informatiesystemen en geldt voor ruim 8.000 organisaties. Er is geen algemene overgangstermijn: de verplichtingen gelden vanaf de eerste dag.

De wet raakt organisaties op twee manieren. Direct, doordat je zelf aan de criteria voldoet. Of indirect, doordat een opdrachtgever eronder valt.

Of je tot de eerste groep hoort is niet altijd eenvoudig vast te stellen. Je kunt er ook onder vallen via de geconsolideerde cijfers van het concern waar je deel van uitmaakt, of doordat je activiteiten in een zwaardere categorie zijn ingedeeld dan je zou verwachten. Verderop staat waar die inschatting in de praktijk kan misgaan.

De tweede manier krijgt aanzienlijk minder aandacht. Wie onder de wet valt, moet ook de beveiliging van zijn leveranciers beoordelen en die beoordeling kunnen onderbouwen. Die verplichting is niet over te dragen. Dus geeft de organisatie de eisen door aan haar leveranciers, via vragenlijsten, contractvoorwaarden en inkoopeisen.

Zo bereikt de wet organisaties die er zelf niet onder vallen. Niet via een inspecteur, maar via een klant.

Hieronder eerst de scopevraag, daarna wat de wet feitelijk vraagt en tot slot de 21 vragen die door de keten gaan lopen.

Valt je organisatie onder de wet?

De toepasselijkheid hangt af van twee criteria: de sector waarin je actief bent en de omvang van je organisatie.

De aangewezen sectoren staan in bijlage 1 en bijlage 2 van de wet. Bijlage 1 bevat de zeer kritieke sectoren, waaronder energie, vervoer, bankwezen, gezondheidszorg, drinkwater, afvalwater, digitale infrastructuur, beheer van ICT-diensten, overheid en ruimtevaart. Bijlage 2 bevat de overige kritieke sectoren, waaronder post- en koeriersdiensten, afvalstoffenbeheer, chemie, levensmiddelen, vervaardiging, digitale aanbieders en onderzoek.

Voor de omvang geldt als hoofdregel:

  • Belangrijke entiteit: ten minste 50 medewerkers en een jaaromzet of balanstotaal boven 10 miljoen euro.
  • Essentiële entiteit: in een sector uit bijlage 1, met meer dan 250 medewerkers of een jaaromzet boven 50 miljoen euro.

Het onderscheid bepaalt hoe het toezicht wordt ingericht en hoe hoog de boetes kunnen uitvallen, niet welke verplichtingen gelden. Die zijn voor beide categorieën gelijk.

Drie situaties waarin de inschatting kan misgaan

  1. De groepstoets. Een werkmaatschappij met twintig medewerkers lijkt op zichzelf buiten bereik te vallen. Maakt die onderneming deel uit van een grotere structuur waarvan de geconsolideerde cijfers de drempelwaarden overschrijden, dan kan zij alsnog onder de wet vallen.
  2. Beheer van ICT-diensten staat in bijlage 1. De sector valt uiteen in beheerde ICT-diensten en beheerde beveiligingsdiensten. Een IT-dienstverlener die zich profileert als managed service provider zit daarmee in de zwaarste categorie. Datzelfde geldt vaak voor een werkmaatschappij die binnen een concern uitsluitend IT-diensten levert aan zusterbedrijven.
  3. Sommige organisaties vallen eronder ongeacht hun omvang. Dat geldt onder meer voor aanbieders van DNS-diensten, beheerders van topleveldomeinregisters, aanbieders van openbare elektronische communicatienetwerken of -diensten, gekwalificeerde vertrouwensdienstverleners en de centrale en decentrale overheid.

Weten waar je staat? Doe de quickscan en check in een paar minuten of je organisatie onder de Cyberbeveiligingswet valt.

Wat de wet vraagt van organisaties die eronder vallen

Er zijn drie hoofdverplichtingen.

  1. Zorgplicht. Passende technische en organisatorische maatregelen nemen om risico’s te beheersen.
  2. Meldplicht. Significante incidenten melden via het portaal van het NCSC. De eerste melding volgt binnen 24 uur en gaat naar het sectorale CSIRT en de toezichthouder.
  3. Registratieplicht. Opname in het entiteitenregister van het NCSC.

De zorgplicht is de meest omvattende van de drie. Artikel 21 van de NIS2-richtlijn benoemt tien onderwerpen waarop de maatregelen betrekking moeten hebben:

  • Risicoanalyse en beveiligingsbeleid
  • Incidentbehandeling
  • Bedrijfscontinuïteit, back-upbeheer en crisisbeheer
  • Beveiliging van de toeleveringsketen
  • Veilige verwerving, ontwikkeling en onderhoud van systemen
  • Beoordeling van de effectiviteit van de getroffen maatregelen
  • Cyberhygiëne en beveiligingstraining
  • Cryptografie en encryptie
  • Toegangsbeheer, personeelsbeleid en beheer van bedrijfsmiddelen
  • Meervoudige authenticatie en beveiligde communicatie

Daarnaast is de bestuurlijke verantwoordelijkheid expliciet gemaakt. Het bestuur keurt de maatregelen goed, moet zich actief laten informeren en is verplicht een beveiligingstraining te volgen. Het beleggen van taken bij een CISO, een IT-manager of een externe partij verandert niets aan de eindverantwoordelijkheid. Bij grove nalatigheid is persoonlijke aansprakelijkheid mogelijk en bij essentiële entiteiten kan een managementfunctie tijdelijk worden geschorst.

De boetemaxima liggen op 10 miljoen euro of 2 procent van de wereldwijde jaaromzet voor essentiële entiteiten en op 7 miljoen euro of 1,4 procent voor belangrijke entiteiten.

Het onderdeel dat het meeste werk oplevert

Van deze tien onderwerpen is er één waar de meeste organisaties nog niets voor hebben ingericht: de beveiliging van de toeleveringsketen.

Dat vraagt concreet om inventariseren welke leveranciers invloed hebben op je netwerk- en informatiesystemen, vastleggen welke beveiligingsmaatregelen zij hebben getroffen, nagaan welke certificeringen of auditrapporten beschikbaar zijn en dit vertalen naar afspraken in contracten.

Dat het hier knelt, blijkt ook uit cijfers van de Rijksinspectie Digitale Infrastructuur. Organisaties in de sector beheer van ICT-diensten die de zelfevaluatie van die inspectie invulden, scoorden zichzelf het laagst op het melden van significante incidenten, het trainen van bestuursleden en het verminderen van ketenrisico’s. Het gaat om zelfevaluatie en niet om inspectieresultaten, maar het is opvallend dat juist de sector die hier professioneel mee bezig is dit onderdeel als zwakste punt aanwijst.

Waarom dit ook geldt als je er niet onder valt

Voor leveranciers die buiten de reikwijdte vallen verandert de wet formeel niets. Geen zorgplicht, geen meldplicht, geen toezichthouder en geen boete.

Wat wel verandert is de contractuele werkelijkheid.

De ketenverplichting richt zich op leveranciers en dienstverleners die direct invloed hebben op de beveiliging van het netwerk- en informatiesysteem van hun klant. Een leverancier zonder digitale koppeling valt daar formeel buiten. Heb je wel een koppeling, toegang tot systemen of lever je software, dan sta je op de lijst die je klant moet opstellen en onderbouwen.

Dat uit zich in vier dingen:

  1. Vragenlijsten. Per klant een eigen versie, afgeleid van de tien onderwerpen of van een norm als ISO 27001.
  2. Nieuwe contractclausules bij verlenging. Meldtermijnen, auditrechten, goedkeuring van onderaannemers en afspraken over aansprakelijkheid.
  3. Beveiligingseisen als toelatingseis. In aanbestedingen verschuiven deze eisen van wenselijk naar knock-out.
  4. De ontdekking dat je zelf onder de wet valt. Dit komt vaker voor dan verwacht, met name via de groepstoets en de sector beheer van ICT-diensten. Doe in dat geval eerst de quickscan.

Het risico voor een leverancier is dus geen boete. Het risico is dat je de opdracht verliest aan een partij die de vragenlijst wel kan invullen.

De 24-uursklok werkt door in de keten

Er is één gevolg dat in de praktijk het meest concreet uitpakt.

Een organisatie die onder de wet valt, moet een significant incident binnen 24 uur melden. Ligt een deel van haar dienstverlening bij een leverancier, dan is zij voor die termijn afhankelijk van het moment waarop die leverancier aan de bel trekt. Daarom verschijnen er in contracten meldtermijnen die korter zijn dan 24 uur, bijvoorbeeld acht of twaalf uur.

Een voorbeeld. Een softwareleverancier met vijftien medewerkers levert een planningsapplicatie aan een regionale zorginstelling die onder de wet valt. Op vrijdagavond wordt er ingelogd op een beheeraccount van de leverancier vanaf een onbekend adres. Er slaat niemand alarm, want er wordt buiten kantooruren niet meegekeken. Maandagochtend valt het op.

Voor de zorginstelling begint de meldtermijn van 24 uur pas op het moment dat zij zelf op de hoogte is, dus formeel mist zij geen termijn. Het probleem zit ergens anders. Zij heeft drie dagen lang niets kunnen doen, zij moet aan haar toezichthouder kunnen uitleggen hoe zij toezicht houdt op haar leveranciers en bij de volgende contractronde legt zij vast dat meldingen voortaan binnen acht uur binnenkomen.

Voor de leverancier is dat het werkelijke gevolg. Geen boete, maar een contracteis die alleen waar te maken is met detectie en bereikbaarheid buiten kantooruren.

Zo’n meldtermijn is dus geen papieren afspraak. Er hoort ook een procedure bij waarin vastligt wie beoordeelt of er gemeld moet worden en wie dat besluit neemt. Wie een korte meldtermijn tekent zonder dat te hebben geregeld, creëert een aansprakelijkheidsrisico dat losstaat van de wet zelf.

De 21 vragen

Hieronder de vragen zoals ze in leveranciersbeoordelingen terechtkomen. Ze zijn op twee manieren te gebruiken:

  • Val je onder de wet: gebruik ze om je leveranciers te beoordelen en die beoordeling vast te leggen.
  • Val je er niet onder: vul ze zelf in, zodat je voorbereid bent op het moment dat een klant erom vraagt.

Beleid en verantwoordelijkheid

  1. Is er een informatiebeveiligingsbeleid dat door de directie is vastgesteld?
  2. Wie is binnen de organisatie aanwijsbaar verantwoordelijk voor informatiebeveiliging?
  3. Wanneer is de laatste risicoanalyse uitgevoerd?

Incidenten

  1. Is er een incidentresponsprocedure en is die het afgelopen jaar geoefend?
  2. Binnen welke termijn wordt een incident aan de klant gemeld?
  3. Wie is buiten kantooruren bereikbaar en via welk kanaal?

Toegang

  1. Wordt meervoudige authenticatie toegepast op alle externe toegang en op beheerdersaccounts?
  2. Hoe wordt toegang ingetrokken bij uitdiensttreding?
  3. Wie binnen de organisatie heeft toegang tot de gegevens van de klant?

Gegevens en infrastructuur

  1. In welk land staan de gegevens fysiek opgeslagen?
  2. Welke onderaannemers of subverwerkers hebben toegang tot die gegevens?
  3. Onder welke jurisdictie valt de partij die de opslag beheert?
  4. Worden gegevens versleuteld in rust en tijdens transport? Wie beheert de sleutels?

Continuïteit

  1. Hoe vaak wordt een back-up gemaakt en waar staat die?
  2. Wanneer is een herstel voor het laatst getest en hoe lang duurde dat?
  3. Welke hersteltijd en welk maximaal gegevensverlies zijn contractueel vastgelegd?

Onderhoud

  1. Binnen welke termijn worden kritieke kwetsbaarheden verholpen?
  2. Hoe wordt geleverde software gecontroleerd op kwetsbaarheden?

Mensen en keten

  1. Krijgen medewerkers periodiek een beveiligingstraining?
  2. Heeft de directie een beveiligingstraining gevolgd?
  3. Worden de eigen leveranciers op dezelfde punten beoordeeld?

Overigens: de Cyberbeveiligingswet verplicht niet tot ISO 27001-certificering. Een gedocumenteerde en onderbouwde set maatregelen volstaat. Dat scheelt met name kleinere organisaties een aanzienlijke investering.

Vier vragen waarvan het antwoord meestal buiten je eigen organisatie ligt

Van de 21 vragen zijn er zeventien die je met eigen documentatie kunt beantwoorden. Beleid, procedures, toegangsbeheer en training zijn zaken die je zelf inricht en vastlegt.

Vier vragen zijn anders van aard. Vraag 10 tot en met 13 gaan over de locatie van de gegevens, de partijen die er toegang toe hebben, de jurisdictie van de beheerder en het sleutelbeheer. Dat zijn geen vragen over jouw beleid maar over de infrastructuur waarop je draait. Het antwoord ligt bij de dienstverlener die de opslag verzorgt en die geeft er niet altijd volledig inzicht in.

Vraag 10 en 12 worden daarbij vaak door elkaar gehaald. Dat gegevens in een Europees datacentrum staan zegt niets over de rechtsorde waaronder de partij valt die dat datacentrum en de bijbehorende beheeraccounts exploiteert. Locatie en jurisdictie zijn twee verschillende antwoorden en alleen het tweede zegt iets over wie er uiteindelijk toegang kan afdwingen.

Vraag 13 is de scherpste van de vier. Zolang je leverancier de sleutels beheert, is “wie heeft toegang tot onze gegevens” een vraag naar vertrouwen. Beheer je ze zelf, dan is het een vraag naar techniek en is het antwoord controleerbaar, ongeacht waar de servers staan of onder welke rechtsorde de beheerder valt.

Bij vraag 11 speelt nog iets anders: het antwoord heeft een houdbaarheidsdatum. Een leverancier kan zijn eigen onderaannemers wisselen zonder dat jij daar bericht van krijgt, terwijl jij die keten wel actueel moet kunnen beschrijven. Wat vandaag klopt is over een jaar niet vanzelf nog juist. De vraag komt bovendien terug bij elke contractronde en elke aanbesteding.

Voor de wet is een verklaring van je leverancier niet automatisch onvoldoende. Je mag je baseren op certificeringen en auditrapporten. Maar er zit verschil tussen “onze leverancier verklaart dat” en “wij kunnen laten zien dat”. Dat verschil wordt zichtbaar op het moment dat een toezichthouder of een klant doorvraagt.

Dat verschil los je zelden op door een betere leverancier te kiezen. De gangbare cloudmodellen zijn ontworpen op schaal en gemak, waarbij de klant bewust op afstand van de infrastructuur is gezet. Dat is een ontwerpkeuze en geen nalatigheid, maar het is wel de reden dat vraag 10 tot en met 13 binnen dat model moeilijk te beantwoorden zijn. De wet vraagt nu juist naar dat antwoord.

Wat YourData Network hierin doet

Wij benaderen die vier vragen vanaf de andere kant. Niet door meer garanties te vragen van een leverancier, maar door de organisatie zelf op de infrastructuur te zetten.

Dat werkt via het decentrale internet van ThreeFold. In plaats van capaciteit te huren in een gedeelde omgeving draaien je applicaties op een node: een aanwijsbaar apparaat op een bekende locatie, dat je zelf in bezit kunt hebben. Daarop installeren en beheren wij de toepassingen waarmee je organisatie werkt. Dat kan Nextcloud zijn voor bestanden, agenda en samenwerking, maar net zo goed een eigen ERP-pakket of een andere bedrijfsapplicatie. Het beheer ligt bij ons, de sleutels blijven bij de organisatie.

Voor de vier vragen levert dat het volgende op:

  • Vraag 10. De locatie is een apparaat op een adres, niet een regioaanduiding in de voorwaarden van een aanbieder.
  • Vraag 11. De keten bestaat uit de organisatie zelf en YourData Network. Er zit geen laag onderaannemers onder die buiten je zicht kan wisselen.
  • Vraag 12. Eén jurisdictie, die bovendien bekend is.
  • Vraag 13. Het sleutelbeheer ligt bij de organisatie. Daarmee wordt “wie kan bij onze gegevens” een technisch gegeven in plaats van een afspraak.

Daarnaast raken wij vraag 9, 14 en 16 gedeeltelijk: toegangsbeheer, de locatie van back-ups en de afspraken over hersteltijd.

Wat dit vooral oplevert is dat de antwoorden niet verlopen. Ze zijn een eigenschap van de opzet en niet van een contract dat opnieuw onderhandeld moet worden zodra je leverancier iets verandert.

De overige veertien vragen gaan over beleid, procedures, training en documentatie. Daar is geen product voor. Dat is werk dat je zelf doet of samen met een adviespartij. Geen enkele leverancier kan een organisatie compliant maken en wij dus ook niet. Wat wij wel kunnen, is de vragen wegnemen waarop je het antwoord nu ergens anders moet gaan halen. Hoe dat er in de praktijk uitziet staat op de pagina over de Soevereine Digitale Werkplek.

Waar te beginnen

  1. Stel vast of je organisatie onder de wet valt, inclusief de groepstoets.
  2. Breng in kaart welke klanten in scope zijn. Dat zijn de partijen die gaan vragen.
  3. Beantwoord de 21 vragen eenmalig voor jezelf en leg de antwoorden vast, in plaats van per klant te improviseren.
  4. Loop de contracten na op meldtermijnen die je operationeel kunt waarmaken.
  5. Bepaal per onbeantwoorde vraag of het om documentatie gaat of om een keuze in je infrastructuur.

De wet treedt in werking op 15 augustus. De vragenlijsten volgen daarna, bij contractverlengingen en aanbestedingen. Dat geeft ruimte, maar het maakt de eerste stap niet minder urgent.

Nog geen antwoord op deze vier vragen?

Vraag 10 tot en met 13 gaan over waar je gegevens staan, welke partijen erbij kunnen, onder welke jurisdictie de beheerder valt en wie de sleutels beheert. Dat zijn de vragen waarvoor wij een oplossing bouwen. Heb je daar nu geen sluitend antwoord op, dan denken we graag met je mee.

In een gesprek kijken we naar je huidige opzet en naar wat er nodig zou zijn om die vragen wel te kunnen beantwoorden. Geen verkoopgesprek, maar een eerlijke inschatting van waar je staat en wat een logische eerste stap is.

Plan direct een afspraak in op een moment dat jou uitkomt, of stuur een mail naar hello@yourdata.network.

Bronnen

  • Nationaal Coördinator Terrorismebestrijding en Veiligheid, informatie over de Cyberbeveiligingswet: nctv.nl
  • Rijksinspectie Digitale Infrastructuur, Cyberbeveiligingswet en resultaten van de NIS2-zelfevaluatie: rdi.nl
  • Nationaal Cyber Security Centrum, informatiebrochure Cyberbeveiligingswet: ncsc.nl
  • Wetsvoorstel 36764, Eerste Kamer

Lees ook: Een ERP-systeem dat je niet vastzet: YourData Network start met ERPNext