PVV Overijssel krijgt 7500 euro boete voor niet melden van datalek
De Autoriteit Persoonsgegevens heeft de Partij voor de Vrijheid (PVV) Overijssel een boete van 7500 euro opgelegd voor het niet melden van een datalek. Het datalek ontstond door een fout van een fractiemedewerker die een e-mail over een achterbanbijeenkomst verstuurde maar niet de BCC-optie gebruikt. De e-mailadressen van de in totaal 101 geadresseerden, die in de e-mail werden aangeduid als 'vrienden van de PVV, waren daardoor voor alle ontvangers van het bericht zichtbaar.
"Hierdoor zijn de politieke opvattingen van de geadresseerden gedeeld", aldus de Autoriteit Persoonsgegevens. Pas nadat één van de ontvangers een klacht bij de privacytoezichthouder indiende kwam het datalek aan het licht. Vervolgens bleek uit onderzoek dat de PVV Overijssel dit datalek niet adequaat had opgepakt door tijdig een melding te doen bij de AP. "Dat is een ernstige overtreding, zeker gezien de gevoeligheid van de gelekte informatie", zo stelt de toezichthouder.
Iemands politieke opvattingen zijn zogenoemde bijzondere persoonsgegevens en worden in de Algemene verordening gegevensbescherming (AVG) extra beschermd. Het schenden van de vertrouwelijkheid van deze informatie kan leiden tot discriminatie en gevolgen hebben voor iemands bestaande of toekomstige maatschappelijke positie, aldus de Autoriteit Persoonsgegevens.
Volgens de toezichthouder verwerken politieke organisaties per definitie gevoelige informatie en hebben daarom een grote verantwoordelijkheid om een hoog beschermingsniveau te hanteren. Ook moet er in het geval van een datalek adequaat worden opgetreden. De PVV Overijssel had het datalek binnen 72 uur bij de AP moeten melden maar heeft dat niet gedaan. Wel laat de partij weten dat het maatregelen heeft getroffen om herhaling in de toekomst te voorkomen.
Voor de betreffende overtreding kan de Autoriteit Persoonsgegevens een boete van tussen de 300.000 en 750.000 euro opleggen, en betreft de basisboete 525.000 euro. De AP stelt dat de draagkracht van de PVV Overijssel beperkt is en komt tot de conclusie dat de partij een boete van 525.000 euro niet kan betalen. Op grond daarvan ziet de AP aanleiding om het boetebedrag te verlagen naar 7500 euro.
Ik begrijp namelijk niet dat er nog e-mail clients bestaan die je niet waarschuwen als je meer dan bijv. 5 geadresseerden in het "Aan:" en/of "Cc:" veld plaatst.
Zelfs als dat geen privacy-issue is, is dat meestal ongewenst omdat veel te veel mensen niet snappen dat "reply all" een berg irritatie en een lamgelegde mailserver kan opleveren.
Als het belangrijk is dat ontvangers weten naar wie een e-mail nog meer verzonden is, kun je ook een lijstje namen in de mail zelf opnemen. En als het noodzakelijk is dat mensen kunnen antwoorden, ook hun e-mail adressen; je voorkomt daarmee in elk geval onbedoelde "reply all" mails.
Ik begrijp namelijk niet dat er nog e-mail clients bestaan die je niet waarschuwen als je meer dan bijv. 5 geadresseerden in het "Aan:" en/of "Cc:" veld plaatst.
...
Ja en nee.
Kan me goed voorstellen dat de verzender van het bericht op dagelijkse basis medewerkers en andere doelgroepen mailt met updates, documentatie en informatie van allerlei origine. Vaak is het intern handig om dan de medewerkers juist WEL in het "Aan:" en/of "CC:" veld, al is het maar om te laten zien aan elkaar dat de collega zeker ook die informatie is toegestuurd.
Anders krijg je constant mails die geforward worden, om zeker te zijn dat je collega dat ene document heeft gelezen voor bijvoorbeeld een vergadering.
Dus de medewerker die dit soort berichten uitstuurt moet bij elke mail heel goed nadenken of hier geen datalek wordt gecreëerd. Een misstap (of kleine foutje) is dan snel gemaakt.
En dan hebben we het nog geeneens over medewerkers die extern zijn aangetrokken (bijvoorbeeld consultants) die alle mail ontvangen op hun eigen mailserver. Zijn zij nu interne medewerkers of extern?
Kan me goed voorstellen dat de verzender van het bericht op dagelijkse basis medewerkers en andere doelgroepen mailt met updates, documentatie en informatie van allerlei origine. Vaak is het intern handig om dan de medewerkers juist WEL in het "Aan:" en/of "CC:" veld, al is het maar om te laten zien aan elkaar dat de collega zeker ook die informatie is toegestuurd.
Anders krijg je constant mails die geforward worden, om zeker te zijn dat je collega dat ene document heeft gelezen voor bijvoorbeeld een vergadering.
Dat kan bijvoorbeeld ingevuld worden door meerdere individuele bestemmingsadressen altijd als Bcc af te handelen. Binnen een organisatie kan je voor afdelingen, projectteams en dergelijke groepsadressen definiëren die, als er geen andere adressen worden gebruikt, wel in To of Cc mogen verschijnen. Dan is voor de ontvangers binnen de organisatie duidelijk wie de ontvangers zijn. Op het niveau van een e-mailclient kan iets dergelijks geregeld worden door alleen meerdere adressen in To/Cc te accepteren als die via een groep in het adresboek worden ingevuld en als bij die groep is ingesteld dat die in To/Cc mogen verschijnen, een instelling met Bcc als default die omgeven is met waarschuwingen over de risico's van het afwijken van de default.
Er zijn vast ook wel andere manieren te bedenken om dit voor elkaar te krijgen, maar de basis moet wel zijn dat bij gedachtenloze handelingen geen ongelukken gebeuren en dat je iets moet doen dat omslachtig genoeg is om er even bewust bij na te moeten denken om een datalek te veroorzaken.
Net als Erik vind ik het opmerkelijk hoe weinig er is geregeld om dit soort ongelukken te voorkomen in e-mailsoftware. Ik vermoed dat de ontwikkelaars ervan, en trouwens ook de ontwikkelaars van veel andere software, hevig in de modus zitten dat alle functies zo laagdrempelig mogelijk moeten worden gemaakt, vanuit het idee dat dat het meest gebruiksvriendelijk is. Gebruiksvriendelijk is naar mijn mening niet hetzelfde als zo laagdrempelig en makkelijk mogelijk. Dat geldt voor functies en mogelijkheden in de software die geen kwaad kunnen, maar juist voor dingen waar makkelijk ongelukken mee kunnen gebeuren is het gebruiksvriendelijker om ze niet al te laagdrempelig te maken.
Ja en nee.
Kan me goed voorstellen dat de verzender van het bericht op dagelijkse basis medewerkers en andere doelgroepen mailt met updates, documentatie en informatie van allerlei origine. Vaak is het intern handig om dan de medewerkers juist WEL in het "Aan:" en/of "CC:" veld, al is het maar om te laten zien aan elkaar dat de collega zeker ook die informatie is toegestuurd.
Anders krijg je constant mails die geforward worden, om zeker te zijn dat je collega dat ene document heeft gelezen voor bijvoorbeeld een vergadering.
In de waarschuwingsbox zou, naast "verplaats naar Bcc" ook de volgende opties kunnen zitten (een soort "wizard"):
1) Voeg namen van geadresseerden toe aan de body van de e-mail
2) Voeg namen en e-mail-adressen van geadresseerden toe aan de body van de e-mail
Natuurlijk voorzien van een toelichting m.b.t. de privacy-risico's.
Het probleem bestaat overigens niet alleen vanwege "gedachtenloze" mensen, maar ook omdat mensen zelden worden opgeleid m.b.t. hoe te e-mailen en over de bijbehorende privacy-risico's. In onnodig veel gevallen moeten mensen "door schade en scande wijs worden". Veel mensen weten niet eens waar een Bcc veld voor dient, laat staan dat zij weten dat elke ontvanger niet ziet naar wie zo'n mail nog meer gestuurd is.
Daarbij, als je al weet dat Bcc een afkorting is van "Blind carbon copy", dan zegt dat nog niks (ik wist dat ook niet en zag zojuist in https://en.wikipedia.org/wiki/Blind_carbon_copy waar dit vandaan komt).
Men vergeet echter dat het hier om een kleine club gaat, te weten de PVV Overijssel. Lijkt me niet dat deze veel ervaring hebben met mass-mailings en gebruik (kunnen) maken van een volwassen ICT-ondersteuning.
De ene oplossing verwijt het aan het software programma, de ander aan het probleem zit tussen stoel en keyboard.
Het blijft mensenwerk.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?