Nieuwsblog: datalekken zijn hét voorbeeld van lastige journalistieke afwegingen

Er waren nogal wat datalekken in de afgelopen weken. Door een paar opvallende, grote hacks bleef onze inbox maar volstromen met tips, van groot naar klein. Daardoor moesten we telkens keuzes maken die soms niet helemaal logisch aanvoelden. Het ene datalek is namelijk wél nieuwswaardig, maar het andere laten we weer zitten.

Een kleine greep uit de datalekken van augustus: autobedrijf Rentrunner, Steam, Ajax en brillenwinkel Ace en Tate, de Bijenkorf en Bol, Framework en drukkerij Drukland. En dat is nog niet eens de helft van de bedrijven die sinds eind juli in onze submits voorkwamen omdat er een datalek plaatsvond. We hadden het er druk mee.

Dat we net nu zoveel schreven over datalekken was een ongelukkige samenloop van omstandigheden. Er waren een paar grote serviceproviders die werden gehackt, wat gebruikers en klanten van veel verschillende bedrijven trof. Het ging bijvoorbeeld om CEVA, een bedrijf dat klantenservice voor (web)winkels verzorgde. Dat gebeurt regelmatig en zal ook vaker gebeuren, want dit is een trend in cybercrime. Experts waarschuwen al jaren dat managed service providers aantrekkelijke doelwitten zijn voor ransomwarebendes. Door een MSP te hacken, is het ook weer heel makkelijk om zijn klanten te treffen en die zo af te persen.

Ransomware

Ransomware draait steeds vaker om het stelen van data

Ransomwarebendes zijn op hun beurt de laatste jaren steeds meer gefocust op het stelen van gegevens in plaats van op het versleutelen van systemen. Bovendien zijn managed service providers meestal niet hoofdverantwoordelijk voor het op de hoogte brengen van slachtoffers. Dat zijn de klanten van die MSP's, dus de webwinkels en bedrijven die hun diensten afnemen. Dat betekent in de praktijk dat je ook als normale internetklant steeds vaker te horen krijgt dat je slachtoffer bent van een datalek.

Tips

Dan volgen de vragen: wat en wanneer schrijven we hierover op Tweakers? We horen meestal over datalekken via ons tipformulier. Slachtoffers delen daar dan de tekst van een e-mail van een bedrijf, met soms een link naar een website met meer informatie. We kunnen dan snel zien welk bedrijf gehackt is en welke gegevens daarbij gestolen zijn.

Vaak willen we eerst verifiëren of een lek wel echt gebeurd is. Daarom vragen we gebruikers regelmatig via DM om ons de originele e-mail door te sturen, die we dan als screenshot kunnen opnemen in het bericht. Vaak hoeft dat ook niet; bij sommige datalekken krijgen we tientallen tips binnen. Dat zien we ook vaak als een indicatie dat een datalek opvallend veel slachtoffers treft.

Geen kant-en-klare checklist

De vraag wanneer we wel of juist niet over een datalek schrijven, is lastig te beantwoorden. Om te beginnen kunnen we niet over ieder datalek een nieuwsartikel schrijven. Daarvoor zijn er te veel datalekken en is er te veel ander nieuws. We moeten daarom keuzes maken. Het is het klassieke journalistieke dilemma met maar één flauw antwoord: dat hangt ervan af.

Een deel van die afweging hebben we geprobeerd vast te leggen. De nieuwsredactie heeft een lang document waarin we redactionele afwegingen beschrijven. Voor beveiligingsvraagstukken hebben we weer een apart document, onze Securitynieuwsrichtlijnen. Daarin beschrijven we hoe, wat en wanneer we over beveiliging schrijven. Nieuws over datalekken valt daaronder.

In dat document staat ook een checklist. Een redacteur kan die naast het artikel houden om te kijken of hij of zij alle relevante informatie heeft opgenomen.

Een checklist in ons securitydocument.

Impact afwegen

De belangrijkste vraag die we onszelf altijd stellen is wat de impact van een datalek is. Er zijn een paar indicatoren voor de impact van een datalek. Hoe groter het lek, hoe meer slachtoffers het telt en hoe privacygevoeliger de gegevens zijn, des te nieuwswaardiger is het. Dat is geen optelsom of een lijstje om af te tikken. Soms staan verschillende nieuwsfeiten ook haaks op elkaar. Denk maar eens aan de volgende voorbeelden.

We kijken naar het aantal slachtoffers: hoe meer slachtoffers, hoe interessanter het nieuws. Neem het grote datalek bij Allianz in 2019. Daarbij werden 2,3 miljoen Nederlanders slachtoffer. De gestolen gegevens waren echter niet heel erg gevoelig. Het ging 'slechts' om naw-gegevens en het type auto van deze mensen. We schreven erover omdat er zó veel slachtoffers waren, maar niet omdat de gegevens veel impact hadden.

Veel of weinig slachtoffers

Omgekeerd vielen er bij een datalek bij een supermarktketen 'slechts' 3500 slachtoffers. Niet erg veel, maar daar waren de gegevens weer wél gevoelig. Het ging daar om paspoortkopieën, handtekeningen, bankrekeninggegevens en medische informatie. Dan is de beperkte omvang wel weer nieuwswaardig.

We gebruiken een document om de richtlijnen over securitynieuws te volgen.

Vaak weten we niet hoeveel slachtoffers er zijn. Dan maken we een inschatting. Als het gaat om een gespecialiseerde webwinkel is de kans klein dat er veel slachtoffers zijn – in tegenstelling tot, noem eens iets, Odido. Dan maken we ook wel weer een andere inschatting als er iets anders opvallends speelt. Neem bijvoorbeeld de hack van de website van Drukland. Daarbij werden ook wachtwoorden gestolen, al waren die gehasht. Hetzelfde geldt bijvoorbeeld bij een datalek bij Carpetright.

Nederland, België en de rest van de wereld

Een datalek wordt ook interessanter als het Nederlanders en/of Belgen betreft. Die medialogica leren journalisten overigens op hun eerste dag op de journalistiekopleiding al: hoe dichterbij iets gebeurt, hoe nieuwswaardiger het wordt. Een datalek bij een Duits bedrijf is dus al snel niet relevant. Door het eerdergenoemde CEVA-lek kwamen bijvoorbeeld gegevens van het Pokémon Center op straat te liggen. Maar omdat het daarbij ging om klanten in het VK en Duitsland, maar niet om klanten in de Benelux, hebben we het laten liggen.

Uiteindelijk proberen we dus de impact van een datalek te bepalen en dat is altijd een combinatie van factoren. Omvang, inhoud, opvallende feiten... Dat maakt ieder datalek weer een nieuwe, unieke afweging. Soms is die simpel. Het lek bij Kerstverlichtingbuiten hebben we laten liggen. Dat is een kleine webshop met waarschijnlijk een beperkt aantal slachtoffers, en het ging om namen, adressen, eventueel telefoonnummers en bestelgeschiedenissen. Die impact is heel beperkt, dus niet nieuwswaardig.

Hacker-met-hoodie is alleen illustratief. Bron: Boonchai Eedmakawand/Moment/Getty Images

Cryptowallets

Vaker is het moeilijker dan dat. Als je voor jezelf eens een gedachteoefening wil doen over hoe ingewikkeld dat is, kijk dan eens naar het datalek bij cryptovalutawallet Trezor. Want dat draait om cryptovaluta (nieuws!), maar het gaat om slechts 11.000 klanten (wel erg klein). Daarvan zit niemand in Nederland of België (niet nieuwswaardig). Bovendien gaat het om namen, adressen, telefoonnummers en e-mailadressen (dat zou bij een webshop geen nieuws zijn). Maar als je veel bitcoin hebt wil je absoluut niet dat bekend wordt waar je je cryptocoins hebt staan (en dan is de impact wél weer groot).

Uiteindelijk hebben we de afweging gemaakt dit nieuws niet te brengen. Was dat de juiste? Zeg het maar.

Reacties (24)

[Ozzy]

Op zich mooi dat jullie dit in overweging nemen en snap ook dat jullie daar een filtering op doen.

Tegelijkertijd ben ik ook wel benieuwd naar de overwegingen om elke storing van een bank te posten. Vergeleken met datalekken hebben die nauwelijks nieuwswaarde. Het is altijd hetzelfde, een linkje naar de storing bij de bank, een linkje naar allestoringen.nl , uitleggen dat de bank niet voor commentaar bereikbaar was. Gevolgd door een eindeloze stroom aan, hier werkt het ook niet, hier werkt het gewoon, ik zit al jaren bij een andere bank, ik ga nu overstappen.

Met dat in het achterhoofd vind ik een datalek minstens zo nieuwswaardig als een bankstoring, waar dus geen enkel filter op lijkt te zitten.

Daarnaast vind ik Tweakers, hoewel helaas steeds minder, eerst een techsite, dan pas een nieuwssite. Hoeveel slachtoffers er zijn interesseert mij bijvoorbeeld niet, de manier van hacken, het doel, wie, wat, wanneer en hoe, is veel interessanter. Daar kan, of moet, Tweakers onderscheidend zijn. Dus een hack op een cryptowallet vind ik zelf interessanter, dan een social engineering hack op een grote winkel, die alle andere media ook brengen, vaak nog sneller en beter ook.

[TijsZonderH]

Storingsnieuws heeft een heel andere functie. Als je zelf niet bij je rekening kunt, is het waardevol om te weten dat dat probleem niet aan jou ligt en dat het aan een storing ligt. Dat maakt ze al sneller relevanter.

Bovendien is de afweging voor ons heel binair: er is storing, of er is geen storing. We kijken hooguit naar hoe lang die duurt, maar buiten dat zijn er in tegenstelling tot datalekken geen andere filters om toe te passen.

En, minder relevant maar niet minder waar: storingsnieuws kost ons vrijwel geen tijd om te schrijven. Dat speelt een beetje mee.

Verder over datalekken zou ik dolgraag doen wat jij voorstelt. Het probleem is alleen dat bedrijven die informatie nooit zelf geven en het daarna heel moeilijk is daar zelf achter te komen. Dat kun je met de middelen van een NOS of RTL wel. Daar zitten fantastische redacteuren die de luxe hebben veel tijd te kunnen besteden aan het hoe en waarom van een lek bij Odido - en zelfs dan kun je dat praktisch alleen doen bij hele hoogprofieldatalekken. Dat kunnen wij niet, tenzij bedrijven zelf actief postmortems tonen. Dat doen ze soms en dan hebben we dat ook, maar dat is helaas zeldzaam

[MAX3400]

Veel storingsnieuws wordt ook niet gepost. En dat kan meerdere redenen hebben zoals tijdstip & duur van storing (en geen redacteur online), de grootte van de storing (soms zeer lokaal per gemeente of postcode) of de impact op de eindgebruiker (heb je omwegen of niet).

Neemt niet weg dat voor de gemiddelde gebruiker, ook zonder weet van Tweakers, er op dat moment zeker een storing is die voor hun op dat moment relevant is. Zo heb ik recentelijk in een bepaald postcodegebied meermaals een pinstoring meegemaakt echter zeer toevallig bij 1 bank en tussen exacte tijdsintervallen. Maar als je de dag erna de bank belt, weten ze natuurlijk van niets (of ze willen het niet zeggen). Maar ook sommige (zakelijke) ISP's hebben er een handje van om (lokale) storingen niet aan de grote boom te hangen; en als je als klant dan aanwijsbaar hebt dat het aan hun ligt "zijn ze lastig te bereiken en moet je maar geduld hebben"; ook dat is regelmatig aan de orde geweest in mijn lijn van werk.

Dus allicht, @TijsZonderH zou het allicht kunnen helpen om storingen, uit meerdere bronnen/feeds, allicht een ander plekje te geven op Tweakers of in een aparte subcategorie als nieuws. En alleen landelijke storingen of met langduriger impact daadwerkelijk een artikel aan wijden, tijdens en/of na de storing.

[onok]

Leuk kijkje achter de schermen. Ik zou niet in jullie schoenen willen staan. Ik kan me voorstellen dat het soms lastig is om bepaalde beslissingen te maken, wanneer het gevoelige dingen zijn dat mensen raakt.

[Llopigat]

Ik vind dat het juist bij gevoelige informatie sneller moet gebeuren. Juist ook om de betreffende bedrijven aan de schandpaal te nagelen en aan te sporen het te verbeteren. Al we ze er mee weg laten komen dan blijft het gebeuren.

En ja vaak zijn het externe partijen maar dat maakt niks uit. Als je je gegevensafhandeling uitbesteedt, ben en blijf je zelf verantwoordelijk.

[Kabouterplop01]

Ik vind victim shaming not so nice, maar aan de andere kant snap ik je punt.
Het belangrijkste issue waar nooit iemand over rept is nl. Wat kost het het bedrijf, -een datalek?
De laatste tijd... Helemaal niets en daarom blijft het maar gebeuren.
Als er ergens 2 bedrijven zijn die ergens over in conflict raken en het gaat geld kosten, ... bam rechtzaak.
Heb je bij een datalek wel eens een rechtzaak aangespannen zien worden van hoofdbedrijf naar subbedrijf wat ingehuurd is voor het "bijhouden" van klantgegevens?

Er moet iets veranderen, maar ik weet daar ook het antwoord niet op.
1 ding is leidend: Het heeft sterk de schijn dat juristen dit risico incalculeren, want het gebeurt zo ontzettend vaak, dat het ruikt naar "Laten we die persoonsgegevens maar schrappen als privacy gevoelige gegevens."

[Llopigat]

De bedrijven zijn niet alleen slachtoffers. Dit gebeurt puur omdat ze zelf hun beveiliging niet serieus nemen. De echte slachtoffers zijn de klanten van wie de data op straat ligt.

De overheid moet hier ook een sterkere rol in nemen, de autoriteit persoonsgegevens legt zelden boetes op voor datalekken.

[Milmoor]

Er zullen zeker te veel bedrijven zijn die hun beveiliging niet serieus nemen, maar ook als je de boel wel op orde hebt kan dit fout gaan. Of bij jezelf, of bij een toeleverancier. Op mijn werk hebben we discussies in hoeverre we die moeten controleren. Als ze de juiste certificeringen en rapportages hebben, moeten we dan ook nog achter hun voordeur kijken? Mag dat van hun, en hebben wij de expertise in huis om te beoordelen wat we zien? Ik heb de antwoorden en de conclusies daaruit nog niet. Uiteindelijk blijft het mensenwerk, en is de onnadenkende klik van een medewerker hetgeen toegang geeft.

[The Zep Man]

Er zullen zeker te veel bedrijven zijn die hun beveiliging niet serieus nemen, maar ook als je de boel wel op orde hebt kan dit fout gaan. Of bij jezelf, of bij een toeleverancier.

Je hoort maar weinig van gehackte bedrijven die hun zaken op orde hadden. Kijk bijvoorbeeld naar hoe vaak het alleen al fout gaat met dataretentie. Veel gegevens worden onnodig lang bewaard, wat de impact van datalekken vergroot.

Daarnaast ontbreekt vaak rate limiting. Met één gecompromitteerd account veel meer records opvragen/muteren dan gebruikelijk zonder interventie? Dat is gewoon nalatigheid.

[Reactie gewijzigd door The Zep Man op 20 augustus 2026 22:36]

[CivLord]

Natuurlijk zal een ICT-er altijd van meninhg zijn dat een bedrijf zich 100% in moet zetten om alles zo veilig te maken als volgens de huidige stand van de techniek mogelijk is. Kosten mogen nooit een bezwaar zijn, ook niet wanneer die 50% van de omzet bedragen.

De werkelijkheid is echter dat een bedrijf maar een beperkte marge maakt op de bedrijfsvoering en het budget voor alles, ook voor de ICT beperkt is.
(Wanneer ik niet meteen voor communist uitgemaakt zou worden, zou ik siggereren dat een ICT-er die begaan is met zijn vak misschien niet moet kijken naar welke werkgever hem het hoogste salaris met de beste secundaire voorwaarden kan geven, maar naar welke werkgever/ opdrachtgever hem het hardst nodig heeft.)

[hachee]

Zonder negatief daglicht welke de merknaam aantast zal het ook niet zo boeien.

Maak dan een werkelijks artikel wie er nu weer allemaal de mist in zijn gegaan qua security per week, met de grootste genoemd in de kop.

[croc]

Heb je bij een datalek wel eens een rechtzaak aangespannen zien worden van hoofdbedrijf naar subbedrijf wat ingehuurd is voor het "bijhouden" van klantgegevens?

Volgens mij gebeurt er minstens het volgende bij pakweg die datalek van CEVA :
* DPO en legal van de getroffen klanten vraagt een gedetailleerd onderzoek naar de oorzaak, vrijwel zeker wordt er ook een claim voorbereid. Zowiezo werd er bij samenwerking met elke derde partij een DPA afgesloten.
* CEVA brengt zijn verzekering op de hoogte
* Zowel CEVA als de verzekering doen een diepgaand onderzoek

Dit zijn natuurlijk processen die niet met de buitenwereld gedeeld mogen worden.

Denk maar niet dat de CEO, het management of de IT afdeling van het bedrijf dat lekte fluitend naar huis gaat.

[Reactie gewijzigd door croc op 20 augustus 2026 20:10]

[Morress]

Misschien elke week een datalek-verslag voor lekken wat in NL geen of amper impact heeft en losse artikelen als het bijvoorbeeld een grotere impact of erg gevoelige data betreffen zal. Lastige afweging.

[drakiesoft]

Er is in nl al een instantie voor datalekken. Ik vind het vrij onzinnig dat elke datalek op tweakers gemeld moet worden en begint ook eentonig te worden. Er is nl helemaal niks tweakers aan, meer hackers. Wellicht een nieuwe site aanmaken en bv hackers.net noemen, dan kunnen dit soort zaken en die GTA lekken bv daar gemeld worden. Ik zou die gasten ook geen enkele aandacht geven want dat is ook waarom ze dit doen. Zelfde voor storingen al zijn die wellicht iets meer relevant. Die hoeven echter niet in de nieuwsfeed, maak een apart kopje storing aan en laat mensen daar op aboneren als ze dat willen als ze een notificatie hiervan willen hebben.

[CAPSLOCK2000]

Er is in nl al een instantie voor datalekken. Ik vind het vrij onzinnig dat elke datalek op tweakers gemeld moet worden en begint ook eentonig te worden. Er is nl helemaal niks tweakers aan, meer hackers. Wellicht een nieuwe site aanmaken en bv hackers.net noemen, dan kunnen dit soort zaken en die GTA lekken bv daar gemeld worden. Ik zou die gasten ook geen enkele aandacht geven want dat is ook waarom ze dit doen. Zelfde voor storingen al zijn die wellicht iets meer relevant. Die hoeven echter niet in de nieuwsfeed, maak een apart kopje storing aan en laat mensen daar op aboneren als ze dat willen als ze een notificatie hiervan willen hebben.

Ik ben het half met je eens dat de grote stroom aan datalekken niet echt veel interessant technisch nieuws oplevert. Tegelijkertijd is klein nieuws ook nieuws. Je kan ook dagelijks in het nieuws lezen over dodelijke ongelukken op de snelweg. Nu zit er wel een flink verschil tussen een dodelijk ongeluk en een datalek, maar in het grotere plaatje zijn beide kleine incidenten die voor de meeste mensen niet zo interessant zijn.

Het verschil is dat een dodelijk ongeluk een grote impact heeft op een klein aantal personen, terwijl een datalek een kleine impact heeft op een groot aantal mensen. De totale 'verwachte waardeschade' van een datalek kan hoger zijn (al ga ik me niet branden aan een berekening van hoeveel bits data een mensenleven waard is).

Ik zie wel wat in je idee om een aparte sectie te maken voor datalekken net zoals we de meuktracker hebben voor software-updates.

Ik zou die gasten ook geen enkele aandacht geven want dat is ook waarom ze dit doen

Dat stadium zijn we ver voorbij, hacken & lekken is gewoon big bussiness geworden en de meeste mensen onderschatten nog steeds hoe groot dat probleem is. Aandacht geven blijft belangrijk.

[Dekar]

Ik vond die cryptowallet hack juist de meeste technieuwswaardige van allemaal. De manier waarop dat product is gekraakt was zeer interessant: YouTube: The safest way to store Bitcoin was just hacked...

[Manderlay1]

Wel jammer dat er nergens wordt uitgelegd dat bv een bedrijf als bol meer kliks krijgt, wat weer meer advertentie inkomsten genereert. Ik wil geloven in onafhankelijke journalistiek maar onder paraplu van DGP blijft dat moeilijk, want het bedrijf wilt namelijk zoveel mogelijk winst maken.

Bv waarom werd bol in de titel gezet bij het datalek terwijl het om externe partner ging? Gewoon omdat het meer kliks oplevert. Ik heb hier geen probleem mee.

Maar waarom wordt dit niet aangehaald en erkent in het artikel?

[TijsZonderH]

Omdat het niet zo is.

[oef!]

Uiteindelijk hebben we de afweging gemaakt dit nieuws niet te brengen. Was dat de juiste? Zeg het maar.

Dat lijkt me de juiste afweging. Als de maatschappelijke en journalistieke impact klein is maar er mogelijk vervelende gevolgen zijn voor slachtoffers dan is dat het niet waard.

Aan de checklist kunnen jullie nog toevoegen of het een kritische of belangrijke entiteit is volgens de CBW, mogelijk spicier

[HenkEisDS]

Misschien moet je er een tracker van maken met zoals de meuktracker. Ik vind het wel leuk om te lezen trouwens, klein en groot, keep ‘em coming.

[Barrycade]

Moet zeggen dat ik al redelijk afgestompt ben geraakt van al die hacks.

Ik klik eigenlijk al niet meer op die berichten.

Dacht daarom zonder het bericht nog te hebben gelezen dat jullie naar een systeem zouden gaan om maandelijks een overzichtje te posten van getroffen bedrijven. En alleen de daadwerkelijk opmerkelijke /afwijkende zouden gaan berichten.

[Cergorach]

Zo een checklist is leuk, maar het is geen vervanging voor kennis/ervaring en dat mist gewoon bij de redactie. Ik zag dat laatst nog met meldingen van security gaten die anscih wel meevielen ten opzichte van veel grotere gaten bij VMware waar geen artikel over verscheen.

Zo een checklist doet me denken aan de eerstelijns helpdesks die niet meer hebben dan een script die ze zonder afwijking volgen en waar we al decennia lang over klagen. Zo een checklist kan als tool worden gebruikt, maar niet blind gevolgd moeten worden en zou zeker regelmatig herzien moeten worden.

Een voorbeeld met de recente datalek bende, ipv. elke getroffen winkel te behandelen, zou ik persoonlijk deze getroffen winkels behandelen in het artikel over de oorzaak van het datalek (een leverancier/transporteur), welke je kan updaten. Als zo een traject meerdere weken in beslag neemt kan je een nieuw artikel schrijven "Nog meer slachtoffers hack bij xyz!" en je zou zelfs als dat allemaal afgerond is een diepergaand artikel er over kunnen schrijven (Wat was de oorzaak, hoe is het opgelost, wie waren de slachtoffers, welke klanten, etc.).

[CivLord]

Wat natuurlijk ook meespeelt is waar de redactie op dat moment mee bezig is.

Wanneer iedereen bezig is aan artikelen met deadlines, zal het een lek met een veel grotere impact moeten zijn om een redacteur van een ander verhaal af te halen, dan wanneer er twee redacteuren met hun duimen zitten te draaien omdat er die dag weinig interessant nieuws is.

[mbbs1024]

De EU zou wetgeving moeten maken om bedrijven die aan zulke massale dataverwerking doen, te verplichten om aan een aantal kwaliteitseisen te voldoen, een soort ISO certificatie op het vlak van security, en daar ook op gaan controleren door onaangekondigde audits, net zoals er in bedrijven belastingscontroles of controles op de voedselveilighed gebeuren.