Plan een gesprek

Waarom technologie alleen je bedrijf niet veilig maakt

Veel organisaties investeren in betere firewalls, antivirussoftware en beveiligingstools. Logisch, want de markt is er vol mee en leveranciers beloven er veel van. Toch blijft het aantal succesvolle cyberaanvallen stijgen. Hoe kan dat?

Het antwoord is ongemakkelijk simpel: alleen technologie lost een menselijk probleem niet op.

De drie pijlers van digitale veiligheid

Beveiliging rust op drie pijlers: mensen, processen en technologie. De meeste organisaties investeren zwaar in de derde en nauwelijks in de eerste twee. Dat is precies waar aanvallers op inspelen.

Een medewerker die niet weet hoe een phishingmail eruitziet, klikt ook door de beste firewall heen. Een organisatie zonder duidelijk proces voor wie wat doet bij een incident, staat stil op het moment dat het er het meest toe doet. Geen tool lost dat op.

Wat mensen ermee te maken hebben

Negen van de tien beveiligingsincidenten begint bij een menselijke handeling. Niet omdat mensen onoplettend zijn, maar omdat aanvallers daar specifiek op sturen. Ze maken berichten die urgent klinken. Ze imiteren bekende afzenders. Ze kiezen het moment waarop iemand afgeleid is.

Awareness is daarom geen nice-to-have. Het is de basis waarop al het andere rust.

Wat processen ermee te maken hebben

Stel dat een medewerker een verdacht bericht ontvangt en het herkent. Wat doet hij dan? Als het antwoord “weet ik niet precies” is, heb je een procesprobleem. Goede beveiliging beschrijft niet alleen wat er niet mag, maar ook wat er moet gebeuren als het toch misgaat.

Een incidentresponsplan, duidelijke afspraken over toegangsbeheer en periodieke evaluatie van wat er werkt en wat niet, dat zijn de processen die het verschil maken.

De rol van technologie

Technologie is onmisbaar, maar het is de derde pijler, niet de eerste. Een goede firewall filtert wat er binnenkomt. Netwerkdetectie signaleert afwijkend gedrag. E-mailbeveiliging houdt een groot deel van de phishingpogingen tegen.

Maar al die tools werken alleen als de mensen die ermee werken weten wat ze doen en de processen eromheen kloppen.

Wat dit betekent voor jouw organisatie

De vraag is niet of je genoeg technologie hebt. De vraag is of de drie pijlers in balans zijn. Een korte audit of zelfscan geeft je daar snel inzicht in, zonder dat je er een groot project van hoeft te maken.

Digitale rust begint niet bij de beste tool. Het begint bij het juiste overzicht.

Wachtwoordbeleid is verouderd: wat er nu wel werkt

Veel organisaties hanteren nog steeds een wachtwoordbeleid dat decennia oud is: minimaal acht tekens, een hoofdletter, een cijfer, een speciaal teken, en elke negentig dagen verplicht wijzigen. Dit beleid is gebaseerd op aannames die inmiddels achterhaald zijn, en in de praktijk maakt het organisaties vaak minder veilig, niet meer.

Dat klinkt tegenstrijdig, maar is goed te verklaren als je kijkt naar hoe mensen daadwerkelijk omgaan met dit soort verplichtingen, en naar hoe aanvallers wachtwoorden tegenwoordig misbruiken.

Waarom het oude beleid niet meer werkt

Verplichte periodieke wijziging leidt tot voorspelbare patronen. Als medewerkers elke negentig dagen een nieuw wachtwoord moeten verzinnen, vervallen ze in voorspelbare aanpassingen: Wachtwoord1, Wachtwoord2, Wachtwoord3. Dit patroon is voor aanvallers net zo makkelijk te raden als het oorspronkelijke wachtwoord.

Complexiteitseisen leiden tot hergebruik. Een wachtwoord met hoofdletters, cijfers en symbolen is moeilijk te onthouden, vooral als iemand dit voor tientallen verschillende diensten moet doen. Het resultaat is dat mensen hetzelfde complexe wachtwoord op meerdere plekken gebruiken, of het opschrijven op een onveilige plek. Beide ondermijnen het doel van de maatregel.

Lengte is belangrijker dan complexiteit. Onderzoek naar wachtwoordkraken laat zien dat een langere, eenvoudigere zin moeilijker te kraken is dan een kort, complex wachtwoord. “OndergaandeZonBoven2026” is sterker en makkelijker te onthouden dan “P@ssw0rd!”.

De grootste dreiging is niet het raden van wachtwoorden. De meeste wachtwoorden worden niet gekraakt door ze te raden, maar gestolen via phishing, datalekken bij andere diensten, of malware. Een uitstekend, complex wachtwoord biedt geen bescherming als het via phishing wordt buitgemaakt. Dit verandert wat de prioriteit van een wachtwoordbeleid zou moeten zijn.

Het Nationaal Cyber Security Centrum en internationale instanties zoals het Amerikaanse NIST hebben hun richtlijnen de afgelopen jaren dan ook bijgesteld: weg van verplichte periodieke wijziging en complexiteitseisen, naar lengte, het controleren van wachtwoorden tegen bekende datalekken, en vooral: het inzetten van multifactorauthenticatie.

Wat een modern wachtwoordbeleid wel inhoudt

Lengte boven complexiteit. Stel een minimale lengte in van twaalf tot vijftien tekens, zonder verplichte combinatie van speciale tekens. Moedig het gebruik van langere wachtwoordzinnen aan in plaats van korte, complexe combinaties.

Geen verplichte periodieke wijziging zonder reden. Een wachtwoord hoeft niet te worden gewijzigd als er geen aanwijzing is dat het is gecompromitteerd. Verplicht wijzigen alleen na een vermoeden van een lek of bij een specifiek incident.

Controleren tegen bekende datalekken. Er bestaan databases met wachtwoorden die zijn buitgemaakt bij eerdere datalekken. Systemen kunnen automatisch controleren of een nieuw wachtwoord in zo’n database voorkomt en het wachtwoord afkeuren als dat het geval is.

Multifactorauthenticatie als primaire verdediging. Het wachtwoordbeleid is niet langer de belangrijkste verdedigingslaag. MFA vangt het risico op dat een wachtwoord alleen niet kan dekken, en verdient daarom prioriteit boven verdere verfijning van wachtwoordregels.

Een wachtwoordmanager faciliteren of verplichten. Het grootste probleem met wachtwoorden is dat mensen ze moeten onthouden. Een wachtwoordmanager lost dat probleem op door unieke, sterke wachtwoorden per dienst te genereren en op te slaan, zonder dat een medewerker ze hoeft te onthouden. Veel organisaties stellen een licentie hiervoor beschikbaar als onderdeel van de standaarduitrusting.

Op termijn: passwordless authentication. De richting waarin de industrie zich beweegt, is het volledig vervangen van wachtwoorden door passkeys, gebaseerd op cryptografische sleutels die aan een apparaat zijn gebonden. Dit elimineert het risico van phishing voor wachtwoorden volledig, omdat er simpelweg niets is om te stelen of te misleiden. Niet elke organisatie is hier al klaar voor, maar het is een ontwikkeling die de komende jaren aan relevantie zal winnen.

Wat dit betekent voor de implementatie

Een overstap naar dit beleid vraagt om communicatie naar medewerkers, want het kan in eerste instantie als minder streng overkomen, terwijl het in werkelijkheid effectiever is. Het is nuttig om uit te leggen waarom de verandering wordt doorgevoerd: niet om het makkelijker te maken, maar om het daadwerkelijk veiliger te maken.

De overstap kan geleidelijk: begin met het afschaffen van verplichte periodieke wijziging en de introductie van een wachtwoordmanager, gevolgd door het instellen van controles tegen bekende datalekken, en parallel daaraan de uitrol van MFA op de meest kritieke systemen.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties hun wachtwoordbeleid moderniseren op basis van actuele inzichten, in combinatie met de bredere inzet van multifactorauthenticatie en passwordless authenticatie waar dat past. We ondersteunen bij zowel de technische implementatie als de communicatie naar medewerkers.

Wil je weten of jullie wachtwoordbeleid nog aansluit op de huidige inzichten, of toe is aan vernieuwing? Neem contact op voor een vrijblijvend gesprek.

Leveranciersrisico: waarom de zwakste schakel niet bij jou zit

Organisaties investeren in hun eigen beveiliging: firewalls, monitoring, training, patchbeheer. Tegelijk verlenen ze toegang tot hun systemen aan tientallen externe partijen, leveranciers, IT-dienstverleners, accountants, marketingbureaus, zonder dezelfde mate van controle toe te passen op die toegang. Dat is een blinde vlek die de afgelopen jaren herhaaldelijk is misbruikt.

Een aantal van de grootste cyberincidenten van de afgelopen jaren begonnen niet bij het uiteindelijke doelwit, maar bij een kleinere partij in de keten. Een IT-dienstverlener, een softwareleverancier, een accountantskantoor. De aanvaller kiest niet altijd het sterkste doelwit direct, maar de meest toegankelijke weg ernaartoe.

Waarom leveranciers een aantrekkelijk doelwit zijn

Een leverancier heeft vaak toegang tot systemen van meerdere klanten. Voor een aanvaller is dat efficiënt: één succesvolle inbraak bij een leverancier kan toegang geven tot tientallen of honderden organisaties die met die leverancier samenwerken.

Daarnaast zijn leveranciers, met name kleinere IT-dienstverleners en gespecialiseerde softwarebedrijven, vaak minder goed beveiligd dan hun grotere klanten. Ze hebben kleinere IT-budgetten, minder dedicated beveiligingspersoneel, en staan minder onder druk van toezichthouders dan grotere, gereguleerde organisaties.

Het resultaat: een aanvaller die het op een grote organisatie heeft voorzien, kijkt eerst naar de leveranciers van die organisatie. Niet omdat de leverancier het doelwit is, maar omdat de leverancier de ingang is.

Wat dit in de praktijk betekent

Dit risico speelt op meerdere manieren.

Directe toegang. Veel leveranciers hebben inloggegevens of een VPN-verbinding tot systemen van hun klant, bijvoorbeeld voor onderhoud op afstand. Als die toegang niet goed wordt beveiligd of gemonitord, is het een directe route naar binnen.

Software-updates als verspreidingskanaal. Een aanvaller die de update-infrastructuur van een softwareleverancier compromitteert, kan kwaadaardige code verspreiden via wat normaal gesproken een vertrouwde, legitieme update is. Dit type aanval, een supply chain attack, is bijzonder schadelijk omdat het vertrouwen in het update-proces zelf misbruikt.

Gedeelde data. Een leverancier die klantdata verwerkt, bijvoorbeeld een salarisadministratiekantoor of een marketingbureau, vormt een risico als die data niet adequaat wordt beveiligd, ook als de eigen systemen van de opdrachtgever volledig in orde zijn.

Indirecte reputatieschade. Zelfs als de eigen organisatie geen directe schade ondervindt, kan een incident bij een leverancier waarmee je publiekelijk wordt geassocieerd, ook jouw reputatie raken.

Waarom dit nu een wettelijke dimensie krijgt

Onder de Cyberbeveiligingswet, de Nederlandse uitwerking van NIS2, wordt ketenverantwoordelijkheid een formele verplichting voor organisaties die onder de wet vallen. Zij moeten niet alleen hun eigen beveiliging op orde hebben, maar ook beoordelen of hun leveranciers voldoende maatregelen treffen.

Dit betekent dat organisaties die onder de wet vallen, in toenemende mate eisen gaan stellen aan hun toeleveranciers. Wie als leverancier niet kan aantonen dat de beveiliging op orde is, loopt het risico contracten te verliezen aan concurrenten die dat wel kunnen.

Hoe je leveranciersrisico in kaart brengt

Maak een overzicht van alle leveranciers met toegang tot systemen of data. Dit klinkt als een eenvoudige stap, maar in de praktijk hebben veel organisaties geen volledig overzicht van wie precies toegang heeft tot wat.

Beoordeel het risiconiveau per leverancier. Niet elke leverancier vormt hetzelfde risico. Een leverancier met directe toegang tot productiesystemen of gevoelige data vormt een groter risico dan een leverancier die alleen kantoorbenodigdheden levert.

Stel minimale beveiligingseisen vast. Voor leveranciers met een hoger risiconiveau is het redelijk om concrete eisen te stellen, zoals het gebruik van MFA, encryptie van gegevens, en een eigen incidentresponsplan.

Beperk toegang tot het minimum. Net als bij interne toegang geldt hier het principe van minimale rechten. Een leverancier die alleen een specifiek systeem onderhoudt, heeft geen toegang nodig tot de rest van het netwerk.

Monitor en evalueer periodiek. Beveiligingsniveaus veranderen. Een jaarlijkse evaluatie van de belangrijkste leveranciers houdt het overzicht actueel.

Leg verantwoordelijkheden contractueel vast. Wie is verantwoordelijk bij een incident dat via de leverancier ontstaat? Welke meldplicht heeft de leverancier richting jouw organisatie? Deze afspraken horen in het contract, niet pas besproken te worden tijdens een crisis.

De spiegel: ben jij de zwakste schakel?

Het risico werkt in twee richtingen. Als jouw organisatie diensten levert aan andere bedrijven, ben jij mogelijk de leverancier waar dit verhaal op slaat. Steeds meer klanten vragen, of zullen gaan vragen, om aantoonbaar bewijs van adequate beveiliging voordat ze een contract aangaan of verlengen. Organisaties die hierop voorbereid zijn, hebben een commercieel voordeel ten opzichte van concurrenten die dat niet zijn.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties leveranciersrisico’s in kaart te brengen en te beheersen, en ondersteunt organisaties die zelf als leverancier moeten aantonen dat hun beveiliging op orde is. We brengen structuur in een proces dat bij veel organisaties nog ad hoc en onvolledig is.

Wil je weten welke risico’s via jouw leveranciers binnenkomen, of hoe je zelf aan de eisen van jouw klanten kunt voldoen? Neem contact op voor een vrijblijvend gesprek.

Wat een penetratietest wel en niet laat zien

Een penetratietest, vaak kortweg pentest genoemd, wordt door veel organisaties gezien als het ultieme bewijs dat de beveiliging op orde is. “We hebben een pentest laten doen en die kwam goed door” is een zin die vaak met meer zekerheid wordt uitgesproken dan gerechtvaardigd is.

Een pentest is een waardevol instrument, maar het is geen garantie en geen volledig beeld van de beveiliging van een organisatie. Begrijpen wat een pentest wel en niet doet, voorkomt een vals gevoel van veiligheid.

Wat een pentest is

Bij een penetratietest probeert een gespecialiseerde tester, met toestemming, daadwerkelijk in te breken in systemen, applicaties of netwerken, op dezelfde manier als een kwaadwillende aanvaller dat zou doen. Het doel is concrete, uitbuitbare kwetsbaarheden te vinden voordat een aanvaller dat doet.

Dit onderscheidt een pentest van een kwetsbaarheidsscan, die geautomatiseerd potentiële zwakheden opsomt zonder ze daadwerkelijk te misbruiken. Een pentest gaat verder: de tester probeert daadwerkelijk toegang te krijgen, rechten te verhogen en te bewijzen wat de impact van een kwetsbaarheid in de praktijk is.

Wat een pentest wel laat zien

Concrete, uitbuitbare kwetsbaarheden op het moment van de test. Als een tester via een specifieke route toegang krijgt tot gevoelige data, is dat een onomstotelijk bewijs van een risico, niet een theoretische mogelijkheid.

De praktische impact van een kwetsbaarheid. Een geautomatiseerde scan meldt vaak honderden potentiële issues, waarvan de meeste in de praktijk weinig risico vormen. Een pentest laat zien welke kwetsbaarheden daadwerkelijk te misbruiken zijn en wat een aanvaller er concreet mee kan bereiken.

Hoe systemen samen een aanvalspad vormen. Een individuele kwetsbaarheid lijkt soms onschuldig, maar in combinatie met een andere zwakte kan die de basis vormen voor een volledige inbraak. Pentesters zijn getraind om dit soort ketens van kwetsbaarheden te ontdekken.

De reactie van detectiesystemen. Sommige pentests, met name de meer uitgebreide vormen, testen ook of beveiligingsmonitoring de aanval daadwerkelijk opmerkt. Dat geeft inzicht in hoe goed de organisatie een echte aanval zou detecteren.

Wat een pentest niet laat zien

De staat van beveiliging op andere momenten. Een pentest is een momentopname. Systemen veranderen, nieuwe kwetsbaarheden worden ontdekt, en configuraties wijzigen. Een pentest van zes maanden geleden zegt weinig over de huidige situatie, zeker in een omgeving waar regelmatig nieuwe kwetsbaarheden in software worden gevonden.

Wat buiten de scope van de test viel. Een pentest wordt vrijwel altijd uitgevoerd binnen een vastgestelde scope: bepaalde systemen, applicaties of een specifiek tijdvenster. Een schone uitkomst zegt niets over systemen die niet zijn getest. Organisaties interpreteren een goed pentestresultaat soms te breed, terwijl het alleen geldt voor wat daadwerkelijk is onderzocht.

Menselijke factoren, tenzij specifiek getest. Een technische pentest zegt weinig over hoe medewerkers reageren op social engineering, tenzij dit nadrukkelijk is meegenomen als onderdeel van de opdracht.

Wat een tester niet heeft gevonden. Geen enkele tester vindt alles. De tijd die voor een pentest beschikbaar is, is beperkt, en een gemotiveerde aanvaller met onbeperkte tijd kan dingen ontdekken die een tester binnen de afgesproken periode niet vond. Een schoon rapport is geen garantie van afwezigheid van kwetsbaarheden, het is een indicatie dat de gevonden kwetsbaarheden binnen die scope en tijd zijn opgelost.

Waarom de kwaliteit van de test sterk varieert

Niet elke pentest is gelijk. De kwaliteit hangt sterk af van de ervaring van de tester, de tijd die beschikbaar is gesteld, en de scope die is afgesproken. Een goedkope, oppervlakkige test levert een ander resultaat op dan een uitgebreide test door een ervaren team met voldoende tijd.

Een veelvoorkomende valkuil is het kiezen van een pentest puur om aan een compliance-eis te voldoen, met als gevolg dat de scope minimaal wordt gehouden om kosten te besparen. Dat levert een rapport op dat voldoet aan de formele eis, maar weinig zegt over de werkelijke weerbaarheid van de organisatie.

Hoe een pentest wel waarde toevoegt

Een pentest werkt het best als onderdeel van een breder, continu proces, niet als eenmalige exercitie. Een paar aanbevelingen:

Herhaal regelmatig. Een jaarlijkse test is een redelijk uitgangspunt voor de meeste organisaties, met aanvullende tests na grote wijzigingen in de IT-omgeving.

Wees expliciet over de scope. Begrijp en bespreek vooraf wat wel en niet wordt getest, zodat de uitkomst correct wordt geïnterpreteerd.

Volg op wat er wordt gevonden. Het echte werk begint na de test: de gevonden kwetsbaarheden daadwerkelijk verhelpen. Een pentestrapport dat in een la verdwijnt, heeft geen waarde.

Combineer met andere maatregelen. Een pentest is één van meerdere instrumenten, naast bijvoorbeeld continue kwetsbaarheidsscans, patchbeheer en monitoring. Het vervangt deze niet, het vult ze aan.

Wat RiskGuard hierin doet

RiskGuard begeleidt organisaties bij het opzetten van pentests met een scope die daadwerkelijk relevant is, en helpt bij het structureel opvolgen van de bevindingen. We plaatsen een pentest in de context van een bredere, doorlopende beveiligingsaanpak in plaats van een eenmalig vinkje.

Wil je weten of een pentest voor jouw organisatie het juiste instrument is, en hoe je de meeste waarde uit de uitkomst haalt? Neem contact op voor een vrijblijvend gesprek.

Multifactorauthenticatie: de meest onderschatte beveiligingsmaatregel

Als er één maatregel is die de veel impact heeft tegen de minste kosten en inspanning, is het multifactorauthenticatie, vaak afgekort tot MFA. Toch staat het bij veel organisaties nog niet overal aan, of wordt het gezien als een vervelende extra stap in plaats van een fundamentele beveiligingslaag.

Dat is een gemiste kans, want de cijfers zijn overtuigend. Microsoft rapporteerde dat MFA meer dan 99 procent van de account-gerichte aanvallen blokkeert. Geen enkele andere losse maatregel komt in de buurt van dat effect tegen die inspanning.

Wat MFA precies doet

Een wachtwoord is, op zichzelf, een zwakke verdediging. Wachtwoorden worden gestolen via phishing, hergebruikt over meerdere diensten, of simpelweg geraden als ze te eenvoudig zijn. Zodra een aanvaller een wachtwoord heeft, heeft hij toegang.

MFA voegt een tweede, onafhankelijke verificatiestap toe. Naast iets dat je weet, het wachtwoord, moet je ook iets bewijzen dat je hebt, zoals een code op je telefoon, of iets dat je bent, zoals een vingerafdruk. Een aanvaller die het wachtwoord heeft gestolen, komt niet binnen zonder ook die tweede factor te bezitten.

Dat is waarom MFA zo effectief is tegen de meest voorkomende aanvalsmethode: gestolen of geraden inloggegevens. Het wachtwoord alleen is niet langer genoeg.

Niet elke vorm van MFA is gelijk

Een belangrijke nuance: niet alle MFA-methoden bieden dezelfde bescherming.

SMS-codes zijn beter dan geen MFA, maar wel de zwakste vorm. Aanvallers kunnen via social engineering bij telefoonproviders, een techniek die sim swapping wordt genoemd, een telefoonnummer overnemen en zo de SMS-code onderscheppen.

Authenticator-apps, die een tijdelijke code genereren op een apparaat, zijn aanzienlijk veiliger dan SMS, omdat ze niet afhankelijk zijn van het telefoonnetwerk.

Push-notificaties, waarbij een gebruiker een melding op zijn telefoon goedkeurt, zijn gebruiksvriendelijk maar gevoelig voor een specifieke aanvalsvorm: MFA-fatigue, waarbij een aanvaller herhaaldelijk inlogpogingen doet in de hoop dat een vermoeide gebruiker per ongeluk goedkeurt.

Hardware-sleutels en passkeys bieden de sterkste bescherming. Deze methoden zijn fysiek gebonden aan een apparaat en vrijwel niet op afstand te onderscheppen of te misleiden.

Voor de meeste organisaties is een authenticator-app een goede balans tussen veiligheid en gebruiksgemak. Voor systemen met de hoogste gevoeligheid, zoals beheerdersaccounts, is een hardware-sleutel of passkey de voorkeur.

Waarom organisaties het toch niet overal inschakelen

Als MFA zo effectief is, waarom staat het dan niet overal aan? De meest gehoorde redenen zijn gebruiksgemak en weerstand van medewerkers. Een extra stap bij het inloggen wordt als hinderlijk ervaren, vooral als het systeem niet goed is ingericht en gebruikers bij elke handeling opnieuw moeten verifiëren.

Die weerstand is grotendeels op te lossen met een goede inrichting. Moderne MFA-systemen onthouden vertrouwde apparaten voor een bepaalde periode, vragen alleen om herverificatie bij verdachte signalen, zoals een nieuwe locatie of apparaat, en kunnen worden gecombineerd met single sign-on, zodat een gebruiker maar één keer per dag de extra stap doorloopt in plaats van bij elke applicatie afzonderlijk.

Een andere reden is simpelweg prioriteit. MFA wordt vaak gezien als een project dat “nog moet gebeuren”, zonder dat iemand er concreet verantwoordelijk voor is. Gezien het bewezen effect, verdient dit een hogere plek op de prioriteitenlijst dan het in de praktijk vaak krijgt.

Waar te beginnen als het nog niet overal aanstaat

Niet elk systeem heeft dezelfde urgentie. Een logische volgorde:

E-mail eerst. E-mailaccounts zijn vaak de ingang naar de rest van de organisatie, omdat wachtwoordresets van andere systemen via e-mail lopen. Dit is meestal de eerste prioriteit.

Beheerdersaccounts. Accounts met verhoogde rechten zijn het meest waardevol voor een aanvaller en moeten als eerste worden beveiligd, idealiter met de sterkste vorm van MFA die beschikbaar is.

Externe toegang. VPN-verbindingen en externe toegangspunten tot het bedrijfsnetwerk zijn een directe ingang voor aanvallers van buiten en verdienen prioriteit boven interne systemen.

Cloudapplicaties. Diensten zoals Microsoft 365 of Google Workspace bevatten vaak grote hoeveelheden bedrijfsgegevens en zijn rechtstreeks vanaf het internet bereikbaar.

De rest van de organisatie. Zodra de meest kritieke systemen zijn beveiligd, kan MFA breder worden uitgerold naar overige applicaties en systemen.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties MFA in te richten op een manier die zowel veilig als praktisch werkbaar is, met aandacht voor de juiste prioritering en een implementatie die weerstand bij medewerkers minimaliseert. We beoordelen welke systemen het grootste risico vormen en stellen een realistisch uitrolplan op.

Wil je weten waar in jouw organisatie MFA nog ontbreekt en wat de prioriteit zou moeten zijn? Neem contact op voor een vrijblijvend gesprek.

Wat is een incidentresponsplan en waarom heeft elke organisatie er een nodig

Een incidentresponsplan klinkt als iets voor grote, technisch volwassen organisaties. In de praktijk is het precies het tegenovergestelde: hoe kleiner de organisatie en hoe minder reserves er zijn om een crisis op te vangen, hoe belangrijker een goed plan is.

Een incidentresponsplan is, in de kern, een document dat vastlegt wat een organisatie doet op het moment dat er een beveiligingsincident plaatsvindt. Niet als theoretische exercitie, maar als praktisch draaiboek dat tijdens een crisis daadwerkelijk wordt gevolgd.

Waarom dit niet hetzelfde is als “wel zien wanneer het gebeurt”

De gedachte “we lossen het op als het zich voordoet” klinkt praktisch, maar werkt averechts in een crisis. Onder druk, met systemen die niet werken en klanten die bellen, neemt iedereen impulsieve beslissingen. Onderzoek naar incidentrespons laat consistent zien dat organisaties zonder vooraf vastgelegd plan trager herstellen en hogere kosten maken dan organisaties met een geoefend plan.

Het verschil zit niet in technische kennis, maar in voorbereiding. Wie van tevoren heeft nagedacht over wie wat doet, wie beslist en hoe gecommuniceerd wordt, verliest geen tijd aan het uitvinden van die antwoorden terwijl de klok doortikt.

De onderdelen van een werkend plan

Een ouderwets stukje papier. Als je systemen eruit liggen wil je dat je alsnog wel je responsplan kunnen gebruiken, het beste advies is daarom ook: zorg dat je ze letterlijk op papier hebt.

Een duidelijk crisisteam met vastgelegde rollen. Wie neemt de leiding? Wie communiceert naar klanten? Wie is het aanspreekpunt voor IT-leveranciers of forensisch onderzoek? Deze rollen moeten vooraf zijn toegewezen aan specifieke personen, niet aan functies in algemene zin. Een plan dat zegt “de IT-manager regelt dit” werkt niet als die persoon op vakantie is.

Classificatie van incidenten. Niet elk incident is even ernstig. Een plan moet onderscheid maken tussen kleinschalige incidenten die binnen het team worden opgelost, en grootschalige incidenten die het bestuur en mogelijk externe partijen vereisen. Deze classificatie bepaalt welk escalatieniveau wordt geactiveerd.

Contactgegevens die up-to-date zijn. Een lijst met telefoonnummers van het crisisteam, de IT-leverancier, een forensisch onderzoeksbureau, juridisch advies en, indien relevant, de cyberverzekeraar. Deze lijst moet ook werken als de reguliere systemen, zoals e-mail, niet beschikbaar zijn.

Een communicatiestrategie. Wat communiceer je naar medewerkers, klanten, leveranciers en mogelijk de media? Wie is woordvoerder? Een ongecoördineerde communicatie tijdens een crisis vergroot de reputatieschade aanzienlijk meer dan het incident zelf.

Meldprocedures richting toezichthouders. Bij een datalek geldt onder de AVG een meldtermijn van 72 uur richting de Autoriteit Persoonsgegevens. Onder de aankomende Cyberbeveiligingswet gelden voor bepaalde organisaties nog kortere termijnen. Het plan moet beschrijven wie verantwoordelijk is voor deze melding en hoe die wordt voorbereid.

Technische herstelstappen. Welke systemen worden eerst herstart, welke back-ups worden gebruikt, en wie voert deze stappen uit? Dit onderdeel wordt meestal door IT opgesteld, maar moet wel zijn afgestemd op de prioriteiten die het bestuur heeft vastgesteld over welke processen het meest kritiek zijn.

De stap die het vaakst wordt overgeslagen: oefenen

Een plan op papier is nuttig, maar onvoldoende. De organisaties die het snelst herstellen na een incident, zijn vaak degenen die hun plan periodiek hebben getest met een tabletop-oefening: een gesimuleerd scenario waarbij het crisisteam doorloopt wat ze zouden doen, zonder dat er daadwerkelijk iets misgaat.

Tijdens zo’n oefening komen vrijwel altijd hiaten naar boven. Een contactpersoon die niet meer bij de organisatie werkt. Een back-up waarvan niemand weet hoe die precies wordt teruggezet. Een beslissing over het al dan niet betalen van losgeld waarover het bestuur nog nooit heeft gesproken. Het is veel beter om deze hiaten te ontdekken tijdens een rustige oefening dan tijdens een daadwerkelijke crisis.

Wie is hier verantwoordelijk voor?

Net als bij patchbeheer is incidentrespons een onderwerp dat verder gaat dan IT. Het bestuur is verantwoordelijk voor de uiteindelijke besluitvorming tijdens een crisis, met name bij vragen die buiten het technische domein vallen: wel of geen losgeld betalen, wanneer klanten te informeren, en wanneer externe partijen zoals de politie of toezichthouders te betrekken.

Onder de Cyberbeveiligingswet wordt deze verantwoordelijkheid ook formeel: bestuurders moeten kunnen aantonen dat ze betrokken zijn bij het beleid rondom incidentrespons, niet alleen bij de uitvoering ervan.

Een eenvoudig startpunt

Organisaties die nog geen plan hebben, hoeven niet meteen een uitgebreid document op te stellen. Een goed startpunt is het beantwoorden van een paar fundamentele vragen: wie bel je als eerste als er iets misgaat, wat is onze meest kritieke data en systeem, en wanneer is de laatste keer dat onze back-up daadwerkelijk is getest door die terug te zetten? De antwoorden op die drie vragen leggen vaak al de grootste hiaten bloot.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties een incidentresponsplan op te stellen dat past bij hun omvang en risicoprofiel, en begeleidt tabletop-oefeningen om te testen of het plan in de praktijk werkt. Geen generiek document, maar een plan dat aansluit op hoe de organisatie daadwerkelijk functioneert.

Wil je weten of jullie incidentresponsplan stand zou houden tijdens een echte crisis? Neem contact op voor een vrijblijvend gesprek.

Phishing herkennen is niet genoeg: waarom bewustwordingstrainingen vaak falen

Veel organisaties hebben een verplichte cybersecurity-training ingericht. Medewerkers krijgen een online module, leren een phishingmail te herkennen, halen een certificaat en dat is het dan, tot de volgende verplichte ronde. Het probleem: dit type training verandert weinig aan het werkelijke risico.

Dat is geen kritiek op het idee van bewustwording. Mensen zijn vaak de eerste verdedigingslinie, en onwetendheid is een reëel risico. Het probleem zit in de uitvoering: veel trainingen zijn ingericht om een vakje af te tikken, niet om gedrag daadwerkelijk te veranderen.

Waarom de standaardaanpak niet werkt

Eenmalige kennis beklijft niet. Een jaarlijkse training waarin iemand leert wat phishing is, zorgt voor kortstondige alertheid. Na een paar weken zakt die alertheid weg, terwijl de dreiging continu aanwezig is. Kennis die niet wordt herhaald of toegepast, verdwijnt.

De training mist context. Veel modules zijn generiek en gaan over phishing in algemene zin, zonder rekening te houden met hoe aanvallen in de praktijk van die specifieke organisatie eruitzien. Een medewerker die leert op “verdachte e-mails” te letten, herkent een goed nagemaakte factuur van een bekende leverancier vaak niet als risico.

Schuld in plaats van leren. Trainingen die vooral gericht zijn op het wijzen naar medewerkers die “fouten maken”, creëren een cultuur waarin incidenten worden verzwegen uit angst voor consequenties. Een medewerker die op een phishinglink heeft geklikt en dat niet meldt uit schaamte, is gevaarlijker dan een medewerker die wel klikt maar het direct meldt.

Aanvallen worden geavanceerder, trainingen niet. Phishingmails zien er steeds professioneler uit. AI-gegenereerde teksten zonder taalfouten, perfect nagemaakte huisstijlen, en steeds vaker spear phishing: gerichte aanvallen op specifieke personen met voorkennis over hun functie of werkzaamheden. Veel standaardtrainingen zijn niet bijgewerkt om deze ontwikkeling te weerspiegelen.

Wat aanvallers daadwerkelijk doen

Het is nuttig om te begrijpen waarom social engineering, het misleiden van mensen in plaats van systemen, zo effectief blijft. Aanvallers maken gebruik van psychologische principes die niet veranderen door een trainingsmodule: urgentie, autoriteit, en de wens om collegiaal en behulpzaam te zijn.

Een e-mail die zogenaamd van de directeur komt en om een spoedoverboeking vraagt, werkt omdat de combinatie van autoriteit en urgentie mensen ertoe aanzet snel te handelen zonder kritisch na te denken. Een telefoontje van iemand die zich voordoet als IT-support en vraagt om even snel in te loggen, werkt omdat mensen geneigd zijn behulpzaam te zijn richting collega’s.

Dit soort aanvallen herkennen vraagt niet om kennis van technische signalen, maar om een ingesleten gewoonte: bij ongebruikelijke verzoeken, hoe legitiem ze ook lijken, een moment pauzeren en verifiëren.

Wat dan wel werkt

Een cultuur van melden, niet van schuld. De belangrijkste verschuiving is het belonen van het melden van verdachte signalen, ongeacht of iemand er zelf op is ingegaan. Een organisatie waar medewerkers zich vrij voelen om te zeggen “ik denk dat ik op iets verkeerds heb geklikt” heeft een aanzienlijk kortere reactietijd bij een daadwerkelijk incident dan een organisatie waar dat wordt verzwegen.

Technische maatregelen als vangnet. Bewustwording is een laag, niet de enige verdediging. E-mailfiltering, multifactorauthenticatie en duidelijke procedures voor het verifiëren van financiële verzoeken vangen op wat training niet voorkomt. Geen enkele organisatie moet volledig vertrouwen op menselijk gedrag als enige beveiligingsmaatregel.

Korte, frequente momenten in plaats van lange sessies. Een kort, terugkerend moment van vijf minuten heeft meer effect op gedragsverandering dan een uitgebreide jaarlijkse sessie. Herhaling in kleine doses beklijft beter dan eenmalige volledige onderdompeling.

De rol van leidinggevenden

Bewustwording wordt sterker als het voorbeeld van boven komt. Een leidinggevende die zelf phishingsimulaties serieus neemt, openlijk meldt als hij twijfelt over een e-mail, en niet uitwijkt naar onveilige werkwijzen om tijd te besparen, zet de toon voor de rest van de organisatie. Beleid dat alleen op papier bestaat maar in de praktijk wordt genegeerd door het management, ondermijnt elke trainingsinspanning.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties bewustwording inrichten op een manier die daadwerkelijk effect heeft: realistische simulaties, een cultuur van melden in plaats van schuld, en trainingen die aansluiten op de werkelijke risico’s van de organisatie. Geen vinkje, maar een structurele verbetering van het menselijke aspect van beveiliging.

Wil je weten hoe weerbaar jouw organisatie werkelijk is tegen social engineering? Neem contact op voor een vrijblijvend gesprek.

Patchbeheer als bestuurlijk risico, niet alleen een IT-taak

Patchbeheer wordt in vrijwel elke organisatie gezien als een operationele taak. De IT-afdeling installeert updates, lost kwetsbaarheden op, en het bestuur hoort er zelden iets over, tenzij het misgaat. Die verdeling klopt niet meer.

De afgelopen maanden zijn er meerdere ernstige kwetsbaarheden in veelgebruikte software publiek gemaakt, sommige actief misbruikt nog voordat een patch beschikbaar was. Dat patroon legt een zwakte bloot die niets te maken heeft met technische kennis, maar alles met besluitvorming: hoe snel kan een organisatie reageren als er iets misgaat, en wie is daar verantwoordelijk voor?

Waarom patchbeheer vaak misgaat

Patchbeheer klinkt eenvoudig: er komt een update, je installeert die, klaar. In de praktijk is het een stuk complexer, en de reden waarom het misgaat, is zelden gebrek aan technische kennis.

Prioriteitenconflict. Een update installeren kan systemen tijdelijk verstoren. IT-afdelingen wegen voortdurend af tussen beveiligingsrisico en operationele continuïteit. Zonder duidelijke richtlijnen vanuit het bestuur over welk risico zwaarder weegt, wordt die afweging ad hoc gemaakt, en vaak in het voordeel van continuïteit.

Ontbrekend overzicht. Veel organisaties weten niet precies welke systemen, applicaties en apparaten ze in gebruik hebben. Zonder een actueel overzicht is het onmogelijk om te weten welke systemen een update nodig hebben.

Verantwoordelijkheid die niemand heeft. In veel organisaties is patchbeheer een taak die “erbij” wordt gedaan, zonder dat iemand er expliciet op wordt afgerekend. Als niemand verantwoordelijk is voor de snelheid van patchen, gebeurt het wanneer er tijd is, niet wanneer het nodig is.

Leveranciersafhankelijkheid. Niet elke organisatie beheert haar eigen systemen. Een deel van het patchproces ligt bij hosting- of IT-dienstverleners. Zonder duidelijke afspraken over reactietijden, blijft onduidelijk wie waarvoor verantwoordelijk is op het moment dat het telt.

Waarom dit een bestuurlijk vraagstuk is

Patchbeheer raakt direct aan continuïteit, aansprakelijkheid en reputatie. Dat zijn drie onderwerpen die wel degelijk op het bord van het bestuur liggen.

Onder de aankomende Cyberbeveiligingswet, de Nederlandse uitwerking van NIS2, wordt deze verantwoordelijkheid ook formeel vastgelegd. Bestuurders van organisaties die onder de wet vallen, moeten kunnen aantonen dat ze toezicht houden op risicobeheer, inclusief de snelheid waarmee kwetsbaarheden worden verholpen. Onwetendheid is geen verdediging, en zeker geen rechtvaardiging.

Daarnaast is er een eenvoudige rekensom. De kosten van een gemiste patch, in de vorm van een succesvolle aanval, zijn doorgaans een veelvoud van de kosten om het patchproces goed in te richten. Dat maakt dit niet alleen een compliance-vraagstuk, maar ook een financiële afweging die op bestuursniveau thuishoort.

Wat een bestuur concreet kan en moet vragen

Een bestuur hoeft geen technische details te begrijpen om hier grip op te krijgen. Een aantal vragen die elk bestuur periodiek aan de IT-organisatie of leverancier zou moeten stellen:

Hoe snel installeren wij kritieke updates, gemiddeld? Niet “we patchen regelmatig”, maar een concreet getal. Dagen, weken? Die snelheid is een directe indicator van risico.

Welke systemen hebben prioriteit en waarom? Niet elk systeem is even kritiek. Een bestuur moet weten welke systemen het meeste risico vormen bij uitval, en of het patchbeleid daar rekening mee houdt.

Wie is verantwoordelijk als een patch wordt gemist? Niet om iemand de schuld te geven, maar om te zorgen dat er een duidelijke verantwoordelijkheidsstructuur is, ook bij externe leveranciers.

Hebben we een actueel overzicht van al onze systemen? Zonder dit overzicht, vaak een asset-inventaris genoemd, is structureel patchbeheer onmogelijk. Dit is een van de eerste dingen die in een audit wordt gecontroleerd.

Wat doen we als er een kwetsbaarheid bekend wordt zonder beschikbare patch? Een zero-day situatie vraagt om een ander proces dan een reguliere update. Heeft de organisatie een plan voor tijdelijke mitigatie terwijl een definitieve oplossing nog niet beschikbaar is?

Een proces, geen vinkje

De valkuil bij patchbeheer is het behandelen als eenmalige exercitie: het systeem wordt bijgewerkt, en daarmee is de taak afgerond. In werkelijkheid is het een continu proces. Nieuwe kwetsbaarheden worden voortdurend ontdekt, en de snelheid waarmee aanvalscode publiek wordt, is de afgelopen jaren toegenomen.

Organisaties die hier structureel mee omgaan, hebben doorgaans een aantal elementen gemeen: een actueel overzicht van systemen, een duidelijke prioritering op basis van risico, vastgelegde reactietijden per risiconiveau, en periodieke rapportage aan het bestuur over de status. Niet om het bestuur te belasten met technische details, maar om het inzicht te geven dat nodig is om verantwoordelijkheid te kunnen nemen.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties patchbeheer van een operationele bijzaak naar een gestructureerd proces te brengen, met heldere rapportage richting het bestuur. We brengen het huidige proces in kaart, identificeren waar de risico’s zitten en ondersteunen bij het inrichten van een aanpak die past bij de omvang en het risicoprofiel van de organisatie.

Wil je weten hoe jullie patchproces er voor staat en welke risico’s daarin verborgen zitten? Neem contact op voor een vrijblijvend gesprek.

Wat een cyberverzekering wel en niet dekt

Steeds meer organisaties sluiten een cyberverzekering af. Dat is een logische stap, want de financiële gevolgen van een incident kunnen groot zijn. Het probleem ontstaat zodra een organisatie de verzekering ziet als vervanging van beveiligingsbeleid, in plaats van als aanvulling erop.

Dat onderscheid is belangrijker dan het lijkt, en het wordt vaak pas duidelijk op het moment dat het te laat is: bij het indienen van een claim.

Waarom verzekeraars steeds strenger worden

Cyberverzekeraars hebben de afgelopen jaren fors meer uitbetaald dan ze hadden voorzien. Ransomware-aanvallen, datalekken en bedrijfsonderbreking door cyberincidenten zijn vaker voorgekomen en hebben hogere schadebedragen opgeleverd dan de premies dekten. Het gevolg: verzekeraars stellen scherpere eisen aan de organisaties die ze verzekeren.

Waar een paar jaar geleden een vragenlijst van een pagina voldoende was, vragen verzekeraars nu om concreet bewijs van genomen maatregelen. Multifactorauthenticatie, een actueel patchbeleid, segmentatie van het netwerk, een werkend back-upproces: dit zijn geen suggesties meer, maar voorwaarden voor dekking.

Wie deze eisen niet kan aantonen, betaalt een hogere premie, krijgt een lagere dekking, of wordt simpelweg niet verzekerd.

Wat een polis vaak niet dekt

Een cyberverzekering wekt soms de indruk dat alle financiële gevolgen van een incident worden afgedekt. In de praktijk zijn er belangrijke uitsluitingen die organisaties pas ontdekken als het te laat is.

Verlies door nalatigheid

Als een organisatie kan aantonen dat ze structureel heeft nagelaten basismaatregelen te nemen, bijvoorbeeld het niet installeren van bekende beveiligingsupdates, kan een verzekeraar de claim afwijzen. De polis dekt risico, niet onachtzaamheid.

Reputatieschade

De financiële impact van klantverlies, een dalende beurskoers of een verslechterde concurrentiepositie is zelden volledig gedekt. Verzekeraars vergoeden doorgaans de directe kosten van een incident, niet de langetermijngevolgen voor de marktpositie.

Boetes en sancties

Boetes die door toezichthouders worden opgelegd, bijvoorbeeld onder de AVG of straks de Cyberbeveiligingswet, zijn in veel polissen uitgesloten of slechts beperkt gedekt. De gedachte achter deze uitsluiting: een verzekering mag niet fungeren als vrijwaring voor het overtreden van de wet.

Statelijke aanvallen

Veel polissen bevatten een uitsluiting voor aanvallen die worden toegeschreven aan statelijke actoren, een zogenaamde “act of war” clausule. Het probleem: attributie van een aanval aan een staat is vaak onduidelijk, wat tot langdurige juridische geschillen kan leiden over de vraag of een incident wel of niet is gedekt.

Verlies van onderhandelingspositie

Sommige polissen vereisen dat de verzekeraar wordt geraadpleegd voordat losgeld wordt betaald of voordat met een aanvaller wordt onderhandeld. Organisaties die zelfstandig handelen, lopen het risico dat de uiteindelijke kosten niet worden vergoed.

De polis werkt pas als de basis op orde is

Dit is de kern van het probleem met de gedachte dat een verzekering voldoende is: een polis is een vangnet voor onverwachte schade, niet een vervanging voor het beperken van risico. Verzekeraars verwachten, en eisen steeds vaker contractueel, dat een organisatie een redelijk niveau van beveiliging op orde heeft voordat de dekking ingaat.

Dat betekent in de praktijk dat de meeste organisaties hun beveiligingsniveau eerst moeten verbeteren om verzekerbaar te worden, niet andersom. De verzekering is het sluitstuk, niet het startpunt.

Wat verzekeraars in de praktijk vragen

De exacte eisen verschillen per verzekeraar en per sector, maar een aantal voorwaarden komt structureel terug:

Organisaties die deze maatregelen niet op orde hebben, lopen het risico dat een claim wordt afgewezen op basis van onvolledige of onjuiste informatie bij het aanvragen van de polis.

Drie vragen voor bestuurders

Kunnen we de vragenlijst van onze verzekeraar nu eerlijk en volledig invullen? Niet wat we denken dat klopt, maar wat daadwerkelijk aantoonbaar is. Het verschil tussen die twee wordt zichtbaar bij een claim, niet bij het afsluiten van de polis.

Weten we precies wat onze polis wel en niet dekt? Lees de polisvoorwaarden, met name de uitsluitingen. Een goedkope polis met brede uitsluitingen biedt minder zekerheid dan een duurdere polis met een beperkter maar duidelijker dekkingsgebied.

Is onze beveiliging het startpunt of het sluitstuk van ons risicobeleid? Als het antwoord “sluitstuk” is, ligt daar het eerste werk. Een verzekering corrigeert geen structureel gebrek aan beveiliging.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties hun beveiligingsniveau in kaart te brengen en te verbeteren tot een niveau dat aansluit op wat verzekeraars eisen. We ondersteunen bij het beoordelen van polisvoorwaarden in samenhang met de daadwerkelijke beveiligingssituatie, zodat dekking en realiteit op elkaar aansluiten.

Wil je weten of jouw organisatie voldoet aan de eisen van moderne cyberverzekeraars? Neem contact op voor een vrijblijvend gesprek.

NIS2 in de praktijk: wat de toezichthouder echt van je verwacht

De Cyberbeveiligingswet, de Nederlandse uitwerking van de Europese NIS2-richtlijn, staat op het punt in werking te treden. Op 15 april 2026 stemde de Tweede Kamer in met het wetsvoorstel. De wet ligt nu ter goedkeuring voor aan de Eerste Kamer, met 1 juli 2026 als verwachte ingangsdatum. Wie nu nog denkt dat dit ver weg is, rekent verkeerd.

Veel directeuren en bestuurders weten dat NIS2 bestaat. Veel minder weten wat er concreet van hen wordt gevraagd zodra de wet ingaat. Dat onderscheid is belangrijk, want NIS2 is geen technische checklist die je aan de IT-afdeling kunt overdragen. Het is een wet die bestuurders persoonlijk verantwoordelijk maakt.

Twee wetten, niet één

Wat in de discussie over NIS2 vaak ondersneeuwt: de Tweede Kamer stemde op 15 april niet in met één, maar met twee wetsvoorstellen. Naast de Cyberbeveiligingswet (Cbw) is ook de Wet weerbaarheid kritieke entiteiten (Wwke) aangenomen, de Nederlandse implementatie van de Europese CER-richtlijn.

Waar de Cbw zich richt op digitale weerbaarheid, gaat de Wwke over fysieke weerbaarheid: de continuïteit van organisaties die essentiële diensten leveren, zoals energie, water, transport en zorg. Een belangrijk verschil met de Cbw: bij de Wwke bepaal je niet zelf of je onder de wet valt. De verantwoordelijke minister wijst organisaties aan. De regering streeft ernaar beide wetten gelijktijdig in werking te laten treden.

Voor wie geldt dit eigenlijk?

NIS2 onderscheidt twee categorieën organisaties: essentiële entiteiten en belangrijke entiteiten. Het verschil zit in de sector en de omvang van de organisatie. Essentiële entiteiten zitten in sectoren zoals energie, transport, drinkwater, bankwezen, financiële marktinfrastructuur, zorg en digitale infrastructuur. Belangrijke entiteiten zitten onder andere in postdiensten, afvalbeheer, chemie, voedsel, productie van bepaalde goederen en digitale dienstverlening.

Binnen die sectoren geldt de wet in de regel voor middelgrote en grote organisaties: vanaf 50 medewerkers of een jaaromzet van meer dan 10 miljoen euro. Kleinere organisaties kunnen alsnog onder de wet vallen als ze een kritieke rol spelen in hun sector.

Er is nog een derde groep die vaak wordt onderschat: leveranciers. Als jouw organisatie diensten levert aan een partij die onder NIS2 valt, ga je er gegarandeerd mee te maken krijgen. Niet via de wet zelf, maar via de eisen die je klant aan jou gaat stellen. De keten is zo sterk als de zwakste schakel, en die gedachte staat letterlijk aan de basis van de richtlijn.

Twijfel je of jouw organisatie onder de wet valt? De Rijksoverheid heeft hiervoor de NIS2 Zelfevaluatie gelanceerd, waarmee je zelf kunt nagaan aan welke verplichtingen je moet voldoen.

Wat de wet daadwerkelijk vraagt

NIS2 draait om drie verplichtingen: een zorgplicht, een meldplicht en een registratieplicht.

Zorgplicht

De zorgplicht houdt in dat je een risicobeoordeling uitvoert en op basis daarvan passende technische, organisatorische en operationele maatregelen neemt. Dat klinkt abstract, maar het komt neer op een aantal concrete stappen: weten welke systemen en gegevens kwetsbaar zijn, weten wat de gevolgen zijn als die uitvallen of worden gestolen, en vervolgens maatregelen nemen die in verhouding staan tot dat risico.

Dit is geen eenmalige exercitie. De zorgplicht is doorlopend: risico’s veranderen, dus de beoordeling en de maatregelen moeten meebewegen.

Meldplicht

Bij een significant incident geldt een strikte meldtermijn. Een eerste melding moet binnen 24 uur bij de toezichthouder liggen, gevolgd door een uitgebreidere melding binnen 72 uur. Dat is fors sneller dan veel organisaties nu gewend zijn, en het vraagt om een proces dat al klaarstaat voordat er iets misgaat. Een incidentresponsplan dat pas tijdens de crisis wordt opgesteld, voldoet niet.

Registratieplicht

Organisaties die onder de wet vallen, moeten zich registreren bij de toezichthouder. Die registratie geeft de overheid zicht op welke partijen onder de wet vallen en hoe de digitale weerbaarheid er sectorbreed voor staat.

De bestuurlijke verantwoordelijkheid: dit is het deel dat vaak wordt gemist

Het meest onderschatte element van NIS2 is de positie van het bestuur. De wet legt de verantwoordelijkheid voor cyberrisico’s niet bij de IT-afdeling, maar bij het bestuur als geheel. Dat betekent in de praktijk drie dingen.

Ten eerste: bestuurders moeten de genomen maatregelen goedkeuren en toezicht houden op de uitvoering. Niet aftekenen omdat de IT-manager het vraagt, maar daadwerkelijk begrijpen wat er speelt en een afgewogen besluit nemen.

Ten tweede: er geldt een verplichte trainingsplicht voor bestuurders. Je moet als bestuur voldoende kennis hebben om de risico’s en de genomen maatregelen te kunnen beoordelen. Onwetendheid is geen verdediging.

Ten derde, en dit is de kern: bij onvoldoende naleving kan het bestuur persoonlijk aansprakelijk worden gesteld. In ernstige gevallen kan dat leiden tot een bestuursverbod. Daarnaast kunnen de boetes voor de organisatie zelf oplopen tot 10 miljoen euro of 2 procent van de wereldwijde jaaromzet, afhankelijk van wat hoger uitvalt. Dit verschuift cybersecurity van een operationeel onderwerp naar een boardroom-onderwerp.

Hoe ver moet je gaan?

Een veelgestelde vraag is hoeveel een organisatie precies moet doen om te voldoen. Er is geen vaste checklist die voor elke organisatie hetzelfde is, want NIS2 werkt met het principe van passendheid: de maatregelen moeten in verhouding staan tot het risico, de omvang en de aard van de organisatie.

Wat in de praktijk wel als basis geldt:

Organisaties die al werken met ISO 27001 hebben een voorsprong. De normen overlappen voor een groot deel, en een goed ingericht informatiebeveiligingsmanagementsysteem dekt veel van wat NIS2 vraagt.

Waarom nu beginnen, ook al is de wet nog niet officieel in werking

Een redenering die je vaak hoort: de wet is er nog niet, dus we wachten tot die er is. Dat is om twee redenen riskant.

De eerste reden is praktisch. De meeste organisaties hebben vier tot zes maanden nodig om hun cybersecurity en leveranciersbeheer op het vereiste niveau te krijgen. Wie wacht tot de wet ingaat, begint te laat.

De tweede reden is inhoudelijk. Een aantal recente incidenten in Nederland, waaronder grootschalige datalekken bij organisaties die met de overheid samenwerken, laat zien dat het risico niet wacht op wetgeving. Minister Van Weel verwoordde het bij de stemming in de Tweede Kamer treffend: de dreiging van cyberaanvallen en verstoringen is geen abstract risico meer, maar dagelijkse realiteit. De wet is uitgesteld, het risico niet.

Drie vragen om mee te beginnen

  1. Vallen wij onder de Cyberbeveiligingswet, direct of als leverancier? Bepaal je sector, omvang en positie in de keten. Dit is het startpunt van elke verdere stap.
  2. Hebben we een actuele risicobeoordeling? Niet een document van drie jaar geleden, maar een beoordeling die de huidige situatie weerspiegelt en die regelmatig wordt bijgewerkt.
  3. Kan ons bestuur uitleggen welke risico’s we lopen en welke maatregelen we daarvoor hebben genomen? Als het antwoord nee is, ligt daar de eerste prioriteit. Niet bij een nieuwe tool, maar bij bestuurlijke kennis en betrokkenheid.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties NIS2 vertalen naar een praktisch en haalbaar plan. We voeren risicobeoordelingen uit, beoordelen of bestaande maatregelen voldoende zijn, en ondersteunen bij het inrichten van een proces voor leveranciersbeheer en incidentrespons dat aansluit op wat de wet vraagt.

Wil je weten of jouw organisatie onder de Cyberbeveiligingswet valt en waar je nu zou moeten beginnen? Neem contact op voor een vrijblijvend gesprek.