Account takeovers verdrievoudigd: de mens is het aanvalsvlak en dat is meetbaar op te lossen

Twee rapporten verschenen er de afgelopen week. Los van elkaar, maar samen vertellen ze één verhaal. Het eerste is de Datalekkenrapportage 2025 van de Autoriteit Persoonsgegevens. Het tweede is een internationaal benchmarkonderzoek naar phishinggevoeligheid onder bijna 15 miljoen medewerkers. Het eerste rapport laat zien waar het misgaat: bij de mens en zijn account. Het tweede laat zien dat daar aantoonbaar iets aan te doen is. Wie beide naast elkaar legt, heeft geen excuus meer om awareness als afvinkoefening te behandelen.

Wat de AP-cijfers laten zien

De AP ontving vorig jaar ruim 39.000 datalekmeldingen. Iets meer dan het jaar ervoor. Dat totaal is niet het nieuws. Het nieuws zit in de verschuiving eronder.

Het aantal datalekken door cyberaanvallen steeg fors, van zo’n 1500 naar ruim 2400 meldingen. En binnen die categorie springt één aanvalsvorm eruit: de account takeover. Daarbij krijgt een aanvaller toegang tot het account van een medewerker, meestal via phishing. Vanuit dat account wordt data gestolen of een grotere aanval opgezet. In 2024 telde de AP 607 van die gevallen. In 2025 waren het er 1742. Bijna een verdrievoudiging in één jaar.

De AP noemt de stijging zorgelijk en wijst een aanjager aan: kunstmatige intelligentie. Taalmodellen maken het eenvoudig om overtuigende en gepersonaliseerde phishingberichten te schrijven, in foutloos Nederlands en desnoods in de schrijfstijl van je eigen directeur. De klassieke herkenningstips schieten daardoor tekort. Kromme zinnen en rare aanhef zijn geen betrouwbaar signaal meer.

Nog een detail dat er voor mij uitspringt. Eén aanval op één dienstverlener leidde tot duizenden datalekmeldingen bij de organisaties die van die partij afhankelijk waren. Ketenrisico is geen theorie uit een norm. Het staat gewoon in de meldstatistieken van de toezichthouder.

En laten we het grootste cijfer niet vergeten. Bijna twee derde van alle datalekken komt nog altijd door verkeerd geadresseerde post en e-mail. Geen hackers, geen AI. Gewoon menselijke fouten in dagelijkse processen. De mens is dus het aanvalsvlak aan twee kanten tegelijk: als doelwit van steeds betere phishing en als bron van steeds dezelfde vergissingen.

Wat de benchmarkdata laat zien

Tegenover die sombere cijfers staat een rapport dat juist hoop geeft. Een internationale benchmark analyseerde 42 miljoen phishingsimulaties bij 64.000 organisaties. De uitkomst voor Europa: zonder training trapt ruwweg 31 procent van de medewerkers in een phishingtest. Na 90 dagen doorlopende training daalt dat naar zo’n 21 procent. Na een jaar naar ongeveer 5 procent.

Van 31 naar 5 procent. Dat is geen marginale verbetering. Dat is het verschil tussen een organisatie waar bijna een op de drie medewerkers een deur openzet en een organisatie waar dat een uitzondering is.

Er zit nog een opvallende bevinding in de data. Grote organisaties met meer dan 10.000 medewerkers zijn gevoeliger voor phishing dan kleine. Wie denkt dat schaal en een eigen securityafdeling vanzelf bescherming bieden, heeft het mis. Meer medewerkers betekent meer variatie in rollen en risico’s. Een generieke jaarlijkse e-learning bereikt daar niemand echt.

De cijfers bevestigen wat de praktijk al liet zien

Ik schreef eerder op deze site waarom de meeste security awareness trainingen mislukken. De kern van dat verhaal: eenmalig werkt niet, generiek werkt niet en angst werkt niet. Awareness die wel werkt is doorlopend, doelgroepgericht en gemeten.

Deze twee rapporten leveren daar nu de cijfermatige onderbouwing bij. De benchmarkdata laat zien dat het verschil tussen wel en geen effect vrijwel volledig in de aanpak zit. Niet in de vraag of je iets aan awareness doet, maar hoe. Een organisatie die één keer per jaar een e-learning uitrolt, blijft dicht bij die 31 procent hangen. Een organisatie die er een doorlopend ritme van maakt, komt bij die 5 procent uit. Zelfde medewerkers. Ander proces.

En de AP-cijfers laten zien waarom dit urgent is geworden. AI-phishing schaalt aan de kant van de aanvaller. Elke medewerker die een net iets te overtuigende mail krijgt, is een potentiële account takeover. De verdediging kan niet meer leunen op het herkennen van slordige mailtjes. Ze moet leunen op gedrag: verifiëren bij twijfel, snel melden en nooit alleen op een wachtwoord vertrouwen.

Techniek en gedrag zijn geen keuze maar een paar

Laat ik daar scherp in zijn, want dit wordt in de awareness-discussie vaak vergeten. Training vervangt geen techniek. De AP zelf hamert op multifactorauthenticatie op alle accounts, op het detecteren van verdachte inlogpogingen en op het beperken van toegangsrechten. Terecht. Een account takeover die stukloopt op MFA hoeft niet herkend te worden door een oplettende medewerker.

Maar het omgekeerde geldt ook. Techniek zonder gedrag houdt geen stand. MFA-moeheid is inmiddels zelf een aanvalstechniek: medewerkers net zo lang pushmeldingen sturen tot iemand op akkoord drukt. En de tweederde aan datalekken door verkeerd geadresseerde post los je met geen enkele firewall op. Wie de AP-cijfers serieus neemt, investeert in beide: sterke techniek als vangnet en getraind gedrag als eerste linie. In die volgorde van denken, maar tegelijk in uitvoering.

Wat je hiermee doet

Drie concrete stappen, in lijn met wat beide rapporten laten zien.

Meet eerst waar je staat. Een nulmeting met een phishingsimulatie geeft je je eigen startpercentage. Zonder dat cijfer stuur je blind en kun je over een jaar niet aantonen dat je aanpak werkt. En aantoonbaarheid is onder de Cyberbeveiligingswet geen vrijblijvendheid meer.

Zet MFA op alles en richt detectie van verdachte inlogpogingen in. Dit is de snelste manier om de schade van een gestolen wachtwoord te beperken. De account takeover-cijfers van de AP zijn hier het directe argument voor richting je bestuur.

En maak van awareness een ritme in plaats van een evenement. Kort en regelmatig. Toegespitst op rollen. Met melden als belangrijkste gedrag dat je beloont. De benchmarkdata laat zien wat dat oplevert en binnen welke termijn. Gebruik die cijfers gerust in je eigen businesscase.

Tot slot

De mens is het aanvalsvlak geworden. Dat is geen mening maar meldstatistiek: account takeovers verdrievoudigden in een jaar en AI maakt de aanvallen alleen maar overtuigender. Tegelijk is nu met ongekende schaal aangetoond dat gedrag trainbaar is, mits je het goed aanpakt. Van 31 naar 5 procent in een jaar. De vraag is dus niet meer of awareness werkt. De vraag is of jouw organisatie het doet op de manier die werkt.

Ronald Everduim is zelfstandig ISO-consultant, CISO-adviseur en ITIL 4 Master. Hij heeft ruim twintig jaar ervaring in IT en IT-servicemanagement en is sinds 2015 gespecialiseerd in informatiebeveiliging. Hij begeleidt organisaties bij awareness, ISO 27001, NEN 7510 en de Cyberbeveiligingswet.

Nederland voor het EU-Hof om NIS2: wat de vertraging van de overheid jou leert

De timing kon niet pijnlijker. Op 7 juli nam de Eerste Kamer de Cyberbeveiligingswet aan. Eén dag later maakte de Europese Commissie bekend dat ze Nederland voor het Hof van Justitie van de EU daagt. De reden: het niet op tijd omzetten van de NIS2-richtlijn in nationale wetgeving. De Commissie vraagt het Hof om financiële sancties. Een boete plus een dwangsom per dag totdat Nederland formeel voldoet.

Nederland is 21 maanden te laat. De deadline voor omzetting was 17 oktober 2024. We staan in de Europese achterhoede, samen met Frankrijk, Spanje en Ierland. Van alle 27 lidstaten had alleen België de richtlijn volledig op tijd omgezet.

Je kunt hier schamper over doen. Dat gebeurt in het vakgebied dan ook volop. Maar ik vind het interessanter om de spiegel om te draaien. Want wat de Nederlandse overheid hier overkomt, is precies wat veel organisaties de komende jaren zelf gaat overkomen. Alleen dan met een andere toezichthouder aan de deur.

Hoe het zo ver kwam

De NIS2-richtlijn is niet uit de lucht komen vallen. Hij is in januari 2023 in werking getreden. De omzettingsdeadline stond bijna twee jaar van tevoren vast. Toch verliep die deadline zonder Nederlandse wet.

Daarna volgde het bekende patroon. In november 2024 stuurde de Commissie een formele ingebrekestelling. In mei 2025 volgden dringende adviezen. Nederland bleef in het wetgevingstraject hangen. En nu, in juli 2026, is de zaak bij het Hof beland. Terwijl de Cyberbeveiligingswet nota bene al was aangenomen.

Herken je het patroon? Deadline bekend. Ruim de tijd. Andere prioriteiten. Eerste waarschuwing genegeerd. Tweede waarschuwing genegeerd. En dan opeens handhaving, op het moment dat je net dacht dat je er bijna was. Dit is exact hoe het bij organisaties gaat die compliance voor zich uit schuiven. De overheid is hierin geen uitzondering. Ze is het schoolvoorbeeld.

Komt Nederland ermee weg?

Waarschijnlijk grotendeels wel. De praktijk bij dit soort inbreukprocedures is dat lidstaten de wetgeving alsnog invoeren terwijl de zaak loopt. De Commissie trekt de zaak dan vaak in voordat het Hof uitspraak doet. De Cyberbeveiligingswet treedt op 15 augustus in werking. Grote kans dat de angel er dan snel uit is.

Maar let op wat hier gebeurt. Niet de goede bedoelingen telden. Niet het feit dat er hard aan werd gewerkt. Wat telt is het formele moment waarop je aantoonbaar voldoet. Tot die tijd loopt de procedure gewoon door en tikt de potentiële dwangsom.

Dat is een les die je één op één kunt vertalen naar je eigen organisatie.

Drie lessen voor je eigen organisatie

Les 1: de deadline was nooit het probleem. De start was het probleem.

Nederland had bijna twee jaar. Dat bleek niet genoeg, omdat het traject te laat op stoom kwam. Organisaties maken dezelfde fout. Ze rekenen terug vanaf de deadline en concluderen dat er nog tijd is. Maar een risicoanalyse, een leveranciersinventarisatie en een werkend meldproces bouw je niet in de laatste weken. Wie pas beweegt als de deadline zichtbaar wordt, is per definitie te laat begonnen.

Les 2: onderweg zijn is niet hetzelfde als voldoen. Maar het scheelt wel.

De formele toets is hard: voldoe je of voldoe je niet. Toch is er een verschil tussen een partij die aantoonbaar bezig is en een partij die heeft stilgezeten. Dat zie je in de Europese procedure en dat ga je ook zien bij het toezicht op de Cyberbeveiligingswet. Een toezichthouder die op 16 augustus langskomt, verwacht geen perfectie. Wel een organisatie die weet waar ze staat, een onderbouwd plan heeft en kan laten zien wat er al loopt. Documenteer je voortgang. Het is je beste verdediging in de periode dat je er nog niet bent.

Les 3: verantwoordelijkheid verschuift niet door te wijzen.

Er valt genoeg af te dingen op het Nederlandse wetstraject. Organisaties die straks onder de wet vallen, hebben daardoor korter de tijd gehad om zich op de definitieve tekst voor te bereiden. Dat is een terecht verwijt. Maar het verandert niets aan je eigen verplichting. De richtlijn en haar eisen zijn al sinds 2023 bekend. Wie heeft gewacht op Den Haag, heeft zijn eigen voorbereiding aan een ander opgehangen. Dat is precies de houding die de wet bij besturen wil doorbreken: cyberrisico’s zijn je eigen verantwoordelijkheid en die kun je niet uitbesteden. Niet aan een leverancier en ook niet aan een trage wetgever.

Wat dit betekent voor de komende maanden

De inwerkingtreding op 15 augustus staat vast. De toezichthouders staan klaar. En Nederland heeft er nu zelf ervaring mee hoe het voelt als een toezichthouder de formele weg bewandelt terwijl je bijna klaar bent.

Mijn advies is hetzelfde als bij de aanname van de wet: begin nu, werk planmatig en maak je voortgang aantoonbaar. Stel vast of je onder de wet valt. Bereid je registratie bij het NCSC voor. Voer je risicoanalyse uit en leg de besluitvorming bij het bestuur. Niet omdat er over vijf weken een inspecteur op de stoep staat. Wel omdat aantoonbaar onderweg zijn het verschil maakt tussen een gesprek en een sanctie.

De overheid kreeg 21 maanden respijt en alsnog een rechtszaak. Reken er niet op dat jouw organisatie meer coulance krijgt.

Ronald Everduim is zelfstandig ISO-consultant, CISO-adviseur en ITIL 4 Master. Hij heeft ruim twintig jaar ervaring in IT en IT-servicemanagement en is sinds 2015 gespecialiseerd in informatiebeveiliging. Hij begeleidt organisaties bij ISO 27001, NEN 7510 en de voorbereiding op de Cyberbeveiligingswet.

Cyberbeveiligingswet aangenomen: wat NIS2 vanaf 15 augustus echt van je vraagt

Het is definitief. Op 7 juli heeft de Eerste Kamer ingestemd met de Cyberbeveiligingswet. Dit is de Nederlandse implementatie van de Europese NIS2-richtlijn. De wet treedt op 15 augustus 2026 in werking. Vanaf dat moment gelden voor ruim 8000 Nederlandse organisaties wettelijke verplichtingen op het gebied van cyberbeveiliging. Tegelijk is de Wet weerbaarheid kritieke entiteiten aangenomen. Die stelt voor zo’n 500 organisaties in kritieke sectoren aanvullende eisen aan fysieke weerbaarheid.

Nederland is ruimschoots te laat. De Europese deadline verliep al in oktober 2024. Maar dat uitstel is nu voorbij en de overgangsperiode is kort: vijf weken tussen aanname en inwerkingtreding. In dit artikel zet ik op een rij wat de wet vraagt. Daarna behandel ik zes misverstanden die ik in de vakdiscussie steeds terug zie komen. Juist die misverstanden gaan organisaties de komende jaren geld en slaap kosten.

Wat de Cyberbeveiligingswet vraagt

De wet geldt voor organisaties in achttien sectoren die essentiële of belangrijke diensten leveren. Denk aan energie, drinkwater, zorg, digitale infrastructuur, vervoer en delen van de overheid. Belangrijk om te weten: je krijgt geen brief. Elke organisatie moet zelf toetsen of ze onder de wet valt.

De kernverplichtingen zijn:

Registratieplicht. Je organisatie moet zich registreren in het entiteitenregister bij het Nationaal Cyber Security Centrum via mijn.ncsc.nl. Praktische valkuil: daarvoor heb je eHerkenning op het juiste niveau nodig. Dat heeft lang niet iedereen in huis. Regel het nu en niet op 14 augustus.

Zorgplicht. Je moet passende technische en organisatorische maatregelen nemen om de risico’s voor je netwerk- en informatiesystemen te beheersen. Passend betekent: onderbouwd vanuit een risicoanalyse. Niet vanuit een standaardlijstje.

Meldplicht. Significante incidenten moet je tijdig melden bij de bevoegde autoriteit. Voor de eerste melding gelden korte termijnen.

Bestuurdersverantwoordelijkheid. Dit is de grootste verandering. Het bestuur is zelf verantwoordelijk voor het beheersen van cyberrisico’s. Het moet de maatregelen goedkeuren en daarvoor aantoonbaar getraind zijn. Cybersecurity is daarmee wettelijk geen IT-onderwerp meer. Het is een bestuurszaak.

Ketenverantwoordelijkheid. Je bent ook verantwoordelijk voor de risico’s in je toeleveringsketen. Daarover hieronder meer. Hier gaat het in de praktijk vaak mis.

Het toezicht verschilt per categorie. Essentiële entiteiten krijgen proactief toezicht met inspecties. Belangrijke entiteiten krijgen reactief toezicht na incidenten of signalen. De zorgplicht en meldplicht zijn voor beide gelijk.

Zes misverstanden uit de praktijk

Sinds de aankondiging van NIS2 volg ik de discussie onder vakgenoten, bestuurders en IT-professionals. Daarin keren steeds dezelfde denkfouten terug. Ik loop de zes belangrijkste langs.

Misverstand 1: “Wij zijn ISO 27001 gecertificeerd, dus we zijn NIS2-compliant.”

Nee. De overlap is groot en een goed geïmplementeerd ISMS is de beste startpositie die je kunt hebben. Maar het certificaat zelf is geen compliance. De Cyberbeveiligingswet stelt eisen die buiten de norm liggen. Denk aan de registratieplicht, de specifieke meldtermijnen en de wettelijke bestuurdersverantwoordelijkheid inclusief trainingsplicht. Wie ISO 27001 volledig heeft geïmplementeerd, heeft aan de gap-analyse en het dichten van de gaten geen maanden werk. Maar die gap-analyse moet wel gebeuren. En het resultaat moet aantoonbaar zijn.

Misverstand 2: “We certificeren gewoon een klein stukje van de organisatie.”

Scope-shopping heet dat: de reikwijdte van je ISO-certificaat zo smal maken dat de audit makkelijk wordt. Commercieel prikken opdrachtgevers daar al doorheen. De scope staat gewoon op het certificaat. Voor de Cyberbeveiligingswet werkt het helemaal niet. De wet kijkt naar je dienstverlening en niet naar wat jij toevallig hebt laten certificeren. Een toezichthouder houdt zich bij een inspectie niet aan de grenzen van jouw certificaatscope.

Misverstand 3: “Het staat in de cloud, dus dat is de verantwoordelijkheid van de leverancier.”

Dit misverstand hoor ik het vaakst. Tot aan bestuurders van getroffen organisaties in de media toe. Uitbesteden van IT is niet uitbesteden van verantwoordelijkheid. De wet legt de ketenverantwoordelijkheid expliciet bij jou. Je moet de risico’s van je leveranciers en dienstverleners beoordelen en beheersen. Contractueel en aantoonbaar. Valt de dienstverlening van je cloudleverancier uit of wordt die gehackt? Dan is dat jouw incident, jouw meldplicht en jouw verantwoording richting toezichthouder. Wie zijn leveranciersmanagement als ITSM-proces heeft ingericht, heeft hier trouwens een voorsprong. De afspraken, evaluaties en rapportages liggen er dan al.

Misverstand 4: “Het is toch een papieren tijger, er is niet eens een certificeringsschema.”

Deze scepsis begrijp ik en hij is niet helemaal onterecht. Compliance op papier heeft nog nooit een aanval gestopt. Een verplicht NIS2-certificaat bestaat inderdaad niet. Maar de conclusie klopt niet. De wet vraagt niet om een certificaat maar om aantoonbaarheid: dat je maatregelen werken en dat je dat kunt bewijzen. Denk aan geteste back-ups, geoefende incident response, werkende multifactorauthenticatie en risicogebaseerd patchbeheer. Er staan tien bevoegde toezichthouders klaar die proactief en reactief gaan handhaven. Wie zijn beveiliging als papieren exercitie inricht, krijgt precies het probleem dat de sceptici voorspellen. Wie de aantoonbaarheid serieus neemt, houdt er een werkend managementsysteem aan over. Het verschil zit niet in de wet maar in de uitvoering.

Misverstand 5: “NIS2 gaat over IT.”

Voor veel organisaties in de industrie, energie en zorg is de operationele technologie minstens zo relevant als de kantoorautomatisering. Productielijnen, gebouwbeheer, medische apparatuur, procesinstallaties. OT is een ander vakgebied dan IT. Andere risico’s, en de gevolgen kunnen in de fysieke wereld terechtkomen. Een ISMS dat alleen naar de IT-omgeving kijkt, dekt het risicoprofiel van zo’n organisatie niet. Normen als IEC 62443 vullen ISO 27001 daar aan. De wet vraagt om beheersing van jouw risico’s. Liggen die in de fabriekshal? Dan hoort je aanpak daar ook te liggen.

Misverstand 6: “Dit wordt vooral duur en levert niets op.”

De kosten zijn reëel. Laat daar geen misverstand over bestaan. Maar kijk naar België, waar de wet al sinds eind 2024 van kracht is. Zodra bestuurders persoonlijk aanspreekbaar werden op cyberrisico’s, gingen organisaties in hoog tempo professionaliseren. Niet omdat de wet zo mooi geschreven is. Wel omdat de verantwoordelijkheid eindelijk ligt waar hij hoort. Dezelfde beweging gaat hier plaatsvinden. Wie de wet aangrijpt om zijn risicobeheersing echt op orde te brengen, haalt er ook daadwerkelijk weerbaarheid uit. Wie een dossier voor de inspecteur optuigt, heeft alleen de kosten.

Wat je nu moet doen

Vijf weken is kort. Maar het is genoeg om de basis te leggen. In volgorde van prioriteit:

Stel vast of je organisatie onder de wet valt. Direct of via de keten. Bereid je registratie bij het NCSC voor, inclusief de eHerkenning. Voer een eerste risicoanalyse uit en leg vast welke maatregelen je al hebt. Bespreek de uitkomsten met het bestuur en laat de risicoaanpak formeel vaststellen. Dat is vanaf 15 augustus hun wettelijke taak. Breng je leveranciers in kaart en beoordeel de belangrijkste ketenrisico’s. En regel de bestuurstraining. Aantoonbare kennis bij het bestuur is een expliciete eis.

Wie al een ISMS heeft, doet dit grotendeels binnen de bestaande structuur. Ook je serviceprocessen helpen hier. Incidentbeheer, wijzigingsbeheer en leveranciersmanagement zijn precies de plekken waar de wet om aantoonbare beheersing vraagt. Staan die processen, dan ontstaat het bewijs in het dagelijks werk.

Wie nog niets heeft, moet niet proberen om voor 15 augustus alles af te hebben. Dat lukt niet. Zorg wel dat je kunt laten zien dat je bent begonnen. Dat je weet waar je staat en een onderbouwd plan hebt. Een toezichthouder maakt onderscheid tussen een organisatie die serieus onderweg is en een organisatie die heeft afgewacht.

Tot slot

De Cyberbeveiligingswet verandert cybersecurity van een IT-aangelegenheid in een wettelijke bestuursverantwoordelijkheid. Met toezicht en handhaving. De grootste risico’s zitten niet in de wettekst maar in de misverstanden eromheen. Het gelijkstellen van een certificaat aan compliance. Het doorschuiven van verantwoordelijkheid naar de cloud. Het onderschatten van aantoonbaarheid en keten. Wie die valkuilen ontwijkt en de wet gebruikt als aanleiding om de risicobeheersing echt in te richten, is niet alleen compliant maar ook daadwerkelijk weerbaarder. En dat was uiteindelijk de bedoeling.

Ronald Everduim is zelfstandig ISO-consultant, CISO-adviseur en ITIL 4 Master. Hij heeft ruim twintig jaar ervaring in IT en IT-servicemanagement en is sinds 2015 gespecialiseerd in informatiebeveiliging. Hij begeleidt organisaties bij ISO 27001, NEN 7510 en de voorbereiding op NIS2 en de Cyberbeveiligingswet.

Change management dat werkt: snelheid zonder controleverlies

In veel organisaties is change management verworden tot het tegenovergestelde van wat het zou moeten zijn. Wat bedoeld was om risico te beheersen, is een wekelijkse vergadering geworden waar wijzigingen blijven liggen tot iemand er een stempel op zet. De business klaagt over traagheid, IT klaagt over bureaucratie, en ondertussen daalt het aantal incidenten er niet merkbaar door. Als change manager kom ik dit patroon overal tegen. In dit artikel leg ik uit waarom het misgaat en hoe je met ITIL change enablement wel snelheid en controle combineert.

Van change management naar change enablement

Niet voor niets heeft ITIL 4 de naam veranderd. Waar het vroeger “change management” heette, spreekt ITIL 4 over “change enablement”. Dat is geen cosmetische woordkeuze. Het verschil zit in de bedoeling: de rol van het proces is niet om wijzigingen tegen te houden, maar om ze mogelijk te maken tegen een aanvaardbaar risico. Enablement, niet gatekeeping.

Dat onderscheid is precies waar het bij de meeste organisaties fout gaat. Hun proces is nog een poortwachter, ontworpen om nee te zeggen, terwijl het een katalysator zou moeten zijn die ja zegt op een verantwoorde manier.

Waarom de klassieke CAB je vertraagt

De Change Advisory Board is bedoeld als adviesorgaan. In de praktijk is het vaak een verplichte wekelijkse halte geworden waar elke wijziging langs moet, ongeacht risico. Dat levert drie problemen op.

Ten eerste ontstaat er een wachtrij. Een wijziging die dinsdag klaar is, wacht tot de CAB van volgende week donderdag. Die vertraging heeft niets met risico te maken en alles met agenda’s.

Ten tweede is de beoordeling oppervlakkig. Een board die twintig wijzigingen in een uur behandelt, kan er geen enkele echt doorgronden. Wat overblijft is een collectief knikken, geen inhoudelijke risicoafweging.

Ten derde geeft het een vals gevoel van controle. Omdat alles langs de CAB gaat, denkt de organisatie dat het risico beheerst is. Maar een proces dat alles gelijk behandelt, onderscheidt niet tussen een routineuze wachtwoordreset en een migratie van een kernsysteem. Wie geen onderscheid maakt, beheerst niets. Hij vertraagt alleen alles even hard.

Het echte fundament: drie soorten wijzigingen

ITIL onderscheidt drie typen wijzigingen, en het correct toepassen daarvan is de grootste hefboom die je hebt.

Standaardwijzigingen zijn vooraf goedgekeurd. Ze zijn laag in risico, goed begrepen en volgen een vaste procedure. Een nieuwe medewerker een standaard accountset geven is geen zaak voor een board. Die goedkeuring regel je één keer, voor het type wijziging, en daarna niet meer per geval. Dit is waar de meeste snelheidswinst zit, en juist dit type wordt in de praktijk het meest verwaarloosd.

Normale wijzigingen worden per geval beoordeeld en geautoriseerd. Maar let op: beoordeeld op een niveau dat past bij het risico. Een kleine, goed geteste aanpassing hoeft niet naar hetzelfde gremium als een ingrijpende architectuurwijziging.

Spoedwijzigingen moeten direct door, bijvoorbeeld om een groot incident of een acuut beveiligingslek op te lossen. Daar hoort een versneld pad bij, met beoordeling achteraf. Niet minder controle, maar controle op een ander moment.

Het venijn zit in de verhouding. In een gezonde organisatie is het overgrote deel van de wijzigingen standaard en volautomatisch afgehandeld. In een ongezonde organisatie is alles een normale wijziging, en verstopt de CAB.

Risicogebaseerd autoriseren in plaats van één loket

De sleutel is dat je de autorisatie koppelt aan het risico, niet aan een vast gremium. ITIL noemt dat de change authority: degene die een wijziging mag goedkeuren. Die autoriteit hoort te passen bij de impact.

Concreet betekent dat: lage-risicowijzigingen laat je autoriseren door een teamlead of zelfs door een geautomatiseerde regel. Middelgrote wijzigingen door een change manager of een technisch verantwoordelijke. Alleen de echt zware, organisatiebrede wijzigingen verdienen de aandacht van een volledige board. Zo besteed je je schaarste aan beoordelingscapaciteit aan de wijzigingen die er werkelijk toe doen, in plaats van hem uit te smeren over alles.

De CAB is een adviseur, geen stempelmachine

Als je dit goed inricht, verandert de rol van de CAB fundamenteel. Hij beoordeelt niet meer elke wijziging, maar buigt zich over de complexe, risicovolle gevallen waar meerdere belangen en systemen samenkomen. Daar is een board ook echt goed in: het bij elkaar brengen van perspectieven die één persoon niet overziet.

De CAB wordt zo weer wat de naam al zegt: advisory. Adviserend, niet vergunningverlenend. Dat is geen verlies aan controle, het is controle op de plek waar hij verschil maakt.

Change enablement is meetbaar

Een van de redenen dat change management zo vaak op gevoel wordt gestuurd, is dat organisaties niet meten. Terwijl juist dit proces zich uitstekend laat meten. De cijfers die ertoe doen: het percentage geslaagde wijzigingen, het aantal mislukte en teruggedraaide wijzigingen, het aantal incidenten dat direct volgt op een wijziging, en de doorlooptijd van aanvraag tot uitvoering.

Die laatste, de doorlooptijd, is de graadmeter die de meeste organisaties negeren en die de business het hardst voelt. Als je proces veilig is maar traag, los je het ene probleem op door een ander te creëren. Een goed change enablement-proces stuurt op beide tegelijk: minder mislukkingen én kortere doorlooptijd. Dat die twee tegen elkaar in zouden werken, is een mythe. In een slecht proces stijgen ze samen, in een goed proces dalen ze samen.

Wat een change manager toevoegt

De rol van change manager is niet om in elke vergadering te zitten en wijzigingen af te tikken. Dat is juist het symptoom van een proces dat niet werkt. Mijn werk is het ontwerpen van het proces: de change-typen goed beleggen, de standaardwijzigingen identificeren en automatiseren, de autorisatieniveaus koppelen aan risico, en de organisatie leren sturen op cijfers in plaats van op onderbuik.

Als dat staat, draait het proces grotendeels zonder dat er iemand bovenop hoeft te zitten. Dat is het doel. Een change manager die zichzelf onmisbaar maakt in de dagelijkse afhandeling, heeft zijn eigen werk verkeerd begrepen.

Tot slot

Change management gaat niet over het tegenhouden van wijzigingen, maar over het mogelijk maken ervan tegen een risico dat je bewust accepteert. Wie alles gelijk behandelt, vertraagt de hele organisatie zonder het risico te verlagen. Wie onderscheid maakt naar risico, standaardwijzigingen automatiseert en de CAB teruggeeft aan zijn adviserende rol, krijgt precies wat change enablement belooft: snelheid en controle tegelijk. Het is geen keuze tussen die twee. Dat het dat zou zijn, is de duurste misvatting in het vak.

ITIL 4 en informatiebeveiliging: security borgen in je serviceprocessen

Veel organisaties behandelen informatiebeveiliging als een apart project naast de reguliere IT. Er komt een securityteam, er komt beleid, er komen maatregelen, en die hangen vervolgens los van de processen waarmee de IT-organisatie elke dag draait. Het gevolg is voorspelbaar: na de implementatie verwatert de beveiliging, omdat ze nergens is geborgd. Wat los staat van het dagelijks werk, sterft een stille dood. ITIL 4 biedt het raamwerk om dat te voorkomen. In dit artikel laat ik zien hoe je met ITIL 4 informatiebeveiliging verankert in je serviceprocessen, en hoe dat aansluit op ISO 27001.

Waarom losse maatregelen verwateren

Een beveiligingsmaatregel die niet in een proces zit, leunt op de discipline van individuele mensen. Zolang de juiste persoon eraan denkt, gebeurt het. Vertrekt die persoon, of komt het druk, dan zakt het weg. Dat is geen kwestie van onwil, maar van ontbrekende borging.

Informatiebeveiliging die wel beklijft, zit ingebakken in hoe het werk standaard verloopt. Niet als extra stap die je eraan plakt, maar als vast onderdeel van het proces zelf. En precies dat is wat ITIL 4 mogelijk maakt: het beschrijft de praktijken waarmee een IT-organisatie waarde levert, en in vrijwel elk van die praktijken zit een natuurlijk haakje voor security.

ITIL 4 in het kort

ITIL 4 is het meest gebruikte raamwerk voor IT-servicemanagement. De kern is het Service Value System, dat beschrijft hoe vraag en kansen via gestructureerde activiteiten worden omgezet in waarde. Daarbinnen kent ITIL 4 een set management practices: herkenbare manieren van werken zoals incidentbeheer, wijzigingsbeheer en leveranciersmanagement.

Het krachtige is dat informatiebeveiliging in ITIL 4 geen aparte praktijk is die naast de rest staat, maar een eigenschap die door alle praktijken heen loopt. Je beveiligt niet los van je processen. Je beveiligt via je processen.

Concreet: waar security in je serviceprocessen zit

Laat ik het tastbaar maken aan de hand van een aantal praktijken.

Wijzigingsbeheer (change enablement). Elke wijziging is een potentieel beveiligingsrisico. Door een securitytoets vast onderdeel te maken van de wijzigingsbeoordeling, voorkom je dat veranderingen ongemerkt nieuwe kwetsbaarheden introduceren. De controle zit dan in het proces, niet in het toeval dat iemand eraan denkt.

Incidentbeheer. Een beveiligingsincident is een incident. Door je incidentproces zo in te richten dat security-incidenten herkend, geclassificeerd en geëscaleerd worden, zorg je dat de organisatie er gestructureerd op reageert in plaats van ad hoc. Dat is ook precies wat een auditor wil zien.

Probleembeheer. Waar incidentbeheer de brand blust, zoekt probleembeheer de oorzaak. Toegepast op security betekent dat: niet alleen het incident afhandelen, maar de onderliggende kwetsbaarheid wegnemen zodat het niet terugkomt. Dit is de motor achter structurele verbetering.

Leveranciersmanagement. Een groot deel van je risico zit bij derde partijen. Door beveiligingseisen, afspraken en periodieke evaluaties in je leveranciersproces te beleggen, houd je grip op de keten. Onder NIS2 is dat geen luxe meer maar een verplichting.

Configuratiebeheer. Je kunt niet beschermen wat je niet kent. Een actueel beeld van je assets en hun onderlinge afhankelijkheden is de basis onder vrijwel elke beveiligingsmaatregel. Configuratiebeheer levert dat beeld.

In elk van deze gevallen is de boodschap dezelfde: je bouwt geen apart securityproces, je maakt security een vast bestanddeel van processen die je toch al hebt.

De aansluiting op ISO 27001

Hier komen twee werelden samen die in de praktijk vaak gescheiden worden gehouden. Veel beheersmaatregelen uit ISO 27001 Annex A gaan over precies de operationele processen die ITIL 4 beschrijft: wijzigingsbeheer, capaciteitsbeheer, logging, leveranciersrelaties, het beheer van kwetsbaarheden. Wie zijn serviceprocessen volgens ITIL 4 heeft ingericht, heeft een groot deel van het fundament onder die maatregelen al staan.

Dat scheelt dubbel werk. In plaats van een ISMS dat naast de IT-organisatie hangt, veranker je de normvereisten in de processen waarmee toch al gewerkt wordt. Dat maakt de beveiliging niet alleen robuuster, maar ook beter aantoonbaar, omdat het bewijs ontstaat in het dagelijks werk in plaats van in een apart dossier dat je voor de audit bij elkaar moet sprokkelen.

Van eenmalig naar continu

De laatste winst zit in continue verbetering. ITIL 4 stuurt op het continu evalueren en bijstellen van praktijken, en dat sluit naadloos aan op de PDCA-cyclus die ISO 27001 vraagt. Plannen, uitvoeren, meten, bijsturen: in beide werelden is dat het ritme. Wie ze combineert, hoeft niet twee verbetercycli naast elkaar te draaien, maar heeft er één die beide doelen dient.

Zo wordt informatiebeveiliging geen project met een einddatum, maar een eigenschap van een organisatie die zichzelf blijft verbeteren.

Tot slot

Informatiebeveiliging die los staat van het dagelijks werk, verwatert. Door security te verankeren in je ITIL 4 serviceprocessen maak je beveiliging een vast onderdeel van hoe je organisatie werkt, sluit je aan op de eisen van ISO 27001, en bouw je een verbetercyclus die blijft draaien. Dat is duurzamer, goedkoper en beter aantoonbaar dan een securityteam dat naast de organisatie staat te roepen. De norm beschrijft wat er moet, ITIL 4 zorgt dat het ook echt gebeurt.

Ronald Everduim is zelfstandig ISO-consultant, CISO-adviseur en ITIL 4 Master. Hij combineert IT-governance en informatiebeveiliging bij organisaties in de zorg, overheid, industrie en het bedrijfsleven.

Waarom de meeste security awareness trainingen mislukken

Bijna elke organisatie heeft tegenwoordig een security awareness training. Een e-learning, een keer per jaar, een eindtoets met een paar meerkeuzevragen, en het vinkje staat. En toch klikt diezelfde organisatie een halfjaar later massaal op een phishingmail. Dat is geen toeval. De meeste awareness-trajecten zijn ontworpen om een verplichting af te vinken, niet om gedrag te veranderen. In dit artikel leg ik uit waarom dat misgaat, en wat het verschil maakt tussen een training die werkt en een die alleen tijd kost.

Het probleem: de afvinkcultuur

Awareness is in veel organisaties verworden tot een compliance-handeling. De norm vraagt erom, dus er moet iets staan, dus er wordt een generieke e-learning ingekocht. Het doel verschuift ongemerkt van “mensen veiliger laten werken” naar “kunnen aantonen dat we iets hebben gedaan”. Dat zijn niet dezelfde dingen, en de tweede levert de eerste zelden op.

Een audit kijkt of er awareness is. Een aanvaller kijkt of die awareness werkt. Zolang je alleen het eerste organiseert, ben je formeel compliant en feitelijk kwetsbaar.

Vijf redenen waarom het misgaat

1. Eenmalig in plaats van doorlopend. Gedrag verandert niet van één sessie per jaar. Wat je in maart leert, ben je in september vergeten. Awareness die werkt is een ritme, geen evenement.

2. Generiek in plaats van relevant. Een algemene e-learning over “wachtwoorden en phishing” raakt niemand persoonlijk. Een financieel medewerker loopt andere risico’s dan een zorgverlener of een systeembeheerder. Wie iedereen hetzelfde voorschotelt, raakt niemand echt.

3. Angst in plaats van begrip. Trainingen die vooral waarschuwen voor straf en gevaar leveren angstige medewerkers op die incidenten verzwijgen in plaats van melden. Dat is precies het tegenovergestelde van wat je wilt. Je wilt dat iemand die per ongeluk op een link klikt dat binnen vijf minuten meldt, niet dat hij het verbergt.

4. Geen meting. Veel organisaties weten niet of hun awareness werkt, omdat ze alleen deelname meten en niet gedrag. Hoeveel mensen melden een verdachte mail? Hoe snel? Daalt het klikgedrag over de tijd? Zonder die cijfers stuur je blind.

5. Losgekoppeld van beleid en praktijk. Een training die zegt “gebruik sterke wachtwoorden”, terwijl het systeem zwakke wachtwoorden toestaat en niemand een wachtwoordmanager heeft, ondergraaft zichzelf. Awareness moet aansluiten op wat technisch en organisatorisch mogelijk is, anders leer je mensen iets wat ze niet kunnen waarmaken.

Van beleid naar gedrag

De kern van het probleem is dat veel organisaties awareness behandelen als een losse maatregel, terwijl het de laatste schakel is in een keten. Die keten loopt van risico naar beleid, van beleid naar concrete maatregelen, en pas daarna naar gedrag. Awareness werkt alleen als de schakels ervoor kloppen.

Concreet betekent dat: bepaal eerst welke risico’s je met gedrag wilt afdekken, vertaal dat naar helder beleid dat mensen kunnen begrijpen en uitvoeren, zorg dat de techniek het gewenste gedrag ondersteunt, en richt de training dan op precies die handelingen die het verschil maken. Awareness is geen vervanging voor goede techniek en goed beleid. Het is het sluitstuk.

Wat wel werkt

Effectieve awareness heeft een paar herkenbare kenmerken.

Het is doorlopend en in kleine porties. Korte, regelmatige momenten werken beter dan één lange sessie. Mensen onthouden iets dat terugkomt, niet iets dat ze eenmaal afvinken.

Het is doelgroepgericht. De directie hoort een ander verhaal dan de servicedesk. Geef mensen voorbeelden uit hun eigen werk, niet uit een algemeen lesboek.

Het maakt gebruik van voorbeeldgedrag van leiders. Als de directie zelf zichtbaar de regels volgt en fouten bespreekbaar maakt, volgt de rest. Cultuur wordt van bovenaf gezet, niet via een e-learning afgedwongen.

Het meet en stuurt bij. Phishingsimulaties hebben hun plaats, mits je ze gebruikt om te leren en niet om te straffen. Meet of het meldgedrag toeneemt en het klikgedrag afneemt, en pas de aanpak aan op wat de cijfers laten zien.

En het maakt melden makkelijk en veilig. De belangrijkste gedragsverandering die je kunt bereiken, is dat mensen fouten en verdachte signalen snel melden. Dat lukt alleen in een cultuur waarin melden wordt gewaardeerd, niet bestraft.

Awareness als aantoonbare beheersmaatregel

Vanuit ISO 27001 en NEN 7510 is awareness geen vrijblijvende extra, maar een beheersmaatregel die je aantoonbaar moet beleggen en evalueren. Een auditor wil niet alleen zien dat er een training is geweest, maar dat je stuurt op het effect ervan. Juist daar komen de afvinkbenadering en de norm samen: wie awareness echt laat werken, voldoet vanzelf aan de aantoonbaarheidseis. Wie alleen afvinkt, voldoet op papier en faalt in de praktijk.

Tot slot

Een security awareness training mislukt zelden omdat de inhoud verkeerd is. Hij mislukt omdat hij eenmalig, generiek en losgekoppeld is van beleid, techniek en cultuur. Behandel awareness als het sluitstuk van een keten die je eerst op orde brengt, maak melden veilig, en meet het effect in plaats van de deelname. Dan verandert er wel iets, en dan klopt het vinkje ook echt.

Ronald Everduim is zelfstandig ISO-consultant en CISO-adviseur. Hij begeleidt organisaties bij informatiebeveiliging, awareness en certificering conform onder meer ISO 27001 en NEN 7510.

Wanneer huurt je een interim CISO in? De rol versus de persoon

Veel organisaties praten over “de CISO” alsof het één ding is. In de praktijk zijn het er twee: er is de CISO-rol, een set verantwoordelijkheden die je organisatie moet beleggen, en er is de CISO-persoon, degene die die verantwoordelijkheden invult. Wie die twee door elkaar haalt, neemt vroeg of laat de verkeerde beslissing over werving, inhuur of opvolging. In dit artikel leg ik het onderscheid uit en geef ik aan wanneer een interim CISO inhuren wel en niet logisch is.

De CISO is een rol, geen functietitel

De Chief Information Security Officer is in de kern een governance-rol. De CISO vertaalt risico naar beleid, beleid naar maatregelen, en maatregelen naar iets dat aantoonbaar werkt richting directie, toezichthouders en certificerende instanties. Het zwaartepunt ligt op sturing, niet op techniek. Een CISO die vooral firewalls configureert is geen CISO maar een security engineer met een te dure titel.

Die rol bestaat in elke organisatie die informatie als bedrijfsmiddel serieus neemt, of je hem nu zo noemt of niet. De vraag is dus zelden of je de rol nodig hebt. De vraag is hoe je hem belegt: als vaste functie, als onderdeel van een bredere rol, of tijdelijk via een interim CISO.

Vast of interim: vier situaties

Het inhuren van een interim CISO is geen tweederangs oplossing voor wie geen vaste kracht kan vinden. Het is een bewuste keuze die in een aantal situaties juist beter past dan een vaste aanstelling.

1. Het overbruggen van een vacature. Je CISO vertrekt en de werving van een opvolger duurt maanden. In die periode kan de rol niet stilvallen, zeker niet in een organisatie die onder NIS2 valt of die een lopend certificeringstraject heeft. Een interim CISO houdt het stuur vast tot de vaste kracht er is.

2. Een afgebakend certificeringstraject. Je wilt naar ISO 27001 of NEN 7510 toe, of je moet aantoonbaar voldoen aan de BIO. Dat is een traject met een begin en een eind. Een ervaren interim die dit type traject eerder heeft gedaan, brengt je sneller en met minder omwegen naar de certificerende audit dan iemand die het naast een drukke staande functie erbij doet.

3. Een deadline die niet wacht. NIS2 is daar het duidelijkste voorbeeld van. Wachten op volledige duidelijkheid uit Den Haag is geen strategie, en de aantoonbaarheidseisen vragen voorbereiding die maanden kost. Een interim met focus haalt die voorbereiding binnen, terwijl je eigen mensen hun reguliere werk blijven doen.

4. Transitie of nasleep van een incident. Een fusie, een grote migratie of de afhandeling van een beveiligingsincident vraagt tijdelijk om meer capaciteit en meer ervaring dan de organisatie zelf in huis heeft. Dat is precies waar interim inhuur voor bedoeld is.

Wat een interim CISO toevoegt dat een vaste kracht vaak niet kan

Een interim brengt drie dingen mee die in een vaste rol moeilijker te organiseren zijn.

Het eerste is onafhankelijkheid. Een interim CISO heeft geen interne carrière te beschermen en geen jarenlange relaties om te ontzien. Dat maakt het makkelijker om de directie ook ongevraagd advies te geven, en om een bevinding te benoemen die intern liever onbesproken blijft.

Het tweede is snelheid. Iemand die ISMS-implementaties en certificeringsaudits heeft begeleid in de zorg, bij de overheid en in de industrie, herkent patronen. Waar een organisatie maanden zoekt naar de juiste structuur, kan een ervaren interim de bekende valkuilen overslaan.

Het derde is focus. Een interim wordt ingehuurd voor één opdracht en wordt niet weggetrokken door de waan van de dag. Dat klinkt vanzelfsprekend, maar het is vaak het grootste verschil met een interne functionaris die security erbij doet.

De valkuil: interim als brandblusser zonder mandaat

De meest gemaakte fout is dat een interim CISO wordt binnengehaald als brandblusser, maar zonder het mandaat om iets structureel te veranderen. Dan blus je het incident, schrijf je een rapport, en ligt de organisatie er na vertrek precies zo bij als ervoor.

Een interim CISO is alleen effectief met directe lijn naar de directie en met de bevoegdheid om besluiten af te dwingen die de organisatie raken. Beleg dat mandaat vooraf, in plaats van het gaandeweg te moeten bevechten. Vraag bij de inhuur niet alleen naar ervaring met de norm, maar ook naar ervaring met het organiseren van draagvlak. De norm is het makkelijke deel. Mensen meekrijgen is het werk.

Borg de rol voordat de persoon vertrekt

Het inherente risico van interim inhuur is dat kennis met de persoon de deur uitgaat. Daarom hoort kennisoverdracht vanaf dag één in de opdracht te zitten, niet pas in de laatste week. Een goede interim levert niet alleen een gecertificeerd managementsysteem op, maar ook een organisatie die het zelf kan dragen: ingerichte processen, eigenaren die hun rol kennen, en documentatie die aansluit op hoe er echt gewerkt wordt.

Zo blijft de rol staan, ook als de persoon vertrekt. En dat is uiteindelijk waar het om gaat. Je huurt geen persoon in, je belegt een verantwoordelijkheid.

Tot slot

Het verschil tussen de CISO-rol en de CISO-persoon bepaalt of inhuur slim of duur is. Heb je een afgebakend doel, een deadline of een transitie, dan is een interim CISO vaak de snellere en scherpere route. Wil je de rol permanent in de organisatie verankeren, dan ligt een vaste invulling meer voor de hand, mits je de tijd hebt om die in te vullen. In beide gevallen geldt: beleg eerst de rol helder, kies daarna pas de persoon.

Ronald Everduim is zelfstandig ISO-consultant en CISO-adviseur. Hij begeleidt organisaties in de zorg, overheid, industrie en het bedrijfsleven bij informatiebeveiliging en certificering.