Een factuur die klopt, tot hij dat niet doet
De mailwisseling loopt al weken. Offertes, bevestigingen, kleine wijzigingen. Dan komt de factuur. Alles klopt: dezelfde thread, dezelfde toon, dezelfde afzender. Alleen het rekeningnummer is “gecorrigeerd” omdat er iets is veranderd aan de administratie. Niemand voelt alarm. Het lijkt op werk.
Dit is waar factuurfraude via Vendor Email Compromise (VEC) landt. Niet als een vreemde mail die je moet herkennen, maar als een normaal moment in een vertrouwd proces. Juist omdat het bericht uit een echt leveranciersaccount komt, doorstaat het veel van de technische en mentale filters waar we in het MKB op leunen.
En daarmee verschuift de vraag van oplettendheid naar bestuur. Als een bericht technisch legitiem is omdat het uit een echt leveranciersaccount komt, welke mate van vertrouwen in e-mail als drager van betaalinstructies is dan nog bestuurlijk verdedigbaar?
Het misverstand: technisch legitiem is niet hetzelfde als bestuurlijk betrouwbaar
VEC is zakelijke e-mailfraude waarbij een aanvaller communiceert vanuit een echt, gecompromitteerd leveranciersaccount. Daardoor voelt de communicatie correct, inclusief timing en toon. Maar “correct” in e-mail is niet hetzelfde als “geautoriseerd” in betaling.
Veel organisaties behandelen e-mail impliciet als bewijs. Als het uit de juiste inbox komt, in de juiste thread, met de juiste aanspreekvorm, dan is het waar. Dat is begrijpelijk: e-mail is jarenlang het kanaal geweest waar afspraken, uitzonderingen en bevestigingen doorheen lopen. Alleen: in betaalverkeer is die aanname fragiel, omdat e-mail procesautoriteit niet vanzelf zichtbaar maakt.
Een e-mail kan technisch legitiem zijn en toch bestuurlijk onbetrouwbaar voor betaalwijzigingen. Niet omdat mensen naïef zijn, maar omdat het kanaal uitnodigt tot een shortcut: identiteit wordt verward met bevoegdheid. VEC misbruikt precies dat gat.
Het mechanisme: manipulatie van betaalinstructies binnen echte correspondentie
De kernhandeling is eenvoudig te benoemen en lastig te beheersen: het wijzigen van betaalinstructies binnen een echte, lopende correspondentie. Dat kan een nieuw rekeningnummer zijn, een “tijdelijke omleiding” of een plausibele correctie nadat de factuur al is verzonden. Het gaat niet per se om een ongeloofwaardig verhaal. Het gaat om het benutten van een proces dat al draait.
Daar kan voorbereiding aan voorafgaan. Context en timing kunnen worden benut waardoor een bericht naadloos aansluit op wat voor uw organisatie normaal voelt. Klassieke phishing-signalen kunnen ontbreken omdat dit geen imitatie is van een leverancier, maar communicatie vanuit het echte account.
In incident response zie je daarnaast soms een tweede laag die het herstelvermogen aantast: onzichtbaarheid. Niet als trucje dat u moet leren herkennen, maar als patroon dat verklaart waarom correcties en waarschuwingen niet landen. Een mailbox kan zo worden gemanipuleerd dat antwoorden, waarschuwingen of interne signalen uit zicht verdwijnen. Wat overblijft is een conversatie die “rustig” blijft, terwijl er juist een breuk is ontstaan.
Een tweede vignette uit de praktijk maakt dit tastbaar. Een organisatie ziet plots afwijkende aanmeldingen op een account vanuit meerdere landen binnen korte tijd. Er is nog geen schade, geen verstoring, alleen een signaal dat toegang niet klopt. De reflex is technisch: blokkeren, herstellen, controleren. Maar de bestuurlijke vraag is scherper: als dit een ketenpad was, wat had er dan in het factuurproces moeten voorkomen dat een betaalwijziging zonder echte autorisatie wordt geaccepteerd?
Kapstok: de vertrouwenskloof tussen kanaal, identiteit en autorisatie
In termen die u ook in publieke guidance terugziet (zoals bij NCSC/DTC) gaat het om zakelijke e-mailfraude waarbij betaalinstructies worden gemanipuleerd binnen echte ketencommunicatie. Die beschrijving is juist, maar nog niet bestuurbaar. Bestuurbaar wordt het pas als u het probleem uit elkaar trekt en expliciet bepaalt waar e-mail wel en niet als bewijs mag gelden.
Hier helpt een eenvoudige kapstok, juist omdat hij directie, IT en finance dezelfde taal geeft.
De drie lagen van vertrouwen in betaalverkeer
- Kanaal-legitimiteit: het bericht komt via het normale kanaal en voelt “zoals altijd”.
- Identiteit: het komt uit een echt account, maar dat zegt niets over intentie.
- Autorisatie: de kernvraag is of een betaalwijziging procesmatig bevoegd en bevestigd is.
VEC misbruikt de kloof: het lijkt te kloppen in de eerste twee lagen, terwijl de derde laag impliciet blijft. En precies daar zit de bestuurlijke keuze. Hoe dichter u bij betaling komt, hoe lastiger het bestuurlijk verdedigbaar wordt om e-mail de drager van “waarheid” te laten zijn. Niet omdat e-mail slecht is, maar omdat betaling een andere risicoklasse is dan afspraken maken.
Keten-implicaties: waarom dit niet stopt bij de leverancier
Het lastige aan VEC is dat de zwakte niet hoeft te liggen waar de schade valt. Een leverancier kan gecompromitteerd raken, terwijl de financiële schade bij de afnemer landt. Daarmee wordt “beveiliging” een ketenfenomeen: vertrouwen verplaatst risico over organisatiegrenzen.
Dat heeft twee effecten in het MKB.
Het eerste is praktisch: u kunt intern zorgvuldig werken en toch geraakt worden via een partij die u nodig hebt om te opereren. Dit is geen pleidooi voor wantrouwen, maar voor realisme. Ketenrelaties zijn vaak langdurig, menselijk en gebaseerd op soepelheid. VEC lift mee op die soepelheid.
Het tweede is bestuurlijk: zodra geld verkeerd gaat, ontstaat direct een tweede realiteit van afhandeling. Niet alleen technisch herstel, maar ook interne escalatie, bankprocedures, communicatie met de leverancier en een discussie over verantwoordelijkheid. Zonder een oordeel te vellen is dit de kernspanning: technische compromittering zit bij partij A, financiële schade bij partij B, en de vraag “wie had dit kunnen stoppen” schuift al snel richting het betaalproces van de betaler.
Een derde vignette laat het tijdsaspect zien. Een organisatie signaleert een verdachte inlogpoging die niet past bij normaal gebruik. Er blijkt een link met een mail die lijkt te komen van een ketenpartner. Er wordt snel ingegrepen en er is uiteindelijk geen aantoonbare schade. Dat is geen comfort, maar een waarschuwing: het verschil tussen “geen schade” en “directe financiële schade” kan zitten in één betaalmoment dat wel of niet als hoog-risico handeling is bestuurd.
Drie bestuurlijke vragen die u expliciet moet beantwoorden
Dit onderwerp wordt volwassen behandeld als u het niet laat eindigen als IT-incident, maar als bestuurskeuze. Niet als stappenplan, maar als expliciete grenzen. Drie vragen helpen om die grens zichtbaar te maken.
Waar is e-mail in uw organisatie een geldig kanaal voor betaalinstructies, en waar expliciet niet?
Veel grijs gebied ontstaat doordat “het altijd zo gaat” de standaard is. VEC breekt die standaard. Als u nooit expliciet hebt gekozen waar e-mail bewijs mag zijn, dan wordt elke mail potentieel bewijs, ook als dat bestuurlijk niet verdedigbaar is.
Wat beschouwt u als een betaalwijziging, en welke mate van verificatie hoort daarbij?
Het gaat niet alleen om een nieuw rekeningnummer. Ook correcties, omleidingen, tijdelijke uitzonderingen en “administratieve wijzigingen” kunnen dezelfde risicoklasse hebben. De bestuurlijke opgave is niet om alles dicht te zetten, maar om frictie te plaatsen waar de schade kan ontstaan.
Wie is eigenaar van die grens, en hoe voorkomt u dat finance en IT langs elkaar heen werken?
Directie is eigenaar van verdedigbaarheid en risicokeuzes. IT en finance zijn eigenaar van borging in proces en controles. Als die eigenaarschaplijn niet expliciet is, ontstaat het bekende patroon: IT focust op identiteit, finance op betaling, en niemand bestuurt de overgang daartussen.
Slot: maak vertrouwen bestuurbaar, niet angstig
VEC vraagt niet om paniek en ook niet om schijnzekerheid. Het vraagt om volwassen taal over vertrouwen. De kern is eenvoudig: een legitieme afzender is geen autorisatie voor een betaling.
Daarom is het meest zinvolle resultaat van dit inzicht niet “betere oplettendheid”, maar betere beslisbaarheid. Waar is e-mail een prima drager van informatie, en waar moet e-mail stoppen als drager van betaalinstructies? Waar wilt u dat een wijziging niet “door kan” zonder expliciete bevestiging?
Een voorbeeld van een controlelaag die u in dit kader kunt noemen is IBAN-Naam Check. Niet als belofte dat het fraude voorkomt, maar als illustratie dat u rond betaling bewust frictie kunt introduceren. Frictie is geen falen van efficiëntie. Op de juiste plek is het een ontwerpkeuze voor bestuurbaarheid.
En dan blijft de vraag die u in uw eigen context moet beantwoorden: als een bericht technisch legitiem is omdat het uit een echt leveranciersaccount komt, welke mate van vertrouwen in e-mail als drager van betaalinstructies is dan nog bestuurlijk verdedigbaar?
