Clinical Diagnostics doet nog onderzoek naar cyberaanval medische onderzoeken

Het Nederlandse onderzoekslab Clinical Diagnostics Nederland doet momenteel nog onderzoek naar de recente cyberaanval, waarbij onder meer medische gegevens van honderdduizenden patiënten gestolen zijn. De oorzaak van het datalek is vooralsnog niet bekendgemaakt.

Het bedrijf erkende maandag direct het datalek na een bericht van Bevolkingsonderzoek Nederland, maar tot dusver waren daar weinig details over bekend. In een persbericht biedt het onderzoekslab zijn excuses aan en laat het weten dat er in samenwerking met 'gespecialiseerde externe experts' onderzoek wordt gedaan naar de oorzaak van het incident. Op basis van het onderzoek besluit het bedrijf of er eventuele extra maatregelen genomen moeten worden.

Maandag werd bekend dat er bij een cyberaanval op Clinical Diagnostics Nederland persoonsgegevens, waaronder burgerservicenummers en medische informatie van honderdduizenden vrouwen, gestolen waren. In eerste instantie zou het alleen om deelnemers aan baarmoederhalskankeronderzoek, uitgevoerd door Bevolkingsonderzoek Nederland, gaan.

Al snel werd echter duidelijk dat ook uiteenlopende andere medische onderzoeksgegevens via het bedrijf gestolen waren. Zorgbeveiligingscentrum Z-CERT meldde dat veel meer zorginstellingen die via Clinical Diagnostics onderzoeken lieten uitvoeren, indirect bij het datalek betrokken waren. Naar verluidt zijn ook gegevens uit huid-, urine-, penis-, vagina- en anusonderzoeken ontvreemd.

Het is nog niet officieel bekend welke gegevens er zijn gestolen bij de cyberaanval op het onderzoekslab. Voor zover bekend gaat het in ieder geval om bijna 500.000 deelnemers aan baarmoederhalskankeronderzoek. RTL Nieuws meldde op basis van een preview van de gestolen data dat er tienduizenden slachtoffers zijn, waaronder mensen die veel andere medische onderzoeken hebben laten uitvoeren.

Door Yannick Spinner

Redacteur

15-08-2025 • 21:09

69

Submitter: Anonymoussaurus

Reacties (69)

Sorteer op:

Weergave:

Fijn dat Eurofins “intensief onderzoek doet” en “de oorzaak nog niet gevonden heeft”… maar als je het naast elkaar zet krijg je toch een ander beeld. Geen mysterieuze APT, maar een niet-gepatchte Citrix-gateway die als N-day is misbruikt, gevolgd door data-exfiltratie door een low-tier groep, en een rookgordijn in de communicatie.

De infrastructuur van laat zien dat Citrix de ruggengraat vormt. Een interne handleiding op Scribd (inclusief linkjes 8)7) toont dat medewerkers het Document Management System via Citrix moeten benaderen. Daar komt bij dat een vacature uit maart 2025 bij NMDL Rijswijk expliciet vroeg om ervaring met Citrix, wat bevestigt dat dit een kernonderdeel van hun omgeving was.

De tijdlijn sluit naadloos aan op de bekende exploitgolf. Tussen 3 en 6 juli vond de datadiefstal plaats, uitgevoerd door Nova, een groep die kant-en-klare PoC’s gebruikt. Hun leaksite en OPSEC zijn van scriptkiddie-niveau.

De communicatie en framing zijn daarmee duidelijk. Termen als “gerichte aanval” en “oorzaak onbekend” passen niet bij de realiteit: dit was opportunistische Citrix-exploitatie. De AVG-meldplicht van 72 uur is zwaar overschreden en het publieke narratief verdoezelt in feite slechts dat een niet-gepatchte NetScaler de zwakke plek was.
Een hele heldere analyse. En ik vraag mij ook af in hoe verre dit ook het geval is. Eigenlijk kan je, zoals je stelt dit optellen en op deze wijze zal een “hack”-groep ook te werk zijn gegaan.

De vacature is een leuke, dit kan zelfs een trigger zijn om te kijken of ze inderdaad te weinig personeel hebben op basis van Citrix expertise.

Wat ik wel regelmatig zie is de laksheid op gebied van patchen en vooral het idee dat een dergelijke change best wel voeten in de aarde heeft en iemand heeft geroepen, wacht maar even want nu zijn wij te druk.

Daarom is een CISO met voldoende mandaat nooit verkeerd. Ik ken bedrijven waar managers zeggen “nee, kan nu niet” en CISO zegt “het moet nu” en de CISO wint ondanks de hiërarchie in het bedrijf.
Helemaal eens! Voor een N-day situatie (zoals bij Clinical Diagnostics) is de oplossing eigenlijk simpel: als je een pre-auth RCE op een internet-facing box hebt, dan laat je álles vallen en patch je direct. Dat is geen Jira-ticket, dat is brandblussen.

Bij organisaties als OM lag het ingewikkelder: zij werden in mei al geraakt toen het nog echt een 0-day was. Daar had patchen nog niet gekund. De enige manier waarop je dat soort stealth-fase aanvallen had kunnen zien, was door alles off-box te streamen:
  • newnslog crashmeldingen → vroegsignaal van AAA/daemon restarts.
  • aaad.debug rare auth-handshakes → aanwijzingen van exploitpogingen.
  • syslog/audit → onverwachte config- of cert-reads.
Zonder off-box streaming wist je niets, want een NetScaler bewaart amper historie en een aanvaller kan bij elke restart sporen wissen. Daarom zei NCSC ook: “traces were deliberately erased.”

Als de eerste actor (pre-patch) niet noisy was geweest, hadden we het waarschijnlijk helemaal niet gezien.
Helemaal eens! Voor een N-day situatie (zoals bij Clinical Diagnostics) is de oplossing eigenlijk simpel: als je een pre-auth RCE op een internet-facing box hebt, dan laat je álles vallen en patch je direct. Dat is geen Jira-ticket, dat is brandblussen.

Bij organisaties als OM lag het ingewikkelder: zij werden in mei al geraakt toen het nog echt een 0-day was. Daar had patchen nog niet gekund. De enige manier waarop je dat soort stealth-fase aanvallen had kunnen zien, was door alles off-box te streamen:
  • newnslog crashmeldingen → vroegsignaal van AAA/daemon restarts.
  • aaad.debug rare auth-handshakes → aanwijzingen van exploitpogingen.
  • syslog/audit → onverwachte config- of cert-reads.
Zonder off-box streaming wist je niets, want een NetScaler bewaart amper historie en een aanvaller kan bij elke restart sporen wissen. Daarom zei NCSC ook: “traces were deliberately erased.”

Als de eerste actor (pre-patch) niet noisy was geweest, hadden we het waarschijnlijk helemaal niet gezien.
Daarom, Splunk! Logging direct naar een centraal logging systeem wat achter een firewall staat. Bovendien kan je op een Netscaler ook nog SNMP traps doen en Syslog dumpen, dus Splunk is niet echt nodig, maar is een extra laag. Kwestie van juist inrichten.

Toen ik zelf nog Netscalers installeerde (ja, ja, ja) had ik bij een klant al aangegeven dat een Netscaler, zoals ontworpen direct Internet facing kon zoals hun architect had bedacht, maar dat ik mij toch comfortabeler voelde met een firewall er voor. Nooit naar geluisterd, maar blijf nog steeds van mening dat dat het beste is. Hun argument was dat je dan het probleem had van NAT/RNAT. Wat natuurlijk vette onzin is, omdat je gewoon een inline firewall er voor zet. Zelf was ik toen gecharmeerd van WatchGuard welke perfecte oplossingen hadden. Maar tja. Geld versus veiligheid versus eigenwijze architect.
Kan mij iemand uitleggen waarom die gestolen onderzoeksgegevens van de deelnemers niet ge-pseudonimiseerd waren zodat alleen met een sleutel die gegevens naar hen te herleiden zouden zijn. En die sleutel zou dan alleen de opdrachtgevers zoals artsen of zorginstellingen moeten hebben.
Voor mij is het ook onduidelijk waarom zo'n onderzoekslab 'alle niet toedoende informatie' zoals: namen, adressen, geboortedata, burgerservicenummers, etc. nodig heeft om huid-, urine-, penis-, vagina- en anusonderzoeken te kunnen uitvoeren.
Is dan een referentienummer of iets dergelijks niet voldoende?
Voor mij is het ook onduidelijk waarom zo'n onderzoekslab 'alle niet toedoende informatie' zoals: namen, adressen, geboortedata, burgerservicenummers, etc. nodig heeft om huid-, urine-, penis-, vagina- en anusonderzoeken te kunnen uitvoeren.
Is dan een referentienummer of iets dergelijks niet voldoende?
Omdat een pathologielab meer doet dan een telling. Een patholoog is een medisch specialist die daadwerkelijk een diagnose stelt op basis van het beeld maar ook van contextinformatie uit het EPD etc.. Nu is dit bij uitstrijkjes redelijk beperkt, maar bij ander weefsel dat door huisartsen wordt aangeleverd wel degelijk van belang. De wet verplicht alle zorgverleners, dus ook pathologen, om op basis van BSN te communiceren.

Vroeger gebeurde dit op basis van het patientnummer van de aanvrager of het BVO uitnodigingsnummer. Maar dat is een uiterst kwetsbaar systeem waarbij patientverwisseling niet uit te sluiten is: nummers zijn gewoon lastig communiceren en namen bevatten vaak typos waardoor electronische verwerking spaak loopt. Veel oudere medici kennen bovendien ook de concepten "administratieve tweeling" en "administratieve splitsing" nog: in praktijk komen dan delen van het dossier bij een andere patient terecht met een sterk gelijkende personalia, of raakte een deel zoek omdat er een andere patient werd aangemaakt bij binnenkomst. Beide kunnen een fatale afloop voor de patient hebben. Zelf ken ik gevallen waar in het dossier bij een patiente voor de derde keer een cervix resectie heeft plaatsgevonden (na één keer is die er echt wel uit). Omdat dit soort diagnoses vaak over kanker gaan is verwisseling en dit soort administratie problemen echt dodelijk en is men in de gehele zorg destijds overgegaan op het BSN.

Belangrijk om te beseffen is ook dat een lab vaak gewoon onderdeel van het ziekenhuis was. Pathologie is best een duur specialisme met veel dure apparatuur en veel dieptespecialisatie (patholoog worden kost je 11 jaar universitaire opleiding tot medisch specialist, daarna volgt vaak een dieptespecialisatie binnen de pathologie in bepaalde weefsels of afwijkingen). Dus veel ziekenhuizen kozen er de afgelopen jaren voor om hun lab te fuseren met dat van andere ziekehuizen en deze dan fysiek te centraliseren. Ik ken de specifieke historie van dit lab niet, maar elk "commercieel" PA-lab dat ik ken is zo ontstaan. En ik ken er heel veel, ik ben 20 jaar op landelijk nivo actief geweest in de pathologie. In die tijd is het aantal laboratoria gedaald van 65 naar 48, waarbij er ook een flinke professionaliseringsslag gemaakt is door de groter wordende labs: meer specialisatie en standaardisatie. Gevolg is dat nu letterlijk SLA's voor bepaalde onderzoeken worden afgesloten zodat bepaalde onderzoeken de uitslag er altijd binnen x uur ligt, wat voor parient en behandeling enorm wenselijk is.

[Reactie gewijzigd door J_van_Ekris op 16 augustus 2025 00:28]

Dank voor uw uitleg.
Ik begrijp dat, afhankelijk van het type onderzoek, context informatie belangrijk is of kan zijn voor een goed onderzoeksresultaat.
En ik wist ook niet dat BSN wettelijk verplicht is, terwijl ik in een Tweaker topic:
nieuws: Autoriteit Persoonsgegevens doet onderzoek naar Clinical Diagnostics na hack
bij de reactie van tweaker Senaxx las dat hij voor z'n werk bij een ziekenhuis "redelijk wat externe aanleveringen aan externe partijen" doet en daarbij nooit het BSN erbij afgeeft.
Ik citeer: "Een BSN nummer is bij ons bijvoorbeeld een no-go. Je kan het als verwerker nog vragen maar dat leveren wij nooit aan".

Maar dan lijkt het mij als leek wel verstandig in de keten van huisartsen/zorgaanbieders met onderzoekslabs en evt. andere instanties, dat het aangeleverde volgens de AVG privacywet gepseudonimiseeert wordt; waarmee, zover ik weet, geen namen, adressen en geboortedata wordt verstrekt.

[Reactie gewijzigd door Berend1954 op 16 augustus 2025 07:53]

En ik wist ook niet dat BSN wettelijk verplicht is, terwijl ik in een Tweaker topic:
nieuws: Autoriteit Persoonsgegevens doet onderzoek naar Clinical Diagnostics na hack
bij de reactie van tweaker Senaxx las dat hij voor z'n werk bij een ziekenhuis "redelijk wat externe aanleveringen aan externe partijen" doet en daarbij nooit het BSN erbij afgeeft.
Ik citeer: "Een BSN nummer is bij ons bijvoorbeeld een no-go. Je kan het als verwerker nog vragen maar dat leveren wij nooit aan".
Tja, dan weet Senaxx in dit geval niet waar hij het over heeft. Ik ben voor veel van de technische inrichting van de landelijke pathologie verantwoordelijk geweest: ik heb zelf de landelijke invoering van BSN in de Zorg begeleid in de jaren '00, en later ook de AVG doorgevoerd. Overal is BSN gewoon wettelijk verplicht en aanvragende zorgverleners leveren die ook netjes aan.
Maar dan lijkt het mij als leek wel verstandig in de keten van huisartsen/zorgaanbieders met onderzoekslabs en evt. andere instanties, dat het aangeleverde volgens de AVG privacywet gepseudonimiseeert wordt; waarmee, zover ik weet, geen namen, adressen en geboortedata wordt verstrekt.
Waarmee je weer de risico's van patientverwisseling introduceert. Je interpreteert de AVG ook te nauw. De AVG vraag is dan ook of de medische specialist deze info nodig heeft voor zijn werk. Een patholoog is een medisch specialist, die moet gewoon een regionaal of landelijk EPD kunnen raadplegen om te kijken of waar hij naar kijkt mogelijk een uitzaaiing van een vorige tumor is, of dat het een nieuwe tumor is. Ook kan een eerdere constatering van HPV serieus ander licht op een stuk weefsel werpen. Dat kan letterlijk een verschil van leven en dood zijn omdat bij ontbreken van deze info de verkeerde behandeling wordt ingezet. Het CBP (voorganger AP) heeft in 2005 in een sectorverkenning al geconstateerd dat ze dit belang medisch dossier voor een goede medische diagnose onderkende en accepteerde. Dit soort informatie opvragen kan en mag alleen op basis van het BSN, ook dat is de wet. En omdat men ook uitslagen dient te verstrekken op basis van het BSN, moet men zelfs het BSN opslaan. Dat is het gevolg van de wet "BSN in de zorg" en de "Wet op de Geneeskundige Behandelovereenkomst". Dit soort informatie is gewoon noodzakelijk voor de uitvoering van het werk en de wet verplicht dan ook dat je ze gebruikt omdat anders de kwaliteit van de zorg in het geding komt.
Je haalt veel wetten aan en hebt ervaring in het veld. Eén ding valt me op: nergens in deze wetten (WGBO ken ik, BSN in de zorg lijkt primair over initiële identificatie te gaan) staat dat iedere informatie transactie het BSN moet bevatten. Dat is voor mijn gevoel de misvatting in je verhaal. De ketenpartners hadden ‘Makkelijk’ een betere oplossing kunnen bouwen, die Niet het over iedere lijn sturen van vele onnodige blokjes PII mogelijk maakte. Exact wat vele roepen: pseudonieme transacties. Deze lekken geven aan dat het bij de implementatie al fout is gegaan. Er is gedaan alsof iets “moest” van de wet, in plaats van nagedacht over hoe het veilig te doen binnen de kaders van vele wetten (w.o. AVG).
Je haalt veel wetten aan en hebt ervaring in het veld. Eén ding valt me op: nergens in deze wetten (WGBO ken ik, BSN in de zorg lijkt primair over initiële identificatie te gaan) staat dat iedere informatie transactie het BSN moet bevatten. Dat is voor mijn gevoel de misvatting in je verhaal.
De wet BSN in de zorg zegt dat letterlijk. Maar als je mij niet geloofd, de AP zegt letterlijk:
Ook moeten zorgaanbieders het BSN gebruiken als zij gegevens uitwisselen met andere zorgaanbieders, zorgverzekeraars en indicatieorganen.
Daar staat ook uitgelegd dat elke zorgaanbieder wettelijk verplicht is het BSN op te slaan.
Je snapt mijn punt wel? Gebruiken is niet gelijk aan 1-op-1 uitwisselen en overal vasthouden? Daar mag van alles tussen zitten. Dat ieder dossier in een database alle records incl. BSN vasthoudt is totale onzin. De gedachte dat het “moet” worden vastgehouden, ontzettend dicht op andere gevoelige data m.i. ook. Het moet worden “gebruikt”. Kijk nog eens in de wet. Die geeft ook hints, bijv. als wordt aangegeven dat de “wijze waarop” het BSN “gebruikt wordt” nader kan worden geregeld.
Je snapt mijn punt wel? Gebruiken is niet gelijk aan 1-op-1 uitwisselen en overal vasthouden? Daar mag van alles tussen zitten.
Zie Artikel 9 van de "Wet op het BSN in de Zorg" zegt dat wel degelijk lettelijk. Artikel 9 van de "Wet aanvullende bepalingen verwerking persoonsgegevens in de zorg" zegt dat nog steeds. Geen woord latijn aan. En ik weet uit eerste hand dat de verantwoordelijke toezichthouders er ook zo over denken.
Dat ieder dossier in een database alle records incl. BSN vasthoudt is totale onzin. De gedachte dat het “moet” worden vastgehouden, ontzettend dicht op andere gevoelige data m.i. ook.
Zie Artikelen 454 tot en met 457 van de "Wet op de Geneeskundige Behandelovereenkomst" en de achterliggende jurispidentie. Zie hier de samenvatting van de AP hierover, die zegt:
Hulpverleners zoals huisartsen, tandartsen en specialisten zijn wettelijk verplicht om gezondheidsgegevens van hun patiënten vast te leggen in een dossier. Dat is nodig voor een goede behandeling of verzorging.
In praktijk moet een medische specialist elke beslissing die hij neemt vastleggen en aan de patient koppelen. Dat is wat de WGBO van hem verwacht. Dit moet met het BSN omdat de wet BSN in de zorg hem dat verplicht. Ook heeft de medisch specialist de wettelijke plicht de data minimaal 20 jaar te bewaren en terug te kunnen vinden als een andere zorgverlener of de patient hierom vraagt. Dat is wat de WGBO artikel 454 verplicht.

[Reactie gewijzigd door J_van_Ekris op 16 augustus 2025 14:25]

Mooi verhaal hoor. Maar wat is er dan mis met een tabel van BSN en uitslag? Dat is in mijn ogen het enige wat ze op hadden mogen slaan.

De hele riedel als voornaam, achternaam, geboortedatum, tel nummer en email, inclusief zorgaanbieders is gewoon teveel informatie en had nooit op hun servers mogen staan. Dit is een enorme schending van AVG en ik hoop dat deze club hier een flinke boete voor krijgt.
Toch een vraag: betekent het verwerken van BSN ook dat je geen pheudonimisering mag toepassen? Dus BSN moet altijd in plain text staan? Sterker nog, ook bij Wet op BSN geldt noodzakelijkheid. Zelfs als je als organisatie bevoegd bent om het te verwerken, moet je alsnog kijken voor welke specifieke verwerking het BSN noodzakelijk is.
Toch een vraag: betekent het verwerken van BSN ook dat je geen pheudonimisering mag toepassen? Dus BSN moet altijd in plain text staan? Sterker nog, ook bij Wet op BSN geldt noodzakelijkheid. Zelfs als je als organisatie bevoegd bent om het te verwerken, moet je alsnog kijken voor welke specifieke verwerking het BSN noodzakelijk is.
Voor directe zorg (communicatie van uitslagen, en het ophalen van medisch dossiers) moet je overal het plain text BSN voor gebruiken. Een versleuteling/pseudonimisering kan werken , zelf ben ik er altijd voorstander van geweest om zo de indices van gevoelige info te ontdoen, maar op de bronsystemen (waar zo'n lab er een van is) ontkom je er niet aan. Als je moet wisselen van sleutel wil je niet dat je patientendossier ontoegankelijk wordt. En veel medische diagnoses, specifiek als het om zaken als kanker gaat, zijn decennia later nog medisch relevant. Dus als je een versleuteling opzet moet het decennia mee kunnen.

Zelf denk ik dat we terug moeten naar de kern van het BSN. Een paar van dit soort lekken bij verschillende instanties (hypotheekverstekkers, grote huisartsenpraktijk, verzekeraar of andere partijen die het BSN moeten gebruiken) en ieders BSN ligt op straat. Eerlijk gezegd denk ik dat dat een kwestie van tijd is. Maar het BSN is ooit ingevoerd als "betekenisloos nummer": het identificeert een burger uniek, maar de bedoeling was dat je er niets mee zou kunnen. De gevoeligheid van het BSN komt deels voort uit dat als je het opgeeft je ineens abbonementen kunt afsluiten etc.. Daar moeten we vanaf.

Een keuze voor een sectorale sleutel zou destijds ook een oplossing geweest zijn. SBVZ zou dan gewoon op basis van BSN een daar bekende zorgsleutel toewijzen in pkaats van het huidige BSN. Maar dat maakt in praktijk je privacy probleem maar iets kleiner: overal moet naam etc. bekend zijn om te kunnen controleren of de patient van het dossier ook de patient in het bed is.
De stelling dat de bijbehorende gegevens (van het aangeleverde te onderzoeken materiaal) NIET versleuteld/ver-pseudonimiseerd hoeft te worden,
met de afweging tussen:

A] De _risico's van patientverwisselingen_
(hoevaak ten tijde van decennias van toen, hoe erg/verschrikkelijk dat toen ook moet zijn geweest)
en
B] Het _lekken van gegevens van 485.000 deelnemers_
(van nu en dan nog maar zwijgen over de toekomst, wat nog gaat gebeuren. En {cynisch} "gelukkig" is er (schijnbaar) nu losgeld betaald {/cynisch})

durf en kan en zal ik geen uitspraak over doen. Een duivels dilemma.

Ook ik citeer: "Als je moet wisselen van sleutel wil je niet dat je patientendossier ontoegankelijk wordt. En veel medische diagnoses, specifiek als het om zaken als kanker gaat, zijn decennia later nog medisch relevant. Dus als je een versleuteling opzet moet het decennia mee kunnen"

Nu lijkt mij, als leek, het ontsleutelen met de oude sleutel en het versleutelen met een nieuwe sleutel van één patientendossier in het EPD geen onoverkomelijkheden te geven voor het toegankelijk maken. Eerder wel, als alle EPD patiëntendossiers in één keer een nieuwe "versleuteling opzet" moeten krijgen en deze, waar ik het mee eens ben: "decennia mee kunnen".

De analyse van het BSN gebruik door
A] "verschillende gewenste instanties (hypotheekverstekkers, grote huisartsenpraktijk, verzekeraar of andere partijen" zoals ook "indicatieorganen" en "zorgaanbieders het BSN gebruiken als zij gegevens uitwisselen met andere zorgaanbieders".
B] minder gewenst gebruik zoals bijvoorbeeld "ineens abbonementen kunt afsluiten etc.."

De gedachte, dat door het veranderen/afschaffen van het in B] genoemde gebruik het probleem oplost is maar gedeeltelijk. Want zonder gebruik van versleuteling, komen de private gegevens van de deelnemers nog steeds op straat te liggen.

De landelijke invoering van BSN in de Zorg in de jaren '00 was toendertijd (wettelijk?) een goed plan. Toen was het internet nog een hype/zeepbel en er was, zover mij bekend, geen nieuws over hacken.

Dus mij lijkt de tijd rijp voor vernieuwing, ook per wetgeving.
Sectorale sleutel?
Nu lijkt mij, als leek, het ontsleutelen met de oude sleutel en het versleutelen met een nieuwe sleutel van één patientendossier in het EPD geen onoverkomelijkheden te geven voor het toegankelijk maken. Eerder wel, als alle EPD patiëntendossiers in één keer een nieuwe "versleuteling opzet" moeten krijgen en deze, waar ik het mee eens ben: "decennia mee kunnen".
Punt is dat zo'n sleutel niet openbaar is of in de hele keten bekend is.

Stel je gaat naar de huisarts waar je onder een bepaalde code bekend bent. Die huisarts stuurt je naar een specialist, waar je onder een andere code bekend bent en waar de vertaalslag van huisartscode naar specialistcode gemaakt kan worden. Die specialist stuurt verschillende monsters met elk een uniek specialist-monstercode naar een laboratorium, waar elk monster onder een andere code bekend is en waar de vertaalslag van specialist-monstercode naar lab-monstercode gemaakt kan worden.
Qua privacy lijkt dit het sumum te zijn. Bij elke stap andere codes en de linkerhand weet niet wat de rechterhand doet. Maar daar ligt ook meteen het probleem.
Stel die specialist werkt bij een kliniek die failliet gaat. Er zit niet genoeg geld in de boedel voor de curator om te zorgen voor een goede permanene archivering van alle gegevens (laat staan dat er nog iemand jarenlang in dienst gehouden kn worden om die gegevens toegakelijk te houden), dus de servers worden gewist en verkocht (met een beetje mazzel wordt er een backup gemaakt die ergens in een kluis verdwijnt, maar in de praktijk vrijwel onbenaderbaar is).
Je huisrts heeft waarschijnlijk een samenvatting van de gegevens van de specialist gekregen, maar misschien niet alle exacte resultaten, want je was in behandeling bij de specialist. Bij een herhaling van de klachten is dan een deel van je medische geschiedenis verdwenen/ ontoegankelijk. Zelfs wanneer de specialis naar je huisarts gecommuniceerd heeft welk laboratorium de monsters onderzocht heeft, is er met geen mogelijkhid meer de koppeling tussen de patiënt en de originele testresultaten te maken.

Daarnaast geldt dat met al die hercoderingen over en weer de kans op fouten veel groter wordt. Een typefout is zo gemaakt en zelf met systemen als de 11-proef kan het gebeuren dat een typefout of verwisseling van cijfers een 'geldig' nummer oplevert.
Wanneer de huisarts het BSN en de gegevens van mw. De Vries aan de specialist doorgeeft, is dat een extra controle. Wanneer de specialist bij het invoeren een typefout maakt en de NAW gegevens van dhr. Jansen ziet, weet hij meteen dat hij een fout gemaakt heeft. En hetzelfde geldt voor de rest van de keten.
De gevoeligheid van het BSN komt deels voort uit dat als je het opgeeft je ineens abbonementen kunt afsluiten etc.. Daar moeten we vanaf.
Dat komt enkel door de luiheid/ gemakzucht van de aanbieder. Voor alles waar je wettelijk gezien een BSN voor nodig hebt, geldt ook een identificatieplicht.

Wanneer je met een BSN iets kunt krijgen zonder dat de aanbieder eist dat je je fysiek identificeert ligt het proleem uiteindelijk bij die aanbieder die iets geleverd heeft zonder goede controle en hoort die aanbieder daar de consequenties van te dragen. (Al zal het je in de praktijk heel veel moeite kosten om die aanbieder de consequenties te laten dragen, wanneer hij accepteert dat een oplichter jouw BSN gebruikt, zonder goede controle.)
Als ik je commentaren lees, lees ik een hoop over wetgeving. Een hoop over de UX van de specialist/lab en nog steeds heel weinig over de medische + NAW data die nu op straat ligt, of de volgende keer.

Het kan niet zo zijn dat omdat "men" dat hele BSN verhaal heeft ingericht omdat oh je, we zijn zo slordig we verwisselen zaken - in een tijdperk van hyper-automation en AI, dat we dan maar bij de eerste de beste Citrix hack ongeremd bij alle data kunnen.

Dat is gewoon om witheet van te worden. Het zijn onze gegevens. Wij mogen eisen hoe daarmee omgegaan wordt. Want wij zijn namelijk ook degenen die met chantage, public shaming, afpersing, fraude te dealen hebben. Net als die brieven nu die overlopen van nietszeggendheid. No one gives a shit - dus wordt het tijd dat we dat zelf doen.
Klopt geheel. Toch is het ook wel mogelijk om anoniem onderzoek uit te voeren. Een voorbeeld zijn de soa-onderzoeken bij GGD’en en commerciële laboratoria. Ook arts-microbiologen worden daarbij vaak als medebehandelaar beschouwd. Ik hoorde van een kennis dat er momenteel problemen spelen op GGD'en rond de invoering van een elektronisch voorschrijfsysteem voor medicijnen, dat verplicht gebruikmaakt van BSN-nummers. Hierdoor wordt anonimiteit feitelijk onmogelijk.

Ik pleit daarom voor een aanpassing van de wet en verplichte scheiding van gegevens: onderzoeksresultaten en andere data zouden altijd gepseudonimiseerd moeten zijn, en uitsluitend via een sleutel te koppelen aan een persoon. Het is een illusie te denken dat gegevens ooit volledig beschermd kunnen worden tegen cyberaanvallen.

Of, we moeten misschien af van het idee van vertrouwelijkheid en privacy, en accepteren dat je gegevens openbaar zijn. Dat kan ook.
Klopt geheel. Toch is het ook wel mogelijk om anoniem onderzoek uit te voeren. Een voorbeeld zijn de soa-onderzoeken bij GGD’en en commerciële laboratoria. Ook arts-microbiologen worden daarbij.
Dat zou vanuit de patient wel enorm onvoordelig uitpakken. HPV (een veel voorkomende SOA) is een precursor van vrij veel kankersoorten. Veel oncologen en pathologen gaan echt anders naar een ziektebeeld kijken als ze weten dat HPV geconstateerd is.

In ziekenhuizen kent men het VIP systeem: de patient wordt dan altijd in zijn geheel onder een pseudoniem behandeld. Maar ik weet niet hoe ver dat wordt doorgevoerd.

Het zou ook niet nodig moeten zijn: ongeacht wie je bent moet je als patient er echt op kunnen vertrouwen dat er fatsoenlijk met je gegevens wordt omgegaan. Dat is wat het medisch beroepsgeheim en de wet daarop borgen. De casus Barbie, waar mensen in een dossier hebben gekeken zonder medische noodzaak, kon echt niet en heeft ook behoorlijk wat mensen wakker geschud. En dan ben je al redelijk vlot je BIG registratie kwijt (= einde loopbaan).
[...]

Dat zou vanuit de patient wel enorm onvoordelig uitpakken. HPV (een veel voorkomende SOA) is een precursor van vrij veel kankersoorten. Veel oncologen en pathologen gaan echt anders naar een ziektebeeld kijken als ze weten dat HPV geconstateerd is.
Nou dat hoop ik toch niet. HPV komt zoveel voor dat je als behandelaar altijd moet denken aan HPV.

Maar, HPV wordt niet getest bij GGD’en en commerciële laboratoria. Het heeft ook geen toegevoegde waarde. Dat is iets voor het bevolkingsonderzoek. Helaas is het daar mis gegaan.

Ik wilde alleen aangeven dat het niet nodig is om alle persoonlijke gegevens te registreren als je onderzoek doet.
In ziekenhuizen kent men het VIP systeem: de patient wordt dan altijd in zijn geheel onder een pseudoniem behandeld. Maar ik weet niet hoe ver dat wordt doorgevoerd.
We hadden regelmatig patiënten opgenomen die anoniem waren. Ze werden ingeschreven onder de naam Jane Doe of een variant. Alle diagnostiek en consulten liepen prima door. Dus, toen kon het ook al.
Volgens mij is ook niet het punt dat je "op dat moment" de zorg kunt verlenen aan Jane Doe, maar dat als volgende week een andere VIP komt die niet verder gaat met het dossier van Jane Doe, of, minstens net zo onwenselijk, als diezelfde Jane Doe een week later terugkomt, bij de juiste Jane Doe de historie gecheckt kan worden.

Nu werk ik niet in de zorg, maar wel regelmatig voor een andere partij waar BSN ook gevoerd mag worden, en het is echt cruciaal dat de juiste info opgehaald wordt.

Misschien zijn er mogelijkheden om op basis van het BSN de overige info op te vragen, maar dat een betreffende afdeling (pathologie in dit verhaal) zelf enkel het BSN opslaat. Controle over wie het gaat, inzicht in compleet medisch dossier, maar in de eigen systemen staat enkel het BSN en de bevindingen.
Vroeger gebeurde dit op basis van het patientnummer van de aanvrager of het BVO uitnodigingsnummer. Maar dat is een uiterst kwetsbaar systeem waarbij patientverwisseling niet uit te sluiten is: nummers zijn gewoon lastig communiceren en namen bevatten vaak typos waardoor electronische verwerking spaak loopt. ...
De vraag blijft dan nog wel waarom voor het BSN is gekozen als zorg-nummer. Het BSN zal niet veel moeilijker of makkelijker te communiceren zijn dan andere nummers, dus dat probleem los je door BSN-gebruik niet op. Daarnaast heeft niet elke patiënt in Nederland een BSN (bijvoorbeeld geborenen voor aangifte bij de gemeente, buitenlanders hebben niet altijd een BSN, of ongeïdentificeerden), bijvoorbeeld een centraal zorg-nummer dat onmiddelijk kan worden aangemaakt door elke zorgverlener in NL zou een dergelijke beperking niet hebben (wellicht wel weer een grotere kans op het ontstaan van meerdere zorg-nummers per persoon, maar dat zou voorkomen kunnen worden door identificatie bij aanmaak (en ook is in de praktijk niet noodzakelijk één persoon aan één BSN gekoppeld)).

Kortom, waarom het BSN in plaats van een centraal zorg-nummer (dat eventueel aan een BSN of ander identificatienummer gekoppeld zou kunnen worden voor fiscale of ID-doelen)?

[Reactie gewijzigd door begintmeta op 16 augustus 2025 10:50]

De zorg communiceert met het BSN. Dat is wettelijk zo vastgelegd. Tenminste voor niet-anonieme zorgvragen.
Inderdaad, de vraag is dan ook waarom men dat wettelijk zo heeft vastgelegd. Ik heb de wetsgeschiedenis niet diepgravend bestudeerd, maar ik krijg er de indruk uit dat fraudebestrijding een sleutelargument is geweest, en dat men daarom alternatieven (zoals een specifiek zorg-nummer, dat eigen nadelen maar ook voordelen zou hebben) niet enorm uitputtend heeft besproken.

[Reactie gewijzigd door begintmeta op 16 augustus 2025 10:57]

De reden zal wel zijn wat deze op andere vlakken ook geweest zal zijn:
"Dit is handig, want dat hebben we al. Dus goedkoop. Hoeven we niets nieuws voor op te tuigen."
Ja, ik denk dat dat misschien inderdaad wel het belangrijkste argument was.
Inderdaad, de vraag is dan ook waarom men dat wettelijk zo heeft vastgelegd. Ik heb de wetsgeschiedenis niet diepgravend bestudeerd, maar ik krijg er de indruk uit dat fraudebestrijding een sleutelargument is geweest, en dat men daarom alternatieven (zoals een specifiek zorg-nummer, dat eigen nadelen maar ook voordelen zou hebben) niet enorm uitputtend heeft besproken.
In mijn beleving was dat een argument, maar patientverwisseling en dossierfouten met hele serieuze medische gevolgen waren vanuit de secotr het zwaarste argument.
Als patiëntverwisseling en dossierfouten de belangrijkste reden zouden zijn voor het gebruik van een zorg-ID-nummer had ik een uitgebreidere afweging verwacht met betrekking tot een specifieke ID voor de zorg. Onder andere omdat niet alle patiënten een BSN hebben, en omdat het ook niet noodzakelijk zo is dat één BSN gekoppeld is aan één patiënt.

Het lijkt me best plausibel dat fraudebestrijding (die reden wordt regelmatig genoemd in de behandeling van de wet) en het gegeven dat er al een BSN-infrastructuur was de leidende argumenten waren voor het gebruik van het BSN in plaats van een andere identificator.

Zoals je ook al aangaf is het probleem van het BSN dat het veel te belangrijk is.

[Reactie gewijzigd door begintmeta op 16 augustus 2025 16:57]

Het grote voordeel van een nummer als BSN over een random nummer is de zogeheten elf-proef.
Er zit letterlijk een controle mechanisme achter waardoor software automatisch kan detecteren of er een typfout begaan is.
Zo'n controlegetalmechanisme (modulo-gebaseerd, Luhn-algoritme of ook een hash-appendix of nog wat anders) kan natuurlijk ook voor een ander getalsysteem dat als zorgID wordt gebruikt worden gedefinieerd, dat is inderdaad erg verstandig.

[Reactie gewijzigd door begintmeta op 16 augustus 2025 16:51]

Uiteraard. Maar dat is atm wel een voordeel over het BSN over een standaard getallen-reeks.
Niet alleen fraudebestrijding.

De kans op fouten/ persoonsverwisseling is ook vele malen kleiner wanneer er per persoon slechts één nummer is waar alle belangrijke overheids- en zorgdiensten mee werken, dat ook op ID-/ legetimatiebewijzen vermeldt staat.
Wanneer je voor elke belangrike dienst/ sector een apart uniek nummer nodig hebt, zorgt dat weer voor andere problemen. Dan moet je een compleet overzich van al die belangrijke nummers bij je hebben, wat in de praktijk niet gebeurt. Paspoort/ ID-bewijs/ rijbewijs heeft iedereen óf bij zich, of ligt op een makkelijk bereikbare plaats thuis. Maar waar liggen mijn Zorg-servicenummer, en mijn Financieel-servicenummer, en mijn Arbeids-servicenummer, en mijn etc.-servicenummer wanneer ik die nodig heb? (Of wanneer mijn familie die nodig heeft omdat ik in het ziekenhuis lig.)

Zo zijn er nu al meer zelfstandigen die problemen hebben gekregen door een specifiek BTW-identificatienummer naast hun BSN, dan er problemen door zijn opgelost.
Niet elke patiënt heeft een BSN. Dat probleem los je dus niet op door het BSN als zorg-ID te gebruiken. Maar op het eerste gezicht lijkt het inderdaad plausibel dat gebruik van een nummer dat ook op Nederlandse identiteitsbewijzen staat voor alles wat (vanuit de overheid of semi-overheid) op een persoon betrekking heeft de kans op fouten of persoonsverwisselingen in de zorg kleiner maakt. Het was dan op zich wel prettig geweest als men bij de behandeling van het wetsvoorstel onderzoek had kunnen meenemen dat kwantificeert hoeveel kleiner de kans op fouten of persoonsverwisseling wordt bij gebruik van het BSN als zorg-nummer tegenover een specifiek nummer voor de zorg.
@begintmeta stelt juist aan de kaak of die keuze door de wetgever wel correct was.

Geparafraseerd:
begintmeta: "Was de keuze om het BSN te gebruiken als wettelijk zorgnummer eigenlijk wel een goede?"
bytemaster460: "Ja- want dat is wat we gekozen hebben."

:+

[Reactie gewijzigd door R4gnax op 16 augustus 2025 10:58]

Een beter antwoord, dat ook al door verschillende anderen gegeven is: Ja, want daarvoor is het specifiek gecreëerd. (Als unieke identifier om alle overheidstaken, waaronder ook de zorg valt, aan één unieke persoon Nederlands ingezetene te kunnen koppelen.)

@R4gnax Zo goed?

[Reactie gewijzigd door CivLord op 19 augustus 2025 07:19]

Niet elke persoon die een medische behandeling moet ondergaan zal een BSN hebben.
Dus het faalt in die taak.
In principe is het bsn een uniek referentienummer. Referentienummers waarvan we stellen dat het enorme risico's geeft bij verkeerd gebruik.

Het verplicht gebruik van bsn is dus geen verklaring waarom een laboratorium zo ongelovelijk veel extra persoonlijke gegevens verwerkt. Waar de opmerking vooral om gaat.

Het is ook geen verklaring waarom een landelijk onderzoeksorganisatie, ziekenhuizen en artsen dit massal extra verwerken maar prima vinden. Het is immers al jaren bekend dat men in de laboratoria, ondanks toezeggingen, fouten maakt. Meer persoonlijke gegevens laten verwerken zorgt niet spontaan voor minder risico's. Eerder het omgekeerde. Al sinds enkel referentienummers gebruikt werden was bekend dat als de persoonlijke gegevens gelekt zouden worden dit enorme impact op patienten heeft. En dat was nog voor er massa digitaal gelekt kon worden via internet. Ik lees geen voortschrijdend inzicht bij laboratoria, organisaties, ziekenhuizen en artsen dit toe te staan. Eerder het omgekeerde: negeren wat het met honderdduizenen tot miljoenen personen doet als een laboratorium een te verwachten fout maakt waarbij al die honderdduizenden tot miljoenen individuele persoonlijke en medische gegevens lekken naar criminelen en de publieke wereld. Dat een laboratorium dat kennelijk weken stil pribeert te houden. Dat het vertrouwen in de personen die hier (door het massaal verwerken maar prima te vinden) daalt. Dat als zelfs maar 1% hierdoor zorg gaat uitstellen of mijden dat grotere gevolgen heeft dan wat men hoopte te verbeteren.

Ja, het bsn is een beter alternatief dan de oude indentificatienummers. Maar nee, het toestaan dat laboratoria er tal van andere persoonlijke identificeerbare gegevens bij verwerken was dat al niet en blijkt dat ook niet te zijn. Zeker in een tijd waarbij we handgeschreven labels en uitwisseling ver achter ons hebben gelaten en er bij lekken meteen honderdduizenden tot miljoenen personen door de zorg gedupeerd worden en die niets kan doen om dat te genezen.
"Het bedrijf erkende maandag direct het datalek na een bericht van Bevolkingsonderzoek Nederland":
??
Het was bij het bedrijf in juli toch al bekend dat de data op straat lag?

Van de website van het bedrijf:
"We hebben even gewacht met het delen van informatie, zodat we eerst de juiste stappen konden nemen. ":
Meerdere weken wachten is niet 'even'. Bovendien: naar het publiek toe is er _inhoudelijk_ anders nog steeds niks bekendgemaakt. Dat is blijkbaar ook niet de gemiddelde gang van zaken (bij andere lekken wordt er ook zelden inhoudelijk iets gezegd over de oorzaak van een lek), maar doe niet alsof de informatievoorziening nu (wel) afdoende is.

[Reactie gewijzigd door kimborntobewild op 15 augustus 2025 21:44]

Het is natuurlijk heel erg wat hier is gebeurd voor alle betrokkenen. Wat ik me wel afvraag, is of Clinical Diagnostics in dit geval optreedt als verwerker of als verwerkingsverantwoordelijke. Ik kan me voorstellen dat zij persoonsgegevens verwerken namens hun opdrachtgevers. In het geval van een datalek is de verwerkingsverantwoordelijke oa verantwoordelijk voor de communicatie richting de betrokkenen.

[Reactie gewijzigd door ElGrandoNeuso op 15 augustus 2025 22:28]

Interessante vraag! Daarnaast is het ook een spannende hoe dit formeel is vastgelegd in overeenkomsten met partijen. Er zullen nu vast wat juristen van partijen aan het kijken zijn wat er is afgesproken.
Voor de wet zullen ze optreden als verwerker.
En dan hangen ze alsnog, want er is voor verwerkers een wettelijke plicht om zonder onredelijke vertraging de verwerkingsverantwoordelijke in te lichten over een datalek zodra deze geconstateerd is.

Je mag als verwerker niet zomaar een paar weken zaken onder de pet houden.

[Reactie gewijzigd door R4gnax op 16 augustus 2025 10:42]

"En dan hangen ze alsnog":
Ze hangen niet. Ze betalen een kleine boete, en betalen de criminelen (wat absoluut fout is, want daarmee wordt het probleem juist groter), en that's it.
De boetes in NL stellen geen ruk voor.
Het laboratorium werk in opdracht van wie wettelijk de afspraken maakt om ingezet te worden. Bij bevolkingsonderzoek is dat de landelijke organisatie, bij onderzoek via het ziekenhuis het ziekenhuis en via de huisarts de huisarts. Het feit dat personen hun gegevens op verzoek rechtstreeks naar het laboratorium sturen doet daar niets aan af. Als je voor samenwerking met je provider bij een door hun ingehuurde klantenservice je persoonlijke gegevens kenbaar maakt is dat ook niet anders.

Ik verwacht niet dat het laboratorium de personen zomaar rechtstreeks mag benaderen. Het verwerkingsdoel is immers het doen van onderzoek voor de directe opdrachtgever, niet het informeren over problemen aan deelnemers in het onderzoek. En zoals ik het nieuws (artikel in nrc) lees lijkt geen van de opdrachtgevers sinds het ontdekken van het lek rond 6 juli ook maar enige informatie ontvangen te hebben van welke personen er gegevens gelekt zijn. Wat in principe geen reden hoeft te zijn om dan maar helemaal niemand persoonlijk te informeren.

[Reactie gewijzigd door kodak op 16 augustus 2025 13:48]

Net ook het NRC-stuk gelezen, dank voor het attenderen. Het komt wel over alsof de verwerkingsverantwoordelijke partijen te weinig grip hebben op de verwerker. Afspraken over de omgang met datalekken leg je normaliter vast in een verwerkersovereenkomst. Nu lijkt het echter alsof partijen naar elkaar wijzen en onduidelijk is wie, wat en wanneer moet doen. Wat NRC ook opmerkt, is dat er sinds afgelopen woensdag bij het Bevolkingsonderzoek NL een vacature voor een FG online staat. Dat kan natuurlijk toeval zijn.
Net ook het NRC-stuk gelezen, dank voor het attenderen. Het komt wel over alsof de verwerkingsverantwoordelijke partijen te weinig grip hebben op de verwerker. Afspraken over de omgang met datalekken leg je normaliter vast in een verwerkersovereenkomst. Nu lijkt het echter alsof partijen naar elkaar wijzen en onduidelijk is wie, wat en wanneer moet doen.
Het afsluiten van een verwerkersovereenkomst is extreem standaard in de zorg, zelfs voor de introductie van de AVG. Dit lab is op basis van een Europese aanbesteding geselecteerd voor het BVO werk, lijkt me sterk dat er geen eisen aan informatiebeveiliging zijn gesteld. In de zorg is werken conform NEN7510 gewoon een wettelijke vereiste sinds 2008 (zie "Wet aanvullende bepalingen verwerking persoonsgegevens in de zorg"). Let wel, je moet er aan voldoen, alleen certificering is niet verplicht.

Ik moet zeggen dat de grens van verwerkingsverantwoordelijke en verwerker hier niet zo scherp voor mij is. De rol verwerker wordt normaal bepaald als de opdrachtgever eigenaar is van de data en zelfstandig kan bepalen hoe de verwerker het werk uitvoerd.

Aan de ene kant is RIVM/BVO opdrachtgever en verstrekker van de identiteit is, maar anderzijds komen de medische gegevens van de specialist en vallen deze dus direct onder de WGBO. Omdat de WGBO bepaald hoe data verwerkt wordt, en niet BVO NL kan het wel eens zijn dat hier een gemeenschappelijke verwerkingsverantwoordelijkheid ligt (zie ook de uitleg van de AP).
Wat NRC ook opmerkt, is dat er sinds afgelopen woensdag bij het Bevolkingsonderzoek NL een vacature voor een FG online staat. Dat kan natuurlijk toeval zijn.
BVO NL had vier jaar geleden een FG (daar had ik destijds zeer regelmatig contact mee). De FG heeft een signalerende/controlerende/toezichthoudende rol, geen beslissende, dus hiervoor verantwoordelijk houden is onmogelijk. En een FG heeft een beschermde juridische status vergelijkbaar met OR-leden, die kun je niet zomaar uit zijn/haar functie zetten. Dus ik zou van toeval uitgaan.
Ik kan je zeggen dat bevolkingsonderzoek Nederland de brieven (op dit moment ook actief) verstuurt met berichtgeving aan de getroffen mensen
Ik denk dat dit nieuw is voor zo’n bedrijf, meerdere weken om te leren en advies te krijgen is niet veel.
De AVG is niet nieuw voor dit bedrijf, hoor. Als jij een vermoeden hebt dat er data is gelekt, dan moet je daar wat mee - waaronder risico gebaseerd afwegen of je betrokkenen moet of gaat informeren. Dit is niet bedoeld als coulance, maar om betrokkenen een kans te bieden zich (zelf) in veiligheid te brengen of anderzijds de impact te beperken. Uitstel van communicatie is daarmee een door verwerker gecreëerde en onnodige ondermijning van de risicobeheersing.

Gezien de aard van de gegevens (bijzondere persoonsgegevens; medische in dit geval) en de omvang van je klantenbestand (honderden duizenden betrokkenen) is een vermoeden van een datalek in dit geval al haast per definitie hoog risico en daarmee genoeg aanleiding om betrokkenen/verwerkingsverantwoordelijken gelijk te informeren over dat er op zijn minst - tot nader order - iets ongebruikelijks met de gegevens is gebeurd en dat waakzaamheid geboden is voor eventueel misbruik.

Dat onderzoek lang kan duren is begrijpelijk en vaak noodzakelijk, maar dat een dergelijk onderzoek nieuw voor je is kan geen reden zijn om te verzaken in je meldplicht.

Dat ze er bewust voor hebben gekozen om communicatie uit te stellen vind ik dan ook kwalijk.
De avg (het bestaan) zal niet nieuw zijn, maar hoe om te gaan bij een hack waarschijnlijk wel.
Het enige wat Clinical Diagnostics als verwerker zou hoeven doen, is Bevolkingsonderzoek Nederland inseinen. De verwerkingsverantwoordelijke bepaalt de verdere afhandeling inzake risico-afweging of de inbreuk gemeld moet worden; melding aan en communicatie met de AP; en evt. meldingen aan de betrokkenen.

Voor een verwerker is er nul-komma-niets interessants aan de te volgen procedures om aan de AVG / GDPR te kunnen voldoen.
Ik denk dat dit nieuw is voor zo’n bedrijf, meerdere weken om te leren en advies te krijgen is niet veel.
Dan hebben ze echt zitten slapen. Ik weet heel erg zeker dat ze in 2017 en 2018 hiervan op de hoogte zijn gesteld. Volgens mij moeten ze zelfs een DPO hebben omdat ze gevoelige medische informatie verwerken.

Op sommige momenten kan er discussie ontstaan of je meldingsplichtig bent. Er zit een grijs gebied in de meldingsplicht waarbij de vraag ontstaat "is het aannemelijk dat er inbreuk op de data van betrokkenen heeft plaatsgevonden?". Als DPO moet je dan gewoon melding doen bij de AP. Maar ik kan me voorstellen dat in een directie de angst voor publiekelijk aan het kruis genageld te worden serieus meespeelt en men dus terughoudend is om dit proces in gang te zetten. Wettelijk heeft men geen keuze, maar soms ziet men hem wel zo helaas.
Op sommige momenten kan er discussie ontstaan of je meldingsplichtig bent.
Een verwerker is nooit meldingsplichtig aan de gegevensbeschermingsautoriteit en is nooit meldingsplichtig aan de betrokkenen. Een verwerker is altijd meldingsplichtig aan de verwerkingsverantwoordelijke.

Het is de verwerkingsverantwoordelijke die de risico-afweging moet maken en moet besluiten of verdere melding nodig is.

[Reactie gewijzigd door R4gnax op 16 augustus 2025 10:48]

Een verwerker is nooit meldingsplichtig aan de gegevensbeschermingsautoriteit en is nooit meldingsplichtig aan de betrokkenen. Een verwerker is altijd meldingsplichtig aan de verwerkingsverantwoordelijke.

Het is de verwerkingsverantwoordelijke die de risico-afweging moet maken en moet besluiten of verdere melding nodig is.
Klopt, maar mijn beeld is dat BVO NL het ook pas afgelopen week wist. Of heb ik in de berichtgeving iets gemist?
Ja. BVO NL wist het pas afgelopen week. Clinical Diagnostics wist het schijnbaar al sinds juli, maar hield het onder de pet. Uit hun eigen berichtgeving: "We hebben even gewacht met het delen van informatie, zodat we eerst de juiste stappen konden nemen."

Daarmee gaan ze wettelijk nat als verwerker. Ze hebben een meldplicht om zonder onredelijke vertraging de verwerkingsverantwoordelijke in te lichten nadat het lek geconstateerd is. Let wel: de vertraging mag redelijk zijn, dwz. hiermee vang je zaken af zoals berichtgeving die een dag of twee kan duren om zich door de administratieve papiermolen te bewegen. Maar de meldplicht zelf ontstaat onmiddelijk. Je mag dus helemaal niet beslissen om eerst op eigen houtje te gaan pogen je hachje te redden voordat de beslissing valt om maar eens een bericht richting de verwerkingsverantwoordelijke te gaan sturen.

De engelse verwoording in de GDPR is ook meer dekkend: 'without undue delay.'
Er zit nogal een nuance verschil tussen die uitdrukking en de platte nederlandse vertaling 'zonder onredelijke vertraging.'
Een betere vertaling zou zijn geweest: 'zonder onredelijk bijkomende vertraging.'

[Reactie gewijzigd door R4gnax op 16 augustus 2025 11:16]

Het zou mooi zijn moest men ook laten weten hoe het lek er gekomen is... een phishing mail? Vermoedelijk... Maar daarna, wat gebeurde dan, waarom werd dit niet opgemerkt of gestopt...
Van wat ik begrepen heb van berichten hier en daar zijn ze via de laatste citrix vulnerability binnen gekomen.
Voordat Citrix meteen weer wordt afgefikt: deze 0-day werd al een paar weken voordat Citrix op de hoogte was misbruikt door bepaalde groeperingen.
En is helaas het zoveelste lek in de Netscaler line up in de afgelopen jaren. Daar valt echt wel iets over te zeggen. De lekken en patches volgen elkaar in redelijk hoog tempo op net als bij bv Fortinet. Een Netscaler is (mede) een security product. Dat daar dermate vaak lekken in zitten met behoorlijke tot grote impact is zorgwekkend.
https://www.cvedetails.com/top-50-vendors.php?year=2025

Dit vertelt een heel ander verhaal. Namelijk dat Fortinet vele malen gevaarlijker is om mee te werken dan Netscaler. Fortinet haalt het nieuws niet meer tegenwoordig.
Wel is het helaas zo dat als er een Netscaler vulnerability gevonden is, de impact hoger lijkt dan wanneer Fortinet weer eens lek is.
Wat an sich logisch is gezien de plaats waar een Netscaler zich bevind.
Je linkt naar de top vendors. Dat is natuurlijk geen eerlijke vergelijking. De ene vendor levert een paar producten, de andere heel erg veel. Daarnaast toont dit overzicht helemaal geen impact. Een CVE met een base score van 1.0 en 10.0 zijn in het overzicht gelijkwaardig. Kortom, je hebt niets aan dit overzicht om je statement te onderbouwen (dwz het onderbouwt jouw statement totaal niet).

Dat de impact by default hoger is dan wanneer Fortinet een lek heeft is een generalisatie die je absoluut niet kan maken zonder meer van de betreffende infrastructuur te weten.

[Reactie gewijzigd door Bor op 16 augustus 2025 11:36]

"Op basis van het onderzoek besluit het bedrijf of er eventuele extra maatregelen genomen moeten worden."

8)7 uh... lijkt mij vrij duidelijk dat maatregelen genomen moeten worden of mis ik iets?
Weet iemand of betrokkenen - los van persberichten - al geïnformeerd zijn? In mijn omgeving heeft (nog) geen enkele persoon tot nu toe bericht gehad. Een statistisch wondertje.

Over het algemeen stoor ik mij vaak aan de terughoudendheid en traagheid in communicatie naar betrokkenen, zeker ook om het gevoerde argument "we doen nog onderzoek". Het starten van een onderzoek naar een datalek is al een trigger om betrokken te informeren, zodat zij zelf alert kunnen zijn op tekenen van misbruik of zelf preventieve maatregelen kunnen treffen. Doe je dat niet dan stel je betrokkenen mogelijk onnodig bloot aan verhoogde risico's.

De oorzaak van dit gedrag zit hem denk ik in twee factoren:

De eerste is dat wet- en regelgeving en adviezen van o.a. de AP allen vermelden dat de afweging om betrokkenen te informeren moet gebeuren op basis van het risico dat betrokkenen lopen en daarnaast eisen stellen over wát je moet communiceren. De daarbij aangedragen lijstjes lijken daarbij te impliceren dat je het hele lijstje compleet moet hebben om een risico te kunnen vaststellen. Wat niet zo is, natuurlijk.

Ten tweede: organisaties beseffen te weinig dat onzekerheid de definitie is van risico. Als jij gaat onderzoeken of er daadwerkelijk iets mis gaat, bestaat het risico al (want blijkbaar heb je onvoldoende zekerheid om het uit te sluiten). Wanneer een risico werkelijkheid is, spreek je niet meer van een risico, maar van een incident met mogelijke gevolgschade. Organisaties proberen te vaak vast te stellen of er een incident bestaat en welke gevolgschade er is, voordat ze communiceren over het risico.

Kortom: wanneer je ook maar de neiging hebt om te gaan onderzoeken, kan je erg snel betrokkenen beginnen met informeren: "Lieve mensen, wij merken iets vreemds en zijn een onderzoek gestart, wij verwerken dit soort gegevens van jullie en weten nog niet of en van wie deze gegevens ook daadwerkelijk zijn gelekt, maar wees even alert terwijl wij uitzoeken of en wat er precies aan de hand is."

Toevoeging: een derde factor is dat de organisatie zijn eigen belangen natuurlijk gaat meewegen (imagoschade, voorkomen van boetes etc.). Maar daar heeft de wet natuurlijk geen boodschap aan.

[Reactie gewijzigd door E!Ma0RB7 op 16 augustus 2025 05:51]

Hoeft geen statistisch wondertje te zijn aangezien dit bedrijf slechts enkele regio’s in Nederland bedient. Geen idee verder of mensen al direct benaderd zijn.
Weet iemand of betrokkenen - los van persberichten - al geïnformeerd zijn? In mijn omgeving heeft (nog) geen enkele persoon tot nu toe bericht gehad. Een statistisch wondertje.
Ergens gehoord dat brieven pas vanaf 18 aug verstuurd gaan worden.
Ook al iets, mijn vrouw heeft het nieuws gelezen en krijgt als antwoord “wij kunnen geen mededelingen doen”. Ze weet alleen dat ze in die resultaten “kan” zitten maar niet hoeft te zitten vanwege onduidelijkheid vanuit de overheid zelf.

Ze beseffen totaal niet wat voor impact het heeft en hier thuis wordt al aangegeven dat ze met geen enkel onderzoek meer durft mee te doen.
Ja- dat is idd wat je krijgt in dit soort gevallen, waar de verwerker de zaak onder de pet heeft pogen te houden - e.e.a. toch uitkomt (en terecht) en de verwerkingsverantwoordelijke op dat moment met de broek op de enkels staat en snel-snel moet gaan regelen mensen alsnog in te lichten.

Heel erg om te horen dat dit binnen het gezin zo gebeurd, natuurlijk. Maar ook BVO-NL moet de administratieve molen opstarten om die brieven er uit te krijgen - en bij telefonisch contact zullen ze ook niet toegang hebben tot de gegevens die nodig zijn om te kijken of een persoon tussen de betrokkenen zit of niet. (En maar heel goed ook, dat dat niet kan. Denk even na: dat zou betekenen dat arbitraire telefoonmedewerkers bij medische gegevens kunnen komen...)

Ik hoop dat e.e.a. gaat resulteren in een gigantische boete voor Clinical Diagnostics, alsmede een verhaal van schade vanuit BVO-NL voor het permanent schaden van de reputatie van deze levens reddende onderzoeken. En misschien ook nog schadevergoeding voor de psychologische schade die dit bij alle betrokkenen aanricht.

[Reactie gewijzigd door R4gnax op 17 augustus 2025 14:10]

Ik maak mij meer zorgen om:
Op basis van het onderzoek besluit het bedrijf of er eventuele extra maatregelen genomen moeten worden.
Dus het kan er op neer komen dat de maatregelen te duur zijn, dan hebben we een mooi rapport maar doen er niks mee.

Op dit item kan niet meer gereageerd worden.