Datalek bij psychiatrisch centrum Parnassia door fout in e-mailverzending

Door een fout van een werknemer zijn 450 e-mailadressen van autismecentrum Parnassia uitgelekt. Het gaat om 'relaties' van de instelling, waarbij het waarschijnlijk ook om patiënten gaat. De e-mail werd verstuurd in het aan-veld in plaats van het bcc-veld.

De uitgelekte e-mail is ingezien door de NOS. Het gaat om een e-mail waarin ontvangers worden opgeroepen een afspraak te maken op een nieuwe locatie van het zorgcentrum. De ontvangers werden door een werknemer in het aan-veld gezet, in plaats van in het bcc-veld.

Het zorgcentrum uit Den Haag specialiseert zich in patiënten met psychiatrische klachten en autisme. Het is daarom extra pijnlijk dat de e-mailadressen zijn uitgelekt. Daaruit kan waarschijnlijk makkelijk worden opgemaakt wie er mogelijk psychiatrische problemen heeft. Volgens de AVG zijn medische gegevens 'bijzonder persoonsgegevens', wat betekent dat die extra goed beschermd moeten worden.

Parnassia zegt tegen de NOS dat het datalek heeft opgegeven bij de Autoriteit Persoonsgegevens. Dat is verplicht volgens de privacywet. Ook zegt een woordvoerder dat het excuses heeft gemaakt aan betrokken. Het centrum zegt daarnaast dat het maatregelen treft om dergelijke incidenten in de toekomst te voorkomen. "Dergelijks mails zullen vanaf nu alleen nog worden verstuurd als iemand extra meekijkt."

Reacties (86)

Wat ik mij bij dit soort datalekken altijd afvraag. Waarom doet men dat nog steeds via een e-mail client achtige oplossing? Er zijn legio systemen op de markt die dat gewoon fatsoenlijk voor je kunnen regelen zonder dat er gekopieerd en geplakt hoeft te worden. Elk zichzelf respecterend crm systeem kan dat out of the box..

Wat ik mij afvraag: Waarom waarschuwt een emailclient hier niet voor? 450 mailaddressen in het 'TO' veld is nog een enorme red flag?

Het lijkt mij nog beter om in een mailserver een check te doen dat als de ontvangers meer dan 5 zijn (bijvoorbeeld) de "to" header te verplaatsen naar de "bcc" en de "sender" naar de "to".
Dan krijg de persoon zelf de mail terug, valt op en weet je dat alles opeens in de bcc staat.

Enige nadeel is dan waarschijnlijk dat men hieraan gaat wennen en als "feature" gaat beschouwen, waardoor in de toekomst bij een andere server dit weer mis gaat.

Het lijkt mij nog beter om in een mailserver een check te doen dat als de ontvangers meer dan 5 zijn (bijvoorbeeld) de "to" header te verplaatsen naar de "bcc" en de "sender" naar de "to".
Dan krijg de persoon zelf de mail terug, valt op en weet je dat alles opeens in de bcc staat.

Enige nadeel is dan waarschijnlijk dat men hieraan gaat wennen en als "feature" gaat beschouwen, waardoor in de toekomst bij een andere server dit weer mis gaat.

Er is volgens mij nog een belangrijker nadeel, namelijk: ongewenste feature... er gebeuren bij ons genoeg vergaderingen/projectwerk waarbij e-mail als communicatiemiddel wordt gebruikt... dan is het best handig als je ziet wie de mail allemaal krijgt en wie niet. Ook zou de handige feature van Outlook verdwijnen, nl. dat als je een ontvanger in de tekst vermeldt, deze automatisch van CC naar To verplaatst wordt. Verder biedt jouw oplossing evenmin een oplossing als er velen in CC geplaatst worden.
Voor mij als ontvanger is het bovendien een groot verschil of ik in To dan wel CC sta... met BCC zou ik elke mail eerst volledig moeten lezen om prioriteit te bepalen.

Samengevat: laat de verzender liever de beslissing maken (de mailclient kan nog steeds verwittiging geven bij "verdacht" aantal "To"-adressen) ipv mailserver.

Het is best handig? Dat is helemaal niet de bedoeling van het to veld, hooguit het cc veld. Als je een brief schrijft aan meerderen geef je onderaan toch ook expliciet een lijpst met wie er een copy ontvangen?
Impliciet een technisch veld daarvoor gebruiken is bad, hoewel algemeen, practice.

Het is best handig? Dat is helemaal niet de bedoeling van het to veld, hooguit het cc veld. Als je een brief schrijft aan meerderen geef je onderaan toch ook expliciet een lijpst met wie er een copy ontvangen?
Impliciet een technisch veld daarvoor gebruiken is bad, hoewel algemeen, practice.

Ik begrijp je reactie, maar ben het niet met je eens. Een To veld dient voor de rechtstreekse ontvanger van een mail (die er iets mee moet doen), CC dient ter kennisgeving (dat is écht wel de oorsprong van Carbon Copy). Kan je even aangeven waarom ik de lijst van bestemmelingen onderaan moet dupliceren? Daar zie ik geen nut in. Bovendien verloopt de meeste van mijn communicatie met "peers"... de leidinggevenden staan, waar nodig, in CC (omdat zij enkel op de hoogte moeten zijn en zelf niets doen).
Oprechte vraag: in mijn ogen gebruik ik de velden net waarom ze er zijn... ik ben benieuwd waarom je dat bad practice noemt.

Ik ben het niet met je eens dat die velden er voor de ontvanger zijn. Ze zijn voor de verzender om ze te adresseren en zouden voor de ontvanger best verborgen mogen zijn. Dan kan dit soort dingen ook niet meer gebeuren.

Ik ben het niet met je eens dat die velden er voor de ontvanger zijn. Ze zijn voor de verzender om ze te adresseren en zouden voor de ontvanger best verborgen mogen zijn. Dan kan dit soort dingen ook niet meer gebeuren.

Ik heb de specs eens nagekeken en die spreken toch tegen wat je zegt.
Neemt natuurlijk niet weg dat je kan vinden dat de specs veranderd moeten worden... al zie ik in jouw redenering dan geen nut meer in onderscheid tussen To, CC en BCC.

Sorry, maar dat doen ze niet. Ik zie nergens in 'de specs' dat To:, Cc: of Bcc: velden er zijn om de ontvanger te laten weten aan wie die e-mail allemaal gestuurd is. Het is waar dat het Bcc-veld er expliciet is om te voorkómen dan een ontvanger de adressen van de overige Bcc-geadresseerden kan achterhalen, maar er staat nergens enig adres voor de ontvanger zichtbaar móet zijn.

Ik vind de To, Cc en Bcc velden 'technische velden' die misschien voor de eerste gebruikers van e-mail wel lekker praktisch waren, maar voor Jan en Alleman die tegenwoordig e-mailen is het beter als die techniek van het gebruik wordt ontkoppeld, dus geen technische velden gebruiken (Cc:) om inhoud (wie ontvangt er allemaal email) te verspreiden.

Daarom zou het beter zijn als àlle adresvelden, behalve het 'From:' natuurlijk, onzichtbaar zouden zijn en dat de verzender zorg draagt voor de inhoud, namelijk Cc: list invoegen als hij dat gevoeglijk vindt.

Sorry, maar dat doen ze niet. Ik zie nergens in 'de specs' dat To:, Cc: of Bcc: velden er zijn om de ontvanger te laten weten aan wie die e-mail allemaal gestuurd is. Het is waar dat het Bcc-veld er expliciet is om te voorkómen dan een ontvanger de adressen van de overige Bcc-geadresseerden kan achterhalen, maar er staat nergens enig adres voor de ontvanger zichtbaar móet zijn.

De specs zeggen inderdaad niet dat de To- en CC-adressen zichtbaar moéten zijn, maar vermelden wel "The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains addresses of recipients of the message whose addresses are not to be revealed to other recipients of the message." ... als het de bedoeling was dat To en CC onzichtbaar waren, dan zou BCC toch niet bestaan?

Ik vind de To, Cc en Bcc velden 'technische velden' die misschien voor de eerste gebruikers van e-mail wel lekker praktisch waren, maar voor Jan en Alleman die tegenwoordig e-mailen is het beter als die techniek van het gebruik wordt ontkoppeld, dus geen technische velden gebruiken (Cc:) om inhoud (wie ontvangt er allemaal email) te verspreiden.

Daarom zou het beter zijn als àlle adresvelden, behalve het 'From:' natuurlijk, onzichtbaar zouden zijn en dat de verzender zorg draagt voor de inhoud, namelijk Cc: list invoegen als hij dat gevoeglijk vindt.

Ik begrijp je argumentatie en ik vind dat je argumenten zeker hout snijden.

Wat ik vooral meen te lezen, is dat je een aanpassing van de specs wenst (zoals eerder gezegd en zonet herhaald, vind ik je argumenten zeker de moeite waard)... en minder wat er al staat.

Nu goed, ik vond deze discussie zeker zinvol (zowel omdat ik de specs nu eens effectief gaan lezen ben, als dat ik jouw argumenten zinvol vind).

edit:
damn jou, autocorrect, ik heb helemaal geen specie nodig

[Reactie gewijzigd door edeboeck op 25 augustus 2019 22:05]

Ok, discussion closed, behalve ...
Dat ik vind de Bcc erkent dat velden anders zichtbaar zijn, niet dat ze dat zouden moeten zijn.

Bedankt

Daar heb je een heel goed punt! Ik noemde de 5 ook als voorbeeld, maar dat kan natuurlijk ook 20 zijn.
Ik kan me bijna niet voorstellen dat er vergaderingen zijn / projectwerk waarbij je in je TO/CC veld meer dan 20 personen nodig hebt.
Daarbij denk ik ook dat de manier waarop jij het omschrijft je al bewust bezig bent met de keuze van To/CC/BCC.

Ik kan me best voorstellen dat een mailserver vele adressen in een TO gaat omzetten naar een BCC of eventueel bounced naar de verzender. Als je 5 mensen in de TO zet en 10 in de CC en 50 in de BCC dan is dat sowieso al een bewuste keuze geweest en hoeft de mailserver niets te doen (getallen zijn uit de lucht gegrepen).

Het probleem blijft evenwel van zodra je de getallen concretiseert... en als je de aantallen erg gaat oprekken, heeft het geen zin meer (dan sta je even goed datalek toe)... daarom geloof ik dat de enige oplossing bij de gebruiker ligt (met ondersteuning van de mailclient).
Zelf ben ik daar inderdaad bewust mee bezig, maar veel van mijn collega's niet... bewustmaking blijft volop nodig (ook m.b.t. reply-to-all ).
Helaas zou zelfs de "intelligente" mailserver (die niets doet bij "bewuste" To/CC/BCC) nog in de fout kunnen gaan, want wat als ik er bewust mee bezig ben, maar enkel "To's" heb? Het probleem blijft dat de mailserver niets kent van de intenties van de verzender (en laat ons dat, ondanks de problemen van tijd tot tijd, alsjeblieft zo houden als we nog een schijntje privacy willen behouden).

Helemaal waar hoor! Ik ben dit volkomen met je eens.
Maar voor zo'n instelling als dit zou bijvoorbeeld een "cap" op x aantal in ieder geval zorgen voor een kleiner lek. 450 adressen in een "to" is natuurlijk ook absurd, dat mag door een mailserver best afgekapt worden bij 10.

Als jij 10+ mensen in het To veld moet hebben van een e-mail, doe je iets verkeerd.
Dan had je óf een mailgroep moeten maken óf op een andere manier handiger kunnen communiceren (een Teams werkgroep of ander vorm van project management groep).

E-mail is niet bedoeld voor broadcasting, daar zijn andere systemen/platformen veel beter voor.

Als jij 10+ mensen in het To veld moet hebben van een e-mail, doe je iets verkeerd.
Dan had je óf een mailgroep moeten maken óf op een andere manier handiger kunnen communiceren (een Teams werkgroep of ander vorm van project management groep).

E-mail is niet bedoeld voor broadcasting, daar zijn andere systemen/platformen veel beter voor.

Volledig met je eens dat dat beter zo zou zijn... echter heb je in de praktijk te maken met het feit dat je geen rechten hebt om een mailgroep aan te maken (uiteraard wel op je mailclient, maar dat verandert toch zuiver in de adressen op zich) en dat je collega's geen Teams gebruiken (tenminste, dat is bij ons toch het geval). Waar ik bij andere groepen volop communiceer met Teams en Slack, moet ik het bij de meeste van mij collega's met e-mail doen... en, neen, dan heb ik niet het gevoel dat ik verkeerd bezig been, ook al zou ik liever andere kanalen gebruiken... dan pas ik me aan aan het meest praktische.

Uiteraard heb je gelijk.

Wij zijn bij ons op het werk recentelijk ook begonnen met Microsoft Teams. Iedereen heeft een introductory 'cursus' gehad van wat Teams kan en hoe je er mee werkt.. maar in praktijk blijven veel mensen gewoon e-mail gebruiken.

Moet zelf ook bekennen dat ik vaak liever een e-mail stuur dan een berichtje post in Teams.
Om nog maar niet te beginnen over het feit dat Team je STANDAARD geen notificaties geeft wanneer iemand een nieuw bericht plaatst in een Team (dit moet je per kanaal handmatig aan zetten wat écht te zot voor woorden is).

Het issue dat ik echter heb met e-mail versus Teams is dat, in het geval dat je bijvoorbeeld een bestand van 5 mb moet delen met 20 mensen, de server dat bericht + die bijlage 21x opslaat: 1x in ieder zijn inbox en 1x in jou sent items box.

Als je elke dag zulk soort e-mails stuurt (bijvoorbeeld dagrapporten of dag statistieken) dan tikt dat gruwelijk snel aan op je mail server...

Met een broadcast group-based systeem zoals Teams of Slack worden zulk soort bestanden maar 1x opgeslagen (back-ups ed. even buiten beschouwing gelaten) dus dat is ook vanuit een IT/BIS standpunt gewoon véél logischer.

[Reactie gewijzigd door Ayporos op 24 augustus 2019 10:48]

Het issue dat ik echter heb met e-mail versus Teams is dat, in het geval dat je bijvoorbeeld een bestand van 5 mb moet delen met 20 mensen, de server dat bericht + die bijlage 21x opslaat: 1x in ieder zijn inbox en 1x in jou sent items box.

Als je elke dag zulk soort e-mails stuurt (bijvoorbeeld dagrapporten of dag statistieken) dan tikt dat gruwelijk snel aan op je mail server...

Met een broadcast group-based systeem zoals Teams of Slack worden zulk soort bestanden maar 1x opgeslagen (back-ups ed. even buiten beschouwing gelaten) dus dat is ook vanuit een IT/BIS standpunt gewoon véél logischer.

Die bijlagen is inderdaad een issue... zelf probeer ik dat een beetje op te vangen door vooral veel te delen vanop Office 365 dat we op het werk gebruiken... ideaal is dat echter ook niet... zou liever hebben dat er voor werkgroepen centraal mappen aangemaakt worden i.p.v. dat ik er een aanmaak en deel met de teamleden... voelt niet volledig goed aan.
Maar blijkbaar is het bij ons net als op de meeste plaatsen: in theorie weten we hoe het moet, maar de praktijk hinkt wat achter

Bij 2 ontvangers in de To: was er nog steeds sprake geweest van een datalek.

Een waarschuwing is te negeren. We hebben het niet over IT specialisten die dit soort datalekken veroorzaken. Daarom is het ook belangrijk dat het onmogelijk word gemaakt dat dit soort dingen kunnen gebeuren

Dat bedoel ik...

Bij mijn vorige werkgever hebben we een keer zo'n mail gehad van Apple, we hadden daarmee een lijst e-mail adressen van alle bedrijven in Nederland die aan Apple leverden. Mijn broertje heeft het laatst ook gedaan, en zijn lijst (business) klanten 'gelekt', en hij is toch redelijk tech savvy.

Even waarschuwing is te negeren, maar het zorgt wel dat men niet meer kan zeggen "sorry, ongelukje" Ik zou liever zien dat emailadressen nimmer inzichtelijk zijn tenzij men zelf een hokje aanvinkt welke duidelijk aangeeft dat alle mailadressen voor alle ontvangende partijen inzichtelijk zijn wat mogelijk in strijd is met heersende wetgeving. Natuurlijk kan het dan nog steeds fout gaan, maar niet meer per ongeluk omdat het elke keer een bewuste keuze is.

Het valt inderdaad buiten 'normaal' gebruik, trouwens ook als je de adressen wel in de Bcc: zet. Helaas zijn er veel organisaties die zulke 'oplossingen' gebruiken gewoon omdat het kan, en dan krijg je als mailclientmaker klachten als je die mogelijkheid laat vervallen.

Waarom vertaal jij 'aanhef' met 'to'? Ik geloof dat ik de dader te pakken heb.

Email software zou dat niet eens moeten toelaten ....

Dit soort incidenten zijn (deels) te voorkomen met technische maatregelen aangevult met een goede awareness training, welke ook door tijdelijke inhuur- of vakantiekrachten moet worden gevolgd.

Nou, even een feature request openen dus, om zo'n waarschuwing toe te voegen.

Hier een feature request voor K9-mail en Thunderbird. Straks nog een paar andere e-mail-clients.
https://github.com/k9mail/k-9/issues/4172
https://bugzilla.mozilla.org/show_bug.cgi?id=1576661

[Reactie gewijzigd door Perihelion op 26 augustus 2019 18:11]

Maar dat soort systemen ondersteunen vaak ook meerdere ontvangers in de to of in de cc
Een e-mail client kan dit ook easy oplossen. Je verplaatst het probleem letterlijk van systeem naar systeem.
Zoals @m8ZBm1Si hieronder aangeeft; Een systeem moet dit blokkeren.
Ik kan in geen enkel geval bedenken waarom je > 50 mensen (niet eens meer dan 20) in de CC of TO wil hebben.

Oke, enige reden als je een mailing lijst hebt. Maar dan zou dat juist een feature moeten zijn imho. Niet default behavior

Dit zou je inderdaad idealiter met een mailinglijst willen hebben en daar zijn CRM systemen juist wel weer goed in. Je stelt een lijstje op van contactpersonen die er toe doen en hopla je verstuurd dezelfde mail naar alle contacten zonder dat ze door hebben dat die contacten dezelfde mail krijgen.

Maar inderdaad of je het nou in een CRM systeem of in een mail client afvangt.. het zou gewoon niet moeten kunnen. (en de persoon in kwestie zou zich af moeten vragen wat ie aan het doen is..)

Ik heb wel een paar mailinglists, maar daar genereer ik juist iedere mail apart zodat ik bounces kan herleiden, en onjuiste adressen kan vinden.

Ook een mallinglijst is geen reden, daar is gespecialiseerde CRM-software voor. In de gezondheidszorg heb je o.a. producten van Korèn die daar specifiek voor gecertificeerd zijn, maar er zijn vast ook algemene online CRM-pakketten.

Dat is omdat de mensen die het mailtje sturen dat niet weten. Ze zijn zich nauwelijks bewust van de risico's. Ook al is het op een veiligere manier te doen, die mensen moet letterlijk de mogelijkheid worden ontnomen om het fout te doen anders zal het gebeuren.

Ik vind niet dat dit zomaar ongestraft mag blijven; dit soort ernstige datalekken zijn een groot inbreuk op iemands leven. Het is al huilen met de pet op wbt privacy, kijk wat je moet doen om enigszins "normaal" gebruik te kunnen maken van internet (ik gebruik pihole + adblock + blokada en nog wat andere zaken), om vervolgens slachtoffer te worden van een medische dienstverlener die nog steeds anno 2019 bcc-tjes zit te verzenden. Zoals @Webgnome al aangeeft vreselijk uit de tijd en vragen om problemen. Ik zou zelfs de cc en bcc funktie bij zorginstellingen geheel blokkeren en dit enkel via een crm applicatie of ieder ander modern system mogelijk maken. Want wat is de volgende blunder, een vruchtbaarheidskliniek die even fijn een cc-tje naar al z'n clienten doet waar jij ook tussen staat? Sta je fijn voor l*l.

Ik vind niet dat dit zomaar ongestraft mag blijven;.

Wel ik denk dat de Autoriteit Persoonsgegevens dat met je eens zal zijn.

Maar wil je nu echt een administratieve medewerker aan het kruis nagelen? Of moet de IT manager een paar tienduizenden euro's ophoesten? Of moet de directeur alle verantwoordelijk persoonlijk nemen en die boete betalen? Of de staatssecretaris? Of de minister die de totale verantwoordelijkheid heeft? Moet die aftreden bij elk van dit soort fouten?

Fouten worden gemaakt. Zelfs als je de doodstraf zet op dit soort 'vouten' zal je zien dat deze fouten nog steeds gemaakt worden. Natuurlijk kan je door een beter systeem sommige fouten verhinderen maar dan is het wachten op de volgende fout. Ze zijn onvermijdelijk en zijn zo oud als de wereld. In een grijs verleden werkte ik als werkstudent bij een ministerie die een interne nota aan 22.000 uitkeringstrekkers stuurde. Per post. Op papier.

Het roepen om zware straffen is behoorlijk zinloos in dit soort zaken. Dat jij pihole en veel andere zaken draait waardoor je een groot deel van de sites die je gebruikt hun inkomen ontzegt (je bent toch wel Tweakers betaler he? Anders heb je wel echt veel boter op het hoofd) maakt werkelijk niets uit.

Even voor de goede orde:

De Autoriteit Persoonsgegevens zal geen boete opleggen op het moment dat er een foutje wordt gemaakt, of de gevolgen zouden wel heel ernstig moeten zijn, maar dit is niet zozeer de taak van de AP en hiermee zou ook het omgekeerde worden bereikt van wat men wil bereiken, namelijk dat bedrijven uit angst voor een boete hun mond houden.

Boetes kunnen wel opgelegd worden als men bewust het lek niet meldt en de fout in de doofpot wordt gestopt. Die boetes zijn dus juist bedoeld als stok achter de deur om het lek wel te melden.

Wie heeft er hier boter op zijn hoofd?? Met je muis boven een icoontje zweven is een te complexe taak voor je? Daarnaast is het argument dat adblockers sites hun inkomen ontzegt al vaak en veel weerlegt, door bijvoorbeeld het veelvuldig geïnfecteerd geraken van advertentienetwerken en de misselijkmakende (onnodige) tracking. En ten derde weet je helemaal niet welke sites ik gebruik of bezoek, dus die ongefundeerde aannames mag je ook achterwege laten.

Ontopic: "fouten worden gemaakt", wil je nou echt onder die noemer de grove schending van de privacy en de nalatigheid om een goede it infrastructuur neer te zetten dit maar relativeren?? We praten in dit geval over een grote zorginstelling, die MOETEN hun zaken op orde hebben, daar zijn de budgetten ook naar. Is dat niet het geval, dan mogen er inderdaad een paar verantwoordelijke bestuurders onbetaald naar huis, totdat de boel wel op orde is.

Leuk bedacht maar totaal niet realistisch. De bestuurder(s) naar huis toe sturen zal niks toevoegen, integendeel.

Wat hiervoor al is gezegd, het is puur amateurisme. Vele bedrijven weten 0,0 van IT. Deze kennis, hoe hard ook nodig, is er niet en zal zeker nog een aantal jaar niet aanwezig zijn. Het tekort aan vakkundige TI mensen groeit namelijk nog steeds.

Wat ik wel jammer vind is dat een behoorlijke sentimentele post die meer berust op emotie dan denk werk zo makkelijk op tweakers wordt geplust

Het feit dat een straf niet voorkomt dat er fouten gemaakt worden vind jij een reden om dan niet te straffen? Dan mogen ze alle flitspalen in Nederland ook wel weghalen.

Als er eenmaal een paar flinke boetes uitgedeeld worden zullen bedrijven echt wel iets beter gaan nadenken of het verstandig is dat Truus naar honderden mensen kan mailen.

Ze zouden inderdaad alle flitspalen moeten weghalen, en wat meer politie rond laten rijden maar dat terzijde.

Het uitdelen van boetes voor AVG-overtredingen kan makkelijk zijn doel voorbijschieten, dus dat zou ik alleen in heel ernstige gevallen of bij recidive doen. Het is in niemands belang als het uit het budget van een zorginstelling moet komen. Wat beter werkt is een register van datalekken zodat klanten kunnen inschatten hoe veilig hun data is. Ook organisaties zullen daar liever niet massaal in willen staan.

[Reactie gewijzigd door mae-t.net op 23 augustus 2019 20:28]

Het uitdelen van boetes voor AVG-overtredingen kan makkelijk zijn doel voorbijschieten, dus dat zou ik alleen in heel ernstige gevallen of bij recidive doen. Het is in niemands belang als het uit het budget van een zorginstelling moet komen. Wat beter werkt is een register van datalekken zodat klanten kunnen inschatten hoe veilig hun data is. Ook organisaties zullen daar liever niet massaal in willen staan.

Dat die het doel voorbijschiet is in alle gevallen.
Een bedrijf heeft een datalek, om wat voor reden dan ook ( intern / extern ) kan een boete krijgen tot 2% van hun jaaromzet, of zelfs tot 4% van hun jaaromzet.
( dat is bij een multinational aanzienlijk, omdat dat over hun hele omzet gaat - zoals bv. Heineken, of Uber, die 600K kregen )
( bron : https://autoriteitpersoon...st-boetebeleidsregels-aan - maximale boetes )

Maar de boetegelden gaan naar de rekening van de AP ( overheid ), en niet naar de gedupeerden.
Ik zou liever zien dat het dan 'eerlijk' verdeeld wordt, tussen een boete naar de AP en een ( normaal ) bedrag aan de slachtoffers als schadevergoeding

2 tot 4 procent hoeft zijn doel niet voorbij te schieten (er zijn amorele bedrijven met grote winsten die het toch zullen moeten voelen), maar zal inderdaad niet altijd proportioneel zijn. Ik ben het volledig met je eens dat de slachtoffers er ook wel wat van terug mogen zien.

De functie van de boete is met de tijd wat verdwenen lijkt het. Incidentele individue menselijke fouten zullen gemaakt blijven worden als de mogelijkheid geboden wordt.
Nu biedt veel IT inrichting van bedrijven de mogelijkheid om dit soort fouten heel makkelijk te maken. Een geldboete veranderd daar niks (of zeer beperkt wat) aan.
De straf moet in dit geval een praktische oplossing behelzen. Bijvoorbeeld het investeren in een protocol en systeem wat dit onmogelijk maakt. Ik denk aan:
- De onmogelijkheid voor medewerkers om meer dan X aantal mensen tegelijk te mailen buiten de organisatie
- de afdeling communicatie laten beschikken over een beveiligd systeem met (externe) mailinglists.
- protocollen opstellen waarin staat dat massacommunicaite, zeker extern,alleen via de afdeling communicatie of patiënt administratie mag verlopen.
- deze implementatie moet binnen afzienbare tijd zijn ingevoerd en er word op toegezien door controlerende instanties dat dit is gebeurd.

Inderdaad. Dit gebeurt veel te vaak.
Wordt er weer een boete geheven (en hopelijk betaald), maar de klanten/degenen in het 'to'-veld zijn en blijven de Sjaak. Hier hoor je vervolgens niets meer over na verloop van tijd.

Afkaderen en opvoeden van personeel is niet genoeg. Waarom wordt er geen gebruik gemaakt van professionele mail-oplossingen, zoals bijv. MailChimp, Copernica, SendGrid etc etc , of een 'eigen' oplossing (volledig getoetst en gecertificeerd) binnen overheden, gemeenten en/of bedrijfsleven voor "bulk-mail" naar relaties.
Of alles goed dichtspijkeren via (standaard) mailprotocol-oplossingen op client- of serverniveau.

Schandalig gewoon dat dit nog steeds kan en gebeurt in 2019!! (en ik denk ook nog wel ergens in 2034 helaas).....

Uhhhhh je weet dat veel van die mail-oplossingen die je opnoemt dit niet kunnen onderscheppen? en dat ze allemaal het tegendeel willen doen?

• MailChimp bijvoorbeeld noemt zichzelf een all in one marketing platform. Niet echt een mail systeem gericht op privacy!
• Copernica noemt zichzelf: software for email marketing automation with advanced multidimensional databases, campaigns management and personalized emails.
• Sendgrid: Delivering your transactional and marketing emails through the world's largest cloud-based email delivery platform

Niet echt platformen om privacy gevoelige emails te verzenden lijkt mij.

Standaard mail protocol oplossingen bestaan ook niet, het protocol heeft geen mechanisme om dit te stoppen. Denk dat je niet veel van institutionele email oplossing weet. Wellicht is het dan beter om niet te reageren met platitudes.

[Reactie gewijzigd door Anoniem: 310408 op 23 augustus 2019 19:45]

Naja... niet onderscheppen, maar wel een standaard e-mailtje aan meerdere gebruikers standaard in een “bcc” zetten.
Natuurlijk is ook hier privacy niet gewaarborgd - immers, als verzender kun je alles volgen waar op geklikt wordt en ook zij hebben voorwaarden. Of dit helemaal AVG compliant is, weet ik niet....

Het gaat mij meer om dat er partijen zij waar dit een core business is, en dit - waarschijnlijk - meer op orde, en afgedekt, is dan bij een Jantje Pietersen van Gemeente X of psychiatrische instelling Y die mailtjes gaat versturen.

• MailChimp bijvoorbeeld noemt zichzelf een all in one marketing platform. Niet echt een mail systeem gericht op privacy!
• Copernica noemt zichzelf: software for email marketing automation with advanced multidimensional databases, campaigns management and personalized emails.
• Sendgrid: Delivering your transactional and marketing emails through the world's largest cloud-based email delivery platform

Niet echt platformen om privacy gevoelige emails te verzenden lijkt mij.

Dan doet Groupmail het beter?
https://group-mail.com/em...gdpr-email-marketing-faq/

[Reactie gewijzigd door BlueInk op 24 augustus 2019 11:00]

Je zou eens moeten weten welke nieuwe it oplossingen anno 2019, geïmplementeerd worden. Een bedrijf als parnassia( een zorg instelling, kan zich bijna niets meer veroorloven qua betere it oplossing, dankzij onze verzekeringsmaatschapijen, dus er wordt veel met de hand gedaan

In gevallen als dit moet je aan een CRM denken, liefst een die dichtgetimmerd is voor gevoelig gebruik. Mailinglistachtige oplossingen zijn hier ook niet voor bedoeld.

Hier zou natuurlijk een protocol voor moeten zijn, en nog beter, goede software. Dit verzin je toch niet?
Keihard bestraffen met een flinke boete.

Keihard bestraffen met een flinke boete.

Te betalen door de administratief medewerker die de fout heeft gemaakt?
Te betalen door de IT medewerker die emails onder zijn beheer heeft?
Te betalen door manager van de IT afdeling die het beter had kunnen regelen?
Te betalen door de instelling?
Te betalen door de organisatie waar de instelling onder viel?
De directeur?
De staatssecretaris?
De minister? Die is uiteindelijk persoonlijk (zo werkt onze politiek) verantwoordelijk voor alle ambtenaren).
Of wellicht de leverancier van de IT?

Zeg het maar... Wie wil jij keihard aanpakken? En waarom denk je dat het dan beter zal worden?

[Reactie gewijzigd door Anoniem: 310408 op 23 augustus 2019 19:36]

Directie (je weet wel, die lui die ook veel verdienen) want dat zijn de directe hoofdverantwoordelijken.

Zodat hun zorg nog duurder wordt voor mensen die het al bijna niet kunnen betalen; dat is helaas de keerzijde

Die goede software hebben ze al. Ik heb net geconcludeerd dat ze onder de GGZ vallen. Toen ik nog in de software licenties zat was er een Microsoft mantelovereenkomst voor zorg waaronder GGZ. Daardoor konden ze onder een hogere dan normale staffel Microsoft aanschaffen. Dus neem ik aan dat ze beschikken over Office. Met Word en Excel is een mail merge zo gedaan.

Misschien hebben ze wel een mail merge programma gebruikt. Vooral met dat soort tools heb je eigenlijk nog minder zicht op wat er gebeurt omdat het echte werk achter de schermen gebeurt. Zelf adressen pasten in een To veld valt denk ik veel sneller op dat een configuratie instelling ergens in het mail merge programma waar een drop-down per ongeluk nog op "To" staat in plaats van "Bcc"...

Er is geen sprake van een "mail merge programma". Het gaat er om dat er in Word (of een andere tekstverwerker) een standaard e-mail wordt opgesteld met verwijzingen naar cellen of kolommen in een spreadsheet. Bij de mail merge (of samenvoegen in het Nederlands) wordt het document iedere keer opnieuw verstuurd via de e-mail client waarbij iedere keer een andere cel als input wordt gebruikt.

Dus in de kolom e-mailadressen wordt de celinhoud in het To-veld elke keer opnieuw geplakt per nieuwe e-mail met de tekst uit het Word-document.

Wat je zegt over meer opvallen met een gewone e-mail client en een hoop adressen kopiëren naar het To-veld daar ben ik het niet mee eens: nieuws: Gemeente Etten-Leur lekt 2000 e-mailadressen van inwoners.

Nu weet ik uit persoonlijke ervaring wat van Parnassia, waar dit soort dingen helaas het gevolg zijn van tekorten in de zorg. Er is te weinig geld voor goede ict (naast te weinig geld voor personeel en patientenzorg).
Dus ik begrijp goed dat het sentiment is dat het beboet moet worden, maar het beste is kijken naar waarom deze fout had kunnen komen. ICT is ontzettend duur en in een deel van de zorg waar er al te weinig geld is om elke patient de zorg te bieden die hij of zij nodig heeft, kan ik me voorstellen waar de prioriteiten liggen.

Deels klinkt dit als een domme fout (met mails en cc/bcc), en dat hoort natuurlijk niet. Maar laten we vooral kijken naar het systeem, en niet naar de individu.

Deels klinkt dit als een domme fout (met mails en cc/bcc), en dat hoort natuurlijk niet. Maar laten we vooral kijken naar het systeem, en niet naar de individu.

Dit datalek bewijst juist dat meer kritisch gekeken mag worden naar de ICT-skills van het personeelsbestand in de zorg.

Ik denk dat je daar veel te onrealistisch in staat. Een van onze klanten in de zorgsector heeft binnen een 3 maanden twéé keer een forse credential leak gehad door succesvolle phishing. Na die eerste keer is een vrij grootschalige interne campagne opgezet om awareness te creëren binnen het bedrijf voor dit soort ellende en vervolgens gebeurt het nog geen 3 maanden later gewoon opnieuw. Mét nota bene een aantal gebruikers die er de eerste keer ook al ingetrapt waren!

Ik denk dat je dit soort dingen alleen kunt voorkomen door omgevingen helemaal dicht te spijkeren en alleen capabele mensen achter die computer te laten. Helaas is dat geen optie en moeten ook Annie en Truus patiëntengegevens bijwerken. Dit moet je technisch afvangen en niet op de opvoeding van eindgebruikers aan laten komen

Helaas is dat geen optie en moeten ook Annie en Truus patiëntengegevens bijwerken. Dit moet je technisch afvangen en niet op de opvoeding van eindgebruikers aan laten komen

Dan ben ik wel benieuwd hoe Annie en Truus hun belastingaangifte invullen, verzekering afsluiten, bankieren, e.d. Papier en kantoor verdwijnt, de computer met internet blijft over. Daarnaast is het verschil tussen het "Aan" en "BCC" veld echt basiskennis om een email-client te gebruiken..

En hoe wil je dit technisch afvangen dan?

In een willekeurige chatprogramma kun je ook heel ongelukkig per ongeluk een lijst e-mailadressen opsturen met Ctrl+V & Enter omdat je dacht dat je hard genoeg op Ctrl+C had gedrukt.

Inderdaad. Ik werk zelf in een zorginstelling. Je wilt niet weten hoe ver de ICT skills van medewerkers uit elkaar kunnen liggen. De IT afdeling verstuurt hier af en toe fake phishing mails en bekijkt dan wie erin trapt, vervolgens krijgen ze een gesprek om uit te leggen waarom ze dat niet moeten doen.

450 e-mail adressen in 1 mail kunnen proppen. Dan heeft hun beheerder ook zitten slapen tijdens het configureren van de outbount spamfiler

Ding had nooit de organisatie mogen verlaten op deze manier en gewoon door IT afgevangen moeten worden.

[Reactie gewijzigd door HKLM_ op 23 augustus 2019 17:44]

Wat ik in zo'n geval doe is even op "reply to all" klikken met hierin een vriendelijk verzoek gericht aan de afzender om even een melding bij de AP te doen (is hij sowieso verplicht). Het levert vervolgens wel even wat mailverkeer op, maar de 'schuldige' let de volgende keer wel drie keer op voordat hij op verzenden klikt

Tjee , hoe vaak overkomt je dat?

Ik krijg rond de 100 emails per dag maar kan en daar is soms ook wel eens een email bij die ik niet had moeten krijgen. Maar ik kan me niet heugen dat ik een mail kreeg waar de AP interesse in zou kunnen hebben, Wat jij krijgt moet veel interessanter zijn dan wat ik krijg.

Geef eens wat voorbeelden? Alle meldingen bij de ATP zijn publiek dus het is leuk om te kijken of er inderdaad actie is ondernomen zoals jij zegt!

Het artikel gaat volgens mij niet over spam, dat kun je redelijk filteren en daar heeft de AP inderdaad weinig mee te maken, maar het gaat hier om het lekken van persoonlijke gegevens van patiënten. Volgens de nieuwe AVG is dit bedrijf (of eigenlijk nog gevoeliger, het gaat hier om een zorginstelling), verplicht dit te melden. Doen ze dit niet, dan kunnen ze een boete krijgen en die kan flink oplopen.

Nu weet ik, dat dit in de praktijk wel meevalt, maar er zijn ook gevallen bekend waarin deze boetes wel degelijk zijn opgelegd.

Meldplicht datalekken.

Het gaat er niet niet over wat interessant is of niet, maar over het gegeven dat 'gegevens' intern gehouden moeten worden.
Als jij als klant van zo'n organisatie ineens 349 andere mailadressen toegestuurd krijgt, gaat het niet over het onderwerp, maar data die niet verspreid mag worden

Wat is intern? Ik mag bij mijn huidige opdrachtgever niet eens op een bepaalde verdieping voorbij deuren want ik ben geen "insider". Een bepaalde tijd voor de publicatie van de cijfers van de NV gaat de communicatie op slot. Dus ook al blijft de informatie binnen het bedrijf, wil nog niet zeggen dat die eyes het moeten of mogen zien.

Wil je nu echt per punt/komma een geheimhoudings-gradatie krijgen dan ?
De reactie gaat hier over mailadressen die naar andere klanten/partners gestuurd werden.
Een klantenbestand, of deel daarvan lijkt mij alleen voor intern gebruik.
Ga je dus dat lijstje naar 450 anderen sturen, is dat geen intern gebruik meer.

Ik heb als ook medewerker geen inzage in sommige zaken, zo werkt dat nu eenmaal in bedrijven

Wow, jij hebt mijn reactie niet goed begrepen. Ik reageer op jou met je stelling:

maar over het gegeven dat 'gegevens' intern gehouden moeten worden.

Ik geef aan dat intern niet betekent dat die gegevens daarom intern verspreid mogen worden.

Ah op die tour ...
Nee dan had ik het verkeerd begrepen inderdaad

450 e-mail adressen in 1 mail kunnen proppen. Dan heeft hun beheerder ook zitten slapen tijdens het configureren van de outbount spamfiler

Ding had nooit de organisatie mogen verlaten op deze manier en gewoon door IT afgevangen moeten worden.

Wat een onzin! IT is er ter ondersteuning van een organisatie, als een organisatie er op staat dat dergelijke emails verzonden moeten kunnen worden vanuit het primaire domein dan ga je dat niet afvangen in een filter. En er zijn zat MKB organisaties die dat zo doen, want een CRM systeem die dat netjes voor je doet is niet goedkoop, zeker niet in onderhoud. Ja, er zijn veel betere systemen/procedures te bedenken, maar als die (nog) niet aanwezig zijn in een organisatie dan kan je re weinig aan doen.

Hell, veel bedrijfstak specifieke CRM systemen, zoals bv. voor de kinderopvang, zijn geschreven voor de millennium wisseling en werken nog steeds op diezelfde 'core', je moet dan... Niet standaard oplossingen bedenken om met moderne infra te kunnen werken en te voldoen aan moderne regelgeving.

Dat iets dergelijks binnen jou organisatie anders werkt betekend verre van dat dit zo gaat bij elke andere organisatie. En het gaat echt niets helpen, want als je iets dergelijks instelt op bv. max 50 recipients dan gaan ze mails versturen die daar net onder zitten qua aantallen. En als je dit heb afgeschermd kan iemand nog steeds een exportje maken van de email adressen en deze per ongeluk naar de verkeerde 'Dennis' sturen. Waar mensen werken worden fouten gemaakt dat hoeft zeer zeker niet altijd met laksheid te maken te hebben...

@mae-t.net AVG compliant: men kan echt prima AVG compliant zijn en door menselijke fouten nog steeds persoonsgegevens lekken. Daarnaast is er geheel geen certificering of iets dergelijks, daarom is er geen enkel bedrijf welke 'AVG compliant' zijn waar het op dezelfde manier is opgepakt.

Emails versturen via BCC is niet tegen de AVG regels is, dus dat zou geen issue moeten wezen. De AVG vereist ook niet dat je je processen human-fool-proof moet maken (they keep making better fools!).

En AVG compliance adoptie is bijzonder slecht te noemen, dat was het een jaar geleden al en begin dit jaar was het slechts ietsiepietsie beter. Als veel afdelingen van de staat het al niet op orde hebben (do as I say, not as I do!) en er genoeg gemeentes zijn die er nog steeds een potje van maken, wat verwacht je van een for-profit organisatie als Parnassia Haaglanden B.V.? Natuurlijk zou het anders moeten gaan, maar in de praktijk ga je dit soort kinderziektes blijven houden tenzij de controlerende partij heel strak gaat optreden. Dat doen ze echter niet en ik vraag me zeer af of dat een hele slechte situatie is, dergelijke impactvolle wijzigingen kosten een hoop tijd/geld en niet elk bedrijf kan die omslag 1-2-3 maken. Als dat inderdaad te snel gaat zitten er straks teveel mensen zonder werk omdat de economie de regel aanpassingen (en controle/boetes daarop) niet aankan.

Ik zou graag overal met een honkbalknuppel (met wel of niet roestige spijkers er in) rondlopen zodat iedereen zich netjes aan de regels/afspraken houd. Maar de ervaring met bedrijven/management/personeel is jammer genoeg anders.

[Reactie gewijzigd door Cergorach op 23 augustus 2019 20:48]

Wat een onzin! is hier wel een beetje sterk uitgedrukt. Immers heeft de IT vanuit zijn ondersteunende functie ook een adviserende rol. In extreme gevallen zou de IT-afdeling bindend advies moeten geven, maar dat hangt inderdaad wel van het management af, dus daar hebben ze mogelijk wel een excuus.

Mogelijk, want het blijft natuurlijk allemaal speculeren over de situaties.

Verder gaat de vergelijking met 'nogal wat MKB organisaties' volstrekt niet op! Het gaat hier om een organisatie die volledig AVG compliant moet zijn omdat er ook bijzondere persoonsgegevens verwerkt worden. Dat houdt in dat ook de processen waar alleen normale persoonsgegevens (zoals mailadressen) verwerkt worden, goed tegen het licht gehouden zijn.

Dat betekent dus dat er wel degelijk iemand heeft zitten slapen. Mogelijk niet de hele IT-afdeling maar toch wel de functionaris gegevensbescherming!

Met AVG compliant bedoel ik dat procedures zijn vastgelegd en vooral welke data waar wordt opgeslagen en gebruikt. De functionaris gegevensbescherming zal dan toch wel ergens een mailprogramma hebben zien langskomen. In principe niet strijdig met de AVG, maar bij iemand die niet zit te slapen moeten de haren overeind gaan staan.

450 e-mail adressen in 1 mail kunnen proppen. Dan heeft hun beheerder ook zitten slapen tijdens het configureren van de outbount spamfiler

Ding had nooit de organisatie mogen verlaten op deze manier en gewoon door IT afgevangen moeten worden.

Ik vind het leuk dat je dit zo event terloops roept maar waar zou zo'n limiet op moeten zitten? Ik heb zelf al in legitieme mailwisselingen gezeten waar gewoon 30 ontvangers in zaten.
En als dit soort shit gebeurd met 20 mensen is het evengoed een datalek.

Het feitelijk probleem is hier dat er gewoon mail op een foute manier verstuurd wordt. Hun mail client wordt gebruikt op een manier waarop deze niet gebruikt moet worden. Uberhaupt niet, ook niet in de BCC.
Dat je dat KAN afvangen met een arbitrair limiet op je mailserver betekend niet dat je dat ook moet gaan doen. Je lost namelijk dat onzorgvoldige gebruik van data er niet mee op en daar zit hem nou net wel de crux.

Je kan niet met een dwijl achter mensen aan blijven lopen want dat is een gevecht wat je niet kan winnen. Dat is wel wat je doet als je een adressantenlimiet van 100 op je mailserver zet en het daarmee opgelost vind.

Wat je ICT wel zou kunnen aanrekenen is dat ze dit type gebruik moeten zien en wat over moeten roepen. Maar dan moet er wel ICT zitten in een hoedanigheid dat deze daar wat mee kan.
Schijnt nogal dramatisch gesteld zijn met de ICT budgetten in zorgland, ondanks dat daar absurde sommen geld rond gaan.

[Reactie gewijzigd door Koffiebarbaar op 24 augustus 2019 12:20]

Ook zegt een woordvoerder dat het excuses heeft gemaakt aan betrokken.

Daar zullen de betrokkenen veel aan hebben.

Het kwaad is al geschied en niet meer terug te draaien.

[Reactie gewijzigd door RoestVrijStaal op 23 augustus 2019 18:59]

Wat moeten ze volgens jou dan doen?

Het is jammer dat t gebeurd is en had beter geregeld kunnen worden zodat de kans dat het kon gebeuren kleiner was, maar waar mensen werken zullen altijd fouten gemaakt worden.

Excuses aanbieden is dan wel het minste wat je kan doen, en soms ook het enige als het niet terug te draaien is en niet tot een duidelijk met geld te compenseren nadeel heeft geleid.

Iets soortgelijks overkwam een bekende van mij, alle e-mailadressen van de leden van de vereniging werden meegestuurd met het rooster. Het is gewoon amateurisme.

Ik weet uit eigen ervaring dat er bij de Parnassia Groep meerdere systemen(met elk hun eigen doel) in gebruik zijn t.b.v. veilige email communicatie.

Ook vind er voorlichting plaats t.b.v. veilig e-mailen en vaak werd IT geraadpleegd voor dit soort vraagstukken.

Wat er hier voorgevallen is ontzettend jammer en ik ga er vanuit dat ze hier leer uit trekken.

Ik krijg van het nieuws maar vooral van de reacties nogal een deja-vu gevoel..
https://tweakers.net/nieu...dressen-van-inwoners.html