De WWKE-wetgeving zet weerbaarheid hoger op de agenda, ook bij organisaties die niet direct als kritieke entiteit worden aangewezen. In de praktijk loopt die druk vaak via klanten, contracten en audits, en precies daar wordt jouw IT-keten bepalend. Als een leverancier uitvalt, wordt gehackt of onduidelijk is over subleveranciers, wordt dat al snel jouw continuïteitsprobleem.
In dit artikel lees je wat de Wet weerbaarheid kritieke entiteiten inhoudt, waarom ketenverantwoordelijkheid je IT-risico vergroot, welke eisen je aan IT-partners stelt en hoe je ketenrisico beheersbaar maakt zonder een groot intern securityteam.
Wat WWKE betekent voor jouw organisatie
De Wet weerbaarheid kritieke entiteiten is de Nederlandse implementatie van de Europese CER-richtlijn. De wet is bedoeld om organisaties die essentiële diensten leveren weerbaarder te maken tegen verstoringen, met aandacht voor zowel fysieke als organisatorische maatregelen. De overheid adviseert organisaties om niet af te wachten met de voorbereiding, omdat de risico’s nu al bestaan en ketens steeds sterker verweven zijn.
Ook als je zelf geen kritieke entiteit bent, kun je met de WWKE-wetgeving te maken krijgen via:
- Klanten die wél onder de scope vallen en strengere eisen doorleggen in contracten.
- Ketenafhankelijkheden waarbij jouw dienstverlening onderdeel is van een essentiële dienst.
- Toezicht- en assurancevragen, zoals aantoonbaarheid van continuïteit en incidentafhandeling.
Belangrijke begrippen zijn kritieke entiteit, weerbaarheidsmaatregelen, risicobeoordelingen, incidentmelding en toezicht. IT-dienstverlening is hierin een belangrijke schakel, omdat digitale werkplekken, cloud, identity en netwerkbeveiliging direct bepalen of je kunt blijven werken tijdens verstoringen.
Waarom ketenverantwoordelijkheid IT-risico vergroot
Ketenverantwoordelijkheid betekent dat je niet alleen naar je eigen beveiliging kijkt, maar ook naar de partijen die jouw IT mogelijk maken. Denk aan MSP’s, cloudproviders, softwareleveranciers en onderaannemers. Hun keuzes en incidenten werken door in jouw beschikbaarheid, integriteit en vertrouwelijkheid.
Typische ketenincidenten die je WWKE-risico vergroten:
- Ransomware bij een leverancier waardoor beheer, support of back-ups tijdelijk niet beschikbaar zijn.
- Uitval bij een cloudplatform waardoor je werkplek, mail of dossiers niet bereikbaar zijn.
- Misconfiguraties of foutieve updates die securitycontrols verzwakken of systemen platleggen.
- Onvoldoende toegangsbeheer bij een subleverancier waardoor accounts worden misbruikt.
De impact is zelden alleen technisch. Het raakt ook compliance, klantvertrouwen en je vermogen om incidenten tijdig te detecteren en te melden. Bovendien kan een kritieke klant eisen dat jij aantoont hoe je leveranciersrisico’s beheerst, inclusief afspraken over escalatie en herstel.
Welke eisen je aan IT-partners stelt
Een goede IT-partner helpt je aantoonbaar grip te krijgen op risico’s. Let bij selectie en evaluatie op deze onderdelen en vraag om bewijs in de vorm van beleid, rapportages en procesbeschrijvingen.
| Onderwerp | Waar je op let |
|---|---|
| Informatiebeveiliging | ISO 27001 en, waar relevant, NEN 7510. Duidelijke scope, een actuele Statement of Applicability en inzicht in hoe bevindingen worden opgevolgd. |
| Logging en monitoring | Welke logs worden verzameld, hoe lang ze worden bewaard, wie meekijkt en hoe escalatie werkt bij verdachte signalen. |
| Patch- en vulnerabilitymanagement | Vaste cadans, prioritering op risico en aantoonbare opvolging van kwetsbaarheden. |
| Identity en access management | MFA, least privilege, rolgebaseerde rechten en strikt beheer van adminaccounts. |
| Back-up en recovery | Herstelbaarheid aantonen met tests, duidelijke RTO- en RPO-afspraken en bescherming tegen ransomware. |
| Incident response | Runbooks, communicatieplan, samenwerking met derde partijen en evaluatie na incidenten. |
| Continuïteit en DR | Businesscontinuïteitsplan, scenario’s voor uitval van leveranciers en periodieke oefeningen. |
| Datalocatie en subverwerkers | Transparantie over waar data staat, wie erbij kan en welke subverwerkers worden ingezet. |
Contractueel wil je dit borgen via SLA’s, een DPA of verwerkersovereenkomst, auditrechten, vaste rapportages en een exitplan. Dat exitplan is belangrijker dan het vaak voelt, omdat het je onderhandelingspositie en continuïteit beschermt als de relatie verandert.
Praktische stappen voor ketenrisicobeheer
Ketenrisicobeheer hoeft niet zwaar te zijn, zolang je het structureert. Voor MKB-organisaties met beperkte interne IT-capaciteit werkt deze aanpak goed.
- Maak een leveranciersinventarisatie. Neem ook subleveranciers mee die toegang hebben tot systemen of data.
- Classificeer op kritikaliteit. Kijk naar impact op dienstverlening, datagevoeligheid en herstelbaarheid.
- Doe een risicoanalyse per kritieke leverancier. Focus op uitval, cyberincidenten en afhankelijkheden.
- Gebruik een due-diligencevragenlijst. Vraag naar monitoring, patching, back-ups, IAM en incidentprocessen.
- Plan periodieke reviews. Niet alleen bij contractverlenging, maar als vast ritme met actiepunten.
- Vraag securityassessments en relevante rapportages. Combineer dit waar nodig met eigen controles.
- Oefen incidenten met table-topsessies. Test escalatie, communicatie en herstel, ook met leveranciers erbij.
- Stuur op KPI’s en KRI’s. Denk aan patchdoorlooptijd, hersteltests en tijd tot detectie en respons.
Maak het werkbaar door eigenaarschap te beleggen: één verantwoordelijke voor leveranciersregie, één voor securitycontrols en vaste momenten in de agenda. Zo wordt ketenverantwoordelijkheid een routine in plaats van een project.
Veelgemaakte fouten bij WWKE en leveranciers
Deze valkuilen zorgen ervoor dat WWKE-wetgeving vooral als stressfactor voelt, terwijl het juist bedoeld is om rust en voorspelbaarheid te brengen.
- Blind vertrouwen op certificaten zonder te kijken naar scope, uitzonderingen en opvolging van bevindingen.
- Onduidelijke verantwoordelijkheden tussen interne teams, IT-partner en cloudleveranciers.
- Geen zicht op subleveranciers en hun toegang tot jouw data en beheerkanalen.
- Te brede adminrechten en te weinig controle op privileged accounts.
- Back-ups die wel bestaan, maar nooit echt zijn teruggezet in een hersteltest.
- Geen exitstrategie, waardoor je vastzit aan tooling of contracten als er iets verandert.
- Versnipperde tooling waardoor monitoring en incidentrespons gaten vertonen.
- Onvoldoende documentatie, wat audits, incidentmelding en herstel vertraagt.
Het gevolg is meestal niet één groot probleem, maar een optelsom: langere downtime, meer kans op datalekken, lastige audits en extra herstelwerk op momenten dat je juist door moet.
Hoe Mr. Blocks helpt met WWKE-ketenverantwoordelijkheid
Wij helpen organisaties om WWKE-ketenverantwoordelijkheid praktisch te maken, met een digitale werkplek en een IT-fundament dat voorspelbaar blijft onder druk. Daarbij nemen we security mee als vast onderdeel van beheer, met continue bewaking en snelle opvolging van risico’s.
- Heldere governance en rollen: wie doet wat bij incidenten, changes en leveranciersafspraken.
- Security by default met managed firewalldiensten, 24/7-monitoring en directe ondersteuning.
- Endpoint Detection & Response op basis van AI om afwijkend gedrag vroeg te signaleren.
- Vulnerabilitymanagement en patching als doorlopend proces, met aantoonbare opvolging.
- Back-up en recovery inclusief hersteltests, plus continuïteitsafspraken die je kunt uitleggen in audits.
- Leveranciersregie en inzicht in subverwerkers, datalocatie en toegangsrechten.
- Documentatie en rapportage die aansluit op compliancevragen vanuit klanten en toezichthouders.
Lees meer over onze aanpak voor de digitale werkplek, bekijk wie we zijn op mrblocks.nl, of plan direct een gesprek via contact voor een korte ketenrisicoscan en een helder stappenplan.
Veelgestelde vragen
Hoe bepaal ik welke leveranciers ‘kritiek’ zijn voor WWKE-ketenrisico?
Maak een korte impactcheck per leverancier: (1) kan je primaire dienstverlening door zonder hen, (2) hebben ze toegang tot gevoelige data of beheeraccounts, (3) wat is je maximale acceptabele downtime, en (4) is er een realistisch alternatief. Leveranciers die op één van deze punten hoog scoren, behandel je als kritisch en review je vaker.
Welke minimale bewijsstukken kan ik opvragen zonder een zware audit te starten?
Vraag om: een recente ISO 27001/NEN 7510 scope + SoA-samenvatting, een incident- en escalatieproces (incl. contactpunten), een overzicht van back-up/hersteltests (datum + resultaat), patch-/vuln-SLA’s, en een lijst met subverwerkers incl. datalocaties. Dit geeft snel zicht op volwassenheid en blinde vlekken.
Hoe leg ik WWKE-verwachtingen slim vast in contracten en SLA’s?
Werk met een bijlage ‘security & continuïteit’ met meetbare afspraken: RTO/RPO, meldtermijnen bij incidenten, logging/retentie, patchtermijnen per severity, MFA/least privilege, auditrecht (of third-party assurance), en een verplichting om subverwerkers vooraf te melden. Voeg ook een escalatiematrix en boete-/servicecredits toe waar passend.
Wat is een praktisch exitplan voor IT-dienstverlening en hoe test ik dat?
Beschrijf minimaal: welke data je periodiek exporteert (format + frequentie), wie eigenaar is van tenant/domeinen/keys, hoe je admin-toegang overdraagt, welke documentatie je meekrijgt, en een migratiepad naar een alternatief. Test het klein: voer elk kwartaal één ‘exit-actie’ uit, zoals een volledige data-export of het herstellen van een omgeving in een aparte tenant.
Hoe kan ik subleveranciers en datalocaties inzichtelijk maken als mijn leverancier vaag blijft?
Vraag om een actuele subverwerkerslijst en laat dit contractueel verplichten. Krijg je geen duidelijkheid, stel een deadline en koppel dit aan risico-classificatie: minder toegang, extra monitoring, of een alternatief traject. Gebruik daarnaast je eigen bronnen: facturen/portals, DNS/WHOIS, cloud-tenant informatie en securityrapportages om afhankelijkheden te verifiëren.
Welke KPI’s/KRI’s zijn het meest bruikbaar voor MKB om ketenrisico te sturen?
Kies 6–8 indicatoren die je maandelijks kunt volgen: patchdoorlooptijd (kritiek/hoog), % systemen met MFA, aantal privileged accounts, succesratio hersteltests, tijd tot detectie (MTTD) en respons (MTTR), aantal openstaande high findings, en beschikbaarheid/incidenten per leverancier. Koppel drempelwaarden aan acties (escalatie, extra review, verbeterplan).
Wat doe ik als een leverancier geen certificering heeft, maar wel essentieel is?
Compenseer met gerichte assurance: laat een securityvragenlijst invullen, vraag bewijs van kerncontrols (MFA, back-ups, logging, patching), spreek verbeterdeadlines af en beperk toegang (least privilege, segregatie, jump host). Overweeg een onafhankelijke assessment of pentest op de relevante scope en leg vast dat je bij uitblijven van verbetering kunt afschalen of overstappen.
