Een datalek dat uw DORA-register niet verklaart

Wat RingCentral daadwerkelijk heeft bevestigd

RingCentrals eigen beveiligingsbulletin in het Trust Center, gedateerd 28 juli 2026 en met risiconiveau HOOG, stelt dat het bedrijf "onlangs ontdekte dat het doelwit was van een geavanceerde social-engineeringcampagne" en "onmiddellijk stappen zette om de ongeautoriseerde activiteit te stoppen" met hulp van een extern forensisch bureau. Het bulletin voegt toe: "dit incident heeft gegevens van een beperkt deel van de RingCentral-klanten getroffen, en wij nemen rechtstreeks contact op met getroffen klanten. Als u niet door RingCentral bent gecontacteerd, bent u niet getroffen."

De afpersingsgroep ShinyHunters eiste de aanval al een dag eerder op, op 27 juli 2026, en zei 623 GB aan data te hebben gestolen, waarna het na de weigering van RingCentral om te betalen een archief van 280 GB publiceerde. Have I Been Pwned verwerkte dat archief en voegde het op 13 augustus 2026 toe aan zijn database: ongeveer 1,6 miljoen unieke e-mailadressen, samen met namen, telefoonnummers en fysieke adressen. RingCentral heeft expliciet gesteld dat het datalek RingEX, RingCentral Contact Center, RingCX of enige andere kerndienst niet heeft bereikt, die volgens het bedrijf "zonder onderbreking is blijven werken."

Een patroon bij leveranciers, niet bij slachtoffers

ShinyHunters heeft in 2026 hetzelfde draaiboek herhaald bij de ene SaaS-leverancier na de andere: Salesforce-klantomgevingen, bij Snowflake gehoste klantdata en Oracle PeopleSoft-implementaties, waarbij de groep zelf de gezamenlijke buit van al zijn campagnes op ruim 1,5 miljard records becijfert. RingCentral is de nieuwste naam op die lijst, en de methode die het bedrijf zelf beschrijft, iemand overgehaald om toegang te verlenen, in plaats van een fout die een aanvaller moest opsporen, past bij een bredere trend van 2026: vishing- en social-engineeringcampagnes die succes hebben bij medewerkers met bevoorrechte toegang bij de leverancier, niet bij de klant.

Dat onderscheid telt voor iedereen die RingCentral als leverancier beoordeelt. Een klant kan zijn eigen software patchen en zijn eigen inloggegevens vervangen, maar heeft geen manier om te testen, of zelfs maar te zien, hoe goed het support- en beheerpersoneel van een leverancier weerstand biedt aan een overtuigend telefoontje. Het doelwit hier was het personeel van RingCentral, niet de code.

Het gat in het leveranciersrisicoregister

Financiële entiteiten onder de Europese verordening voor digitale operationele veerkracht moeten, volgens de artikelen 28 tot en met 30 van DORA, een informatieregister bijhouden van elke ICT-derde partij en het risico beoordelen dat elke partij vormt voor hun eigen veerkracht. Essentiële en belangrijke entiteiten onder de NIS2-richtlijn dragen een parallelle verplichting in artikel 21 om het cyberrisico van de toeleveringsketen te beheren, inclusief de beveiligingspraktijken van hun directe leveranciers. Beide kaders veronderstellen dat de gereguleerde entiteit voldoende details van een leverancier kan krijgen om diens risico daadwerkelijk te beoordelen.

Het bulletin van RingCentral noemt niet de functie van de betrokken medewerker, niet het interne systeem dat de aanvaller bereikte, en niet welke controle, meerfactorauthenticatie, terugbelverificatie, identiteitscontrole bij de helpdesk, faalde waardoor een telefoontje een datalek werd. Een Duitse bank, een Nederlandse ziekenhuisgroep of een Britse verzekeraar die RingCentral in het ICT-derdepartijenregister vermeldt, heeft niets concreets toe te voegen aan die vermelding, behalve dat er een incident plaatsvond. De gebruikelijke leveranciersvragenlijst, een SOC 2-verklaring, een versleutelingscertificaat, een pentestsamenvatting, toetst precies de technische controles die nooit in het spel waren bij een incident dat begon en eindigde met een gesprek.

Wat een operator daadwerkelijk zou moeten veranderen

De praktische oplossing is niet nog meer versleutelingspapierwerk. Operators die afhankelijk zijn van RingCentral, of van elke andere UCaaS- of CCaaS-leverancier die gereguleerde klanten bedient, zouden de leverancier rechtstreeks moeten vragen of hij zelf gesimuleerde social-engineeringtests uitvoert tegen support- en beheerpersoneel, en het antwoord, of de weigering om te antwoorden, moeten behandelen als een volwaardige vermelding in het eigen risicoregister.

Contractverlengingen na deze openbaarmaking zijn het moment om een specifieke clausule toe te voegen: een recht op een technische post-mortemanalyse, geen marketingverklaring, binnen een vaste termijn na elk bevestigd incident. Zonder die clausule zal de volgende datalekmelding van een leverancier precies klinken als deze: op papier volledig en compliant, maar nutteloos voor het ene document, het risicoregister, dat de regelgeving een operator daadwerkelijk verplicht actueel te houden.

Lees hierna: 45.601 lekken, 171 worden echt misbruikt  |  Een bericht bereikte de SSH-sleutels