Algemene verordening gegevensbescherming - GDPR / AVG

[DiedX]

Je had m aan kunnen zien komen

Kan je niet creatief blurren? En foto's van de keynote-spreker met subtiel de rug van iemand die er maar luistert zal geen probleem zijn denk ik

[pr0mo]

Verwijderd schreef op woensdag 28 maart 2018 @ 11:50:
Ik heb ook een praktische vraag: wij organiseren jaarlijks een groot ledenevenement waar 1000+ mensen komen. In het aanmeldingsformulier hebben we dit jaar netjes conform AVG-vereiste een toestemmingsvraag opgenomen over bezwaar wel/niet tegen maken van foto- en filmmateriaal waar ze mogelijk herkenbaar in beeld komen. Deze sfeerimpressies worden gebruikt op de website (staat er bij). Nu hebben best veel mensen aangegeven dat ze bezwaar hebben, en zitten wij met praktisch probleem hoe met die mensen om te gaan die we niet allemaal van gezicht kennen. Achteraf eruit filteren is dus niet mogelijk. Iemand praktische suggesties?

Een foto opzichzelfstaand is geen persoonsgegeven. Het doel van de foto is het geven van een sfeerimpressie. dus deze foto mag je gewoon maken. Als mensen het hier niet mee eens zijn beroepen ze zich op het portretrecht en niet op de privacywetgeving.
Het is een ander verhaal wanneer je een analyse gaat uitvoeren op de foto om bijv te kijken hoeveel mannen en vrouwen er zijn geweest. Dan is het wel een persoonsgegeven en dien je toestemming van alle aanwezige te vragen die je op de foto zet (schriftelijk want aantoonbaar).

[Yucon]

Zorg dat je op de spreker inzoomt op een zodanige manier dat het publiek vaag wordt.

[Frogmen]

pr0mo schreef op woensdag 28 maart 2018 @ 12:20:
[...]


Een foto opzichzelfstaand is geen persoonsgegeven. Het doel van de foto is het geven van een sfeerimpressie. dus deze foto mag je gewoon maken. Als mensen het hier niet mee eens zijn beroepen ze zich op het portretrecht en niet op de privacywetgeving.
Het is een ander verhaal wanneer je een analyse gaat uitvoeren op de foto om bijv te kijken hoeveel mannen en vrouwen er zijn geweest. Dan is het wel een persoonsgegeven en dien je toestemming van alle aanwezige te vragen die je op de foto zet (schriftelijk want aantoonbaar).

Nou hier wringt het juist, foto's is echt een drama. Leuk bedacht maar in de uitvoering komt het er al gauw op neer dat je geen foto's met mensen meer mag plaatsen. Het vervelende is dat je het als vrije keuze moet plaatsen. Echt er wordt een probleem gemaakt van iets wat nooit een probleem is geweest. Reden is vooral dat er een theoretische mogelijkheid is om mensen in foto's te zoeken. Maar wat met historische foto's enzo, als scouting hebben we een archief van meer dan 10.000 foto's.

[F_J_K]

pr0mo schreef op woensdag 28 maart 2018 @ 12:20:
Een foto opzichzelfstaand is geen persoonsgegeven.

Heb je een bron? Onder de Wbp (cq jurisprudentie daarbij) was dat wel zo. Ook de (nog van de Wbp uitgaande) FAQ van de AP benoemt dit nog: https://autoriteitpersoon...soonsgegevens-op-internet

[Killjoy]

Verwijderd schreef op woensdag 28 maart 2018 @ 11:50:
Ik heb ook een praktische vraag: wij organiseren jaarlijks een groot ledenevenement waar 1000+ mensen komen. In het aanmeldingsformulier hebben we dit jaar netjes conform AVG-vereiste een toestemmingsvraag opgenomen over bezwaar wel/niet tegen maken van foto- en filmmateriaal waar ze mogelijk herkenbaar in beeld komen. Deze sfeerimpressies worden gebruikt op de website (staat er bij). Nu hebben best veel mensen aangegeven dat ze bezwaar hebben, en zitten wij met praktisch probleem hoe met die mensen om te gaan die we niet allemaal van gezicht kennen. Achteraf eruit filteren is dus niet mogelijk. Iemand praktische suggesties?

Frogmen schreef op woensdag 28 maart 2018 @ 13:46:
Nou hier wringt het juist, foto's is echt een drama. Leuk bedacht maar in de uitvoering komt het er al gauw op neer dat je geen foto's met mensen meer mag plaatsen. Het vervelende is dat je het als vrije keuze moet plaatsen. Echt er wordt een probleem gemaakt van iets wat nooit een probleem is geweest. Reden is vooral dat er een theoretische mogelijkheid is om mensen in foto's te zoeken. Maar wat met historische foto's enzo, als scouting hebben we een archief van meer dan 10.000 foto's.

Maar het interessante is: er is niets veranderd. Toestemming op grond van de AVG, artikel 6, lid 1, onder a) is niet wezenlijk anders dan toestemming op grond van de Wbp, artikel 8, onder a. Wat er veranderd is, is de focus die door velen ineens wordt gelegd op het toestemmingsvereiste. Dat was onder de Wbp al de vluchtstrook en dat is het ook onder de AVG. Er is geen absoluut vereiste ten aanzien van vrije keuze (In Duitsland ligt dat wat anders, overigens). En de Auteurswet is van 1912...

Bij jullie beiden gaat het om een besloten club met leden. Dat betekent dat er een overeenkomst ten grondslag ligt aan de relatie die je hebt met leden. In die overeenkomst kun je regelen dat het noodzakelijk is om persoonsgegevens te verwerken. Expliciet doe je dat in je Privacybeleid.

Organiseer je voor de leden een bijeenkomst waar je foto's maakt, communiceer dat dan expliciet. Dan kunnen leden zelf de afweging maken om te komen (en daarmee accepteren dat ze gefotografeerd kunnen worden) of weg te blijven. Uiteraard moet je bij het maken van foto's voorkomen dat je close ups neemt. Beperk je zoveel mogelijk tot sfeerfoto's. En zorg ervoor dat de foto's alleen voor leden toegankelijk zijn (inlog op de verenigingswebsite) En natuurlijk nog expliciet verwijzen naar de opt-out van de Auteurswet (redelijk belang) en de AVG (rechten betrokkene)

Voor een scouting geldt natuurlijk nog wel als aandachtspunt dat persoonsgegevens van minderjarigen worden verwerkt.

Enne, denk vooral eens goed na over de bewaartermijnen van de foto's. Ook iets voor je privacybeleid. Recht op gegevenswissing wordt anders een dingetje.

[Frogmen]

@Killjoy Daar ga je dus fout de keuze moet in alle vrijheid en zonder consequenties gedaan kunnen worden. Hou dat maar eens bij met foto's en 300 kinderen! Het is vrijwilligers werk en daar wordt geen rekening mee gehouden, gevolg geen foto's want 1 kan het dus verzieken voor een paar honderd anderen. Daarentegen de foto's die iemand zomaar op Facebook gooit daar kan je weinig tegen doen, zeker als het openbaar terrein is.

[Killjoy]

Frogmen schreef op maandag 2 april 2018 @ 21:33:
@Killjoy Daar ga je dus fout de keuze moet in alle vrijheid en zonder consequenties gedaan kunnen worden. Hou dat maar eens bij met foto's en 300 kinderen! Het is vrijwilligers werk en daar wordt geen rekening mee gehouden, gevolg geen foto's want 1 kan het dus verzieken voor een paar honderd anderen. Daarentegen de foto's die iemand zomaar op Facebook gooit daar kan je weinig tegen doen, zeker als het openbaar terrein is.

Waarop baseer je dat precies? Het toestemmingsvereiste is maar één van de grondslagen die de AVG kent. Ik kan prima beargumenteren dat het maken van foto's van activiteiten in verenigingsverband onderdeel is van de voorwaarden die komen met het lidmaatschap van de Scouting. Daarmee verwerk ik die gegevens op basis van AVG artikel 6, lid 1 onder b) : de verwerking is noodzakelijk voor de uitvoering van een overeenkomst waarbij de betrokkene partij is (...)

Kan het zijn dat je de grondslag voor verwerking (artikel 6, lid 1, a): toestemming voor verwerking) gelijkstelt met de toestemming voor publicatie? Want inderdaad zul je voor publicatie toestemming moeten hebben van de ouders/verzorgers (tot 16 jaar) of van het kind zelf (vanaf 16 jaar)

Echter: het toestemmingsvereiste voor publicatie is niet nieuw onder de AVG. Het is een bestaand vereiste onder de Wbp. Dus als dat nu al niet geregeld is, ben je al langer in overtreding. Het enige verschil tussen Wbp en AVG is dat je onder de AVG ook aan moet kunnen tonen dat je die toestemming hebt.

Overigens is dat precies het probleem. Veel organisaties voldoen niet aan de Wbp en eer je dat achterstallig onderhoud hebt ingehaald... Been there, still doing that...

Dus wil je als vereniging je leven makkelijk maken: ga dan niet over tot publicatie van de foto's. Alternatief is, om de toestemming algemeen in te winnen en periodiek (jaarlijks) uit te vragen. En je voor te bereiden op intrekkingsverzoeken...

Op dit punt schiet de huidige en nieuwe privacywetgeving zijn doel inderdaad voorbij, helaas.

[Frogmen]

Die toestemming vroegen we al ben alleen bang dat dat steeds meer gaat worden, waardoor het maken en publiceren (lees plaatsen op de website voor de ouders) verleden tijd wordt. Gevolg iedereen plaatst en deelt foto's op facebook. Ook de foto's die minder leuk zijn voor een kind. Joepie we hebben vooruitgang geboekt. En de macht van Facebook en consorten wordt nog groter. Sorry op dit vlak is de wet doorgeschoten.

[xAn52]

Waar ligt de grens? Als ik foto's maak bij een sportwedstrijd voor een sportclub, staan er mensen van andere clubs op, toeschouwers en mogelijk voorbijgangers. Nu heb ik wel toestemming van de spelers van de thuisclub, maar niet van de rest. Moet ik die gaan blurren? Moet ik daar ter plaatse toestemming aan gaan vragen en derhalve dus deze mensen op gaan nemen in een database?

En ja, een foto van iemand valt onder de privacywetgeving, aangezien je iemands ras van een foto kan herleiden.

[Frogmen]

Als je dus naar de letter van de wet kijkt wel, daarentegen mag de krant die foto gewoon plaatsen. Het zal echt wachten worden op jurisprudentie in deze.

[Fritsflow]

Als ik het goed begrijp is het volgens de GDPR straks verplicht om op het contactformulier op websites een vinkje te laten plaatsen "Ik stem in dat mij gegevens gebruikt worden voor het opgegeven doel" oid. ...
Dus: je hebt net je gegevens in zitten vullen op een website en dan moet je een vinkje zetten dat dat ook gebruikt mag worden.. Het formulier gewoon niet invullen is dan eenvoudiger toch?

Je kunt ook een vinkje zetten: "Ik heb net mijn gegevens ingevuld maar je mag er niks mee doen"..

Punt is dat Aleid Wolfsen straks wel boetes kan gaan uitdelen als je het verkeerd doet. Zo jammer dat bestuurders dit soort onzin bepalen.

[F_J_K]

"het opgegeven doel" natuurlijk nog even aanpassen naar het concrete doel.

Maar waarom zou je het vinkje NIET laten zetten (en de ja, datum, tijd, etc administreren)? Toch geen moeite? Ook geen moeite voor de invuller. Vinkje is minder werk dan contactgegevens typen. Of doe je er meer mee dan de invuller denkt? Het zou inderdaad mooi zijn als je separate vinkjes hebt voor alleen eenmalig info te verschaffen / om ook voortaan een nieuwsbrief te sturen / om door te verkopen aan Cambridge Analytica.

[Outerspace]

Wij zitten hier als vereniging ook erg mee te stoeien, gelukkig heeft de KNZB wel iets om mee te helpen: https://www.knzb.nl/veren...eid__organisatie/privacy/

Ik hoop dat er ooit een beknopte scan komt (of een lijst met to do's) zodat we makkelijker kunnen zien of we AVG/GDPR proof zijn.

[WvR79]

Outerspace schreef op dinsdag 10 april 2018 @ 14:41:
Wij zitten hier als vereniging ook erg mee te stoeien, gelukkig heeft de KNZB wel iets om mee te helpen: https://www.knzb.nl/veren...eid__organisatie/privacy/

Ik hoop dat er ooit een beknopte scan komt (of een lijst met to do's) zodat we makkelijker kunnen zien of we AVG/GDPR proof zijn.

Wij hebben als club via de bond (KNHB) toegang gekregen tot een AVG toolkit die precies dat biedt: een stappenplan om AVG compliant te worden. Zo te zien zijn er meerdere bonden bij aangesloten waaronder de KNZB. Zie ook https://avgverenigingen.nl/partnerlijst/

Met wat algemene kennis kom je dan een heel eind, en de voorbeelddocumenten zorgen ervoor dat je het wiel niet opnieuw hoeft uit te vinden.

[Falcon10]

Kan iemand me eigenlijk eens duidelijk proberen te vertellen wie nu eigenlijk een verwerkersovereenkomst moet opmaken in volgend vb ( en vermoed eerlijk gezegd dat beide partijen ze naar elkaar moeten opmaken ) :

Mijn boekhouder doet mijn boekhouding, dus ik ben klant van hem, en ik moet een verwerkersovereenkomst met hem afsluiten ( want ik ben verwerkersverantwoordelijke, en hij verwerker ), correct ?
Maar omgekeerd, ik doe ook bepaalde diensten voor mijn boekhouder, dus hij moet mij ook een verwerkersovereenkomst geven, maar dan omgekeerd, waar ik verwerker ben en hij verwerkersverantwoordelijke ? Juist ?

Of zie ik dat verkeerd ?

[Bob-B190]

Falcon10 schreef op zaterdag 14 april 2018 @ 07:48:
Kan iemand me eigenlijk eens duidelijk proberen te vertellen wie nu eigenlijk een verwerkersovereenkomst moet opmaken in volgend vb ( en vermoed eerlijk gezegd dat beide partijen ze naar elkaar moeten opmaken ) :

Mijn boekhouder doet mijn boekhouding, dus ik ben klant van hem, en ik moet een verwerkersovereenkomst met hem afsluiten ( want ik ben verwerkersverantwoordelijke, en hij verwerker ), correct ?
Maar omgekeerd, ik doe ook bepaalde diensten voor mijn boekhouder, dus hij moet mij ook een verwerkersovereenkomst geven, maar dan omgekeerd, waar ik verwerker ben en hij verwerkersverantwoordelijke ? Juist ?

Of zie ik dat verkeerd ?

Juist. Er zijn ook overigens mooie formats te vinden.

[EdiscoveryNL]

Knip. Dit is zo zonder overleg vooraf gewoon spam.

[ Voor 115% gewijzigd door F_J_K op 17-04-2018 09:39 ]

[Boermansjo]

Ik vindt dit verhaal ook niet echt duidelijk.
Hier in ons bedrijf zit er enkel klanten data in het ERP. Dit is puur voor aankoop/verkoop...
Er wordt niks van data verwerkt of gebruikt voor tele-marketing ofzo.
De klant vult een klantenfiche in en deze data komt in het ERP-systeem.

Nu is er blijkbaar een firma langs geweest die ons zo'n heel 'GDPR' plan wil verkopen (x aantal workshops) omdat wij anders niet in regel zijn...
Mag zo'n bedrijf echt zomaar binnen vallen ?
Is dat niet juist heel het doel van deze wetgeving ?

[Jazzy]

Boermansjo schreef op dinsdag 17 april 2018 @ 14:10:
Ik vindt dit verhaal ook niet echt duidelijk.
Hier in ons bedrijf zit er enkel klanten data in het ERP. Dit is puur voor aankoop/verkoop...
Er wordt niks van data verwerkt of gebruikt voor tele-marketing ofzo.
De klant vult een klantenfiche in en deze data komt in het ERP-systeem.

Nu is er blijkbaar een firma langs geweest die ons zo'n heel 'GDPR' plan wil verkopen (x aantal workshops) omdat wij anders niet in regel zijn...
Mag zo'n bedrijf echt zomaar binnen vallen ?
Is dat niet juist heel het doel van deze wetgeving ?

Mag een bedrijf proberen om jullie een dienst te verkopen? Ja natuurlijk mag dat. Of je er op ingaat of het liever zelf aanpakt of hulp van anderen aanneemt mag je natuurlijk zelf bepalen.

[jfeelders]

Moeten we (vereniging) als verwerkingsverantwoordelijke een verwerkingsovereenkomst met de ING opstellen als we bij de ING een jaarlijkse batch-incasso-opdracht aanbieden? Het aanbieden gebeurt in de vorm van het aanleveren/uploaden van een incassobestand welke de ING dan verwerkt. Het lijkt erop dat het Privacy Loket zich onttrekt aan de verantwoordelijkheid voor het aangaan van een verwerkersovereenkomst voor het afkaderen van het verwerkingsdoel, de te verwerken persoonsgegevens en de bewaartermijn van de persoonsgegevens. Ze zetten in op dat de rekeninghouder de opdrachtgever is en niet de vereniging die het incassobestand aanlevert. Dat terwijl er op hun servers een incassobestand met identificeerbare persoonsgegevens ter verwerking wordt opgeslagen.

[Killjoy]

jfeelders schreef op dinsdag 17 april 2018 @ 21:47:
Moeten we (vereniging) als verwerkingsverantwoordelijke een verwerkingsovereenkomst met de ING opstellen als we bij de ING een jaarlijkse batch-incasso-opdracht aanbieden? Het aanbieden gebeurt in de vorm van het aanleveren/uploaden van een incassobestand welke de ING dan verwerkt. Het lijkt erop dat het Privacy Loket zich onttrekt aan de verantwoordelijkheid voor het aangaan van een verwerkersovereenkomst voor het afkaderen van het verwerkingsdoel, de te verwerken persoonsgegevens en de bewaartermijn van de persoonsgegevens. Ze zetten in op dat de rekeninghouder de opdrachtgever is en niet de vereniging die het incassobestand aanlevert. Dat terwijl er op hun servers een incassobestand met identificeerbare persoonsgegevens ter verwerking wordt opgeslagen.

De ING bepaalt de voorwaarden voor hun financiële dienstverlening. Je doet namelijk geen incassoverzoek, maar een incassovoorstel. De ING zal het voorstel alleen in behandeling nemen wanneer de aangeleverde gegevens overeenkomen met hun eigen administratie.

Inderdaad is de rekeninghouder de feitelijke opdrachtgever. Die heeft jouw vereniging (de incassant) gemachtigd om het incassovoorstel namens hemzelf in te dienen.

[jfeelders]

Hoe zit het dan met het incassobestand met verzamelde persoonsgegevens dat ter verwerking op de systemen van de ING wordt opgeslagen? Daar is toch juist een verwerkingsovereenkomst voor bedoeld?

Het lijkt dat ze geen zin hebben in die rompslomp en dus dus doen alsof de regelgeving niet op hun van toepassing is.

[Killjoy]

ING is zelf verwerkingsverantwoordelijke voor de financiële dienst die zij aanbieden. Doel en middelen bepalen zij zelf binnen de kaders van de op hen van toepassing zijnde wet en regelgeving. Dus ook de bewaartermijnen.

[Falcon10]

Ben ik met je eens Killjoy, maar zelf zou je toch als klant zijnde van hen toch ergens op papier zicht moeten hebben hoe zij dat regelen.
Uiteindelijk is heel de AVG/GDPR juist voor bedoeld : transparantie en duidelijkheid.

[Killjoy]

Falcon10 schreef op woensdag 18 april 2018 @ 07:37:
Ben ik met je eens Killjoy, maar zelf zou je toch als klant zijnde van hen toch ergens op papier zicht moeten hebben hoe zij dat regelen.
Uiteindelijk is heel de AVG/GDPR juist voor bedoeld : transparantie en duidelijkheid.

Om te kunnen voldoen aan het transparantiebeginsel is dat inderdaad nodig. Een privacyverklaring is een veelgebruikt middel. Maar beter is dat gerichte informatie wordt verstrekt voorafgaand aan het afnemen van een specifieke dienst. Veel privacyverklaringen zijn trouwens meer 'cover your ass' documenten.

[Falcon10]

Mee eens.

Want hoe zit het eigenlijk bij reeds lopende contracten/overeenkomsten ?

Voorbeeld : mijn loon wordt reeds menig jaar door een bepaalde firma/sociaal secretariaat berekend/uitbetaald etc.
Ik heb in het begin een contract getekend met hen dat zij dit voor mij doen etc. Maar dat was nog ruim voor de GDPR.
Moet ik nu een verwerkersovereenkomst naar hen sturen die ze mogen handtekenen om akkoord te gaan dat ze met mijn persoonlijke gegevens voorzichtig zullen omgaan, niet langer bewaren dan nodig, blablabla, aangezien zij van mij simple data, en financiele data verwerken.
Of wordt er vanuit gegaan door het contract dat ik met hen reeds heb, dat dit ook zo wordt uitgevoerd/behandeld door hen ?

En zo zijn er menig voorbeelden vind ik :

Zoals hierboven reeds aangegeven door jfeelders met ING. Hoe zit het met de bank waar ik bij ben ? Moet ik hen ook een verwerkersovereenkomst voorleggen die ze mogen tekenen, want ook zij verwerken financiele persoonsgegevens van mij. En vermoed dat er in het contract wel staat dat dat ik met hen heb aangegaan toen ik een bankrekening opende bij hen dat die gegevens vertrouwelijk zijn en enkel door hen behandeld zullen worden, maar ik durf er donder op zeggen dat ze adhv mijn financiele verrichtingen ook bepaalde profiling toepassen op mijn bankrekening ism persoonsgegevens waardoor ik voor hen een klant ben die makkelijk/moeilijk een professionele lening zou kunnen krijgen, autolease interest etc, en om dat te mogen doen op mijn gegevens hebben ze toch wel een iets andere verwerkingsgrond nodig dan gewoon en contractuele toelaatbaarheid me dunkt.

[_Chris_]

Falcon10 schreef op zaterdag 14 april 2018 @ 07:48:
Kan iemand me eigenlijk eens duidelijk proberen te vertellen wie nu eigenlijk een verwerkersovereenkomst moet opmaken in volgend vb ( en vermoed eerlijk gezegd dat beide partijen ze naar elkaar moeten opmaken ) :

Het maakt niet uit wie hem maakt, als deze maar gemaakt / getekend is. Hetzelfde in lopende contracten, daarbij kunnen de voorwaarden soms een issue zijn, ook daar is het om er gezamelijk uit te komen

[Killjoy]

Falcon10 schreef op woensdag 18 april 2018 @ 09:44:
Mee eens.

Want hoe zit het eigenlijk bij reeds lopende contracten/overeenkomsten ?

De AVG is van toepassing op bestaande en nieuwe overeenkomsten.

Voorbeeld : mijn loon wordt reeds menig jaar door een bepaalde firma/sociaal secretariaat berekend/uitbetaald etc.
Ik heb in het begin een contract getekend met hen dat zij dit voor mij doen etc. Maar dat was nog ruim voor de GDPR.
Moet ik nu een verwerkersovereenkomst naar hen sturen die ze mogen handtekenen om akkoord te gaan dat ze met mijn persoonlijke gegevens voorzichtig zullen omgaan, niet langer bewaren dan nodig, blablabla, aangezien zij van mij simple data, en financiele data verwerken.
Of wordt er vanuit gegaan door het contract dat ik met hen reeds heb, dat dit ook zo wordt uitgevoerd/behandeld door hen ?

Het is belangrijk om onderscheid te maken tussen jouw handelen als individu en jouw zakelijke activiteiten. Dat is in de situatie van kleine zelfstandigen best lastig, aangezien het gaat om het handelen van natuurlijke personen.

In dit geval ga jij als ondernemer een zakelijke overeenkomst aan met de betreffende firma met als doel om onder jouw verantwoordelijkheid jouw salarisadministratie uit te voeren. Die firma heeft zelf geen wettelijke grondslag om jouw gegevens te verwerken. Dus ben jij verwerkingsverantwoordelijk en is de betreffende firma verwerker. Daarbij hoort een verwerkersovereenkomst. Eigenlijk had je al een bewerkersovereenkomst moeten hebben op basis van de bestaande privacywetgeving, overigens.

En zo zijn er menig voorbeelden vind ik :

Zoals hierboven reeds aangegeven door jfeelders met ING. Hoe zit het met de bank waar ik bij ben ? Moet ik hen ook een verwerkersovereenkomst voorleggen die ze mogen tekenen, want ook zij verwerken financiele persoonsgegevens van mij. En vermoed dat er in het contract wel staat dat dat ik met hen heb aangegaan toen ik een bankrekening opende bij hen dat die gegevens vertrouwelijk zijn en enkel door hen behandeld zullen worden, maar ik durf er donder op zeggen dat ze adhv mijn financiele verrichtingen ook bepaalde profiling toepassen op mijn bankrekening ism persoonsgegevens waardoor ik voor hen een klant ben die makkelijk/moeilijk een professionele lening zou kunnen krijgen, autolease interest etc, en om dat te mogen doen op mijn gegevens hebben ze toch wel een iets andere verwerkingsgrond nodig dan gewoon en contractuele toelaatbaarheid me dunkt.

Hierbij ligt het anders. Jij bent geen financiële instelling, dus is er geen sprake van het uitbesteden van werkzaamheden. Bij een bank neem je een dienst af, waarbij het voor de bank noodzakelijk is om bepaalde persoonsgegevens te verwerken. Deels zijn dat verplichtingen die op de bank rusten, deels zijn dat voorwaarden volgend uit bedrijfsbelang. Bevallen de voorwaarden volgend uit het bedrijfsbelang van de bank je niet, dan ga je naar een andere bank.

Dus voor de dienst die jij afneemt, is de bank verwerkingsverantwoordelijke en moet dus voldoen aan alle eisen die de AVG stelt.

[bones]

Hebben jullie ook al te maken gehad met het hele cookie gebeuren betreffende de AVG? Ik ben dat nu voor websites in kaart aan het brengen, en als ik het goed begrijp werkt het als volgt:
- functionele cookies die noodzakelijk zijn voor de werking van een website (bijvoorbeeld winkelmandjes bij webshops), daarvoor heb je geen toestemming nodig van de bezoeker.
- Analytische cookies (zoals google analytics) moet je vermelden aan je bezoeker door middel van bijvoorbeeld een privacy verklaring, maar je hebt hiervoor geen specifieke toestemming nodig.
- Tracking cookies (zoals bij google adwords remarketing), hiervoor dien je toestemming te krijgen van de bezoeker voordat deze geplaatst wordt.

Nu zit ik voornamelijk met dat laatste, de tracking cookies. Je mag geen algemene cookiewall meer gebruiken, en je bezoeker moet vooraf aangeven of de tracking cookies wel/niet gebruikt mogen worden. Ik zit er zelf aan te denken om een script te fabriceren, die pas het remarketing script toevoegt aan de footer nadat de bezoeker toestemming gegeven heeft.

Iemand die hier al ervaring mee heeft?

[Tralapo]

In Google's laatste GDPR mailing naar AdSense klanten werd een lijstje gegeven met enkele betaalde en gratis varianten van een cookie opt-in.

Zo ook deze bijvoorbeeld. Daar is ook uitgelegd hoe je die dingen kunt inladen na een toestemming. Deze tool is ook open source dus je kunt 'm of zelfs gewoon gebruiken of als uitgangspunt gebruiken

[Chris_147]

Mag ik bij deze thread aansluiten met mijn vragen?
Ik ben zelfstandig freelancer en hou dus ook gegevens bij van klanten om deze later opnieuw te kunnen contacteren.

1) Tot nu toe gebruikte ik hier vooral LinkedIn voor. Dit is op mijn persoon, niet op mijn bedrijf, moet ik hier dan goedkeuring voor hebben? Of is het goedkeuren van een connectie voldoende om in regel te zijn, ook al was dit voor GDPR uitkwam?

2) LinkedIn is echter beperkt, dus ben ik nu ook gegevens (naam, tel, email, bedrijf, functie) gaan bijhouden in Bitrix24. Mijn account daarvoor is op mijn bedrijfsnaam aangemaakt dus valt zeker onder GDPR. Ik neem aan dat ik dus elk een email moet sturen om hun goedkeuring te vragen hiervoor?

3) Ik geef ook trainingen. Daarbij vraag ik om evaluaties in te vullen en natuurlijk wil ik hun gegevens bijhouden voor mogelijke vervolgopleidingen. Is het voldoende om hen een papier te laten tekenen bij de start van de training?

4) Wat als ik niets bijhoudt in Bitrix24, maar bvb enkel email. Iemand stuurt mij een email en onderaan staan hun gegevens. Ik verwijder die email niet, moet ik dan ook toestemming vragen? Tenslotte kan ik met goede zoekmogelijkheden of goede folderstructuur quasi even snel hun gegevens vinden.

5) Is er een voorbeeld GRPD overeenkomst beschikbaar?

6) Ik werk voornamelijk in België en Nederland. Zijn er verschillen in de GDPR implementatie tussen deze landen?

[ Voor 4% gewijzigd door Chris_147 op 01-05-2018 07:38 ]

[DJMaze]

Vandaag een bedrijf gebeld vanwege een datalek.
Of ik de Data Protection Officer / Functionaris voor de Gegevensbescherming kon spreken:

"wij hebben niemand met zo'n dure functienaam in dienst" 🙊

Dan maar een e-mailing partner gebeld:
"Ja top, hij is er vandaag niet. Ik zal je even doorverbinden met iemand" 👍

Dat de Overheid/AP geen campagne houdt voor het (klein)bedrijf is mij een raadsel want blijkbaar bij de grote jongens weet al het personeel wel wat er wordt bedoeld.

Nou is de term best onhandig.
Misschieen maar vragen naar "de persoon die over veiligheid gaat"?
Hoe zeggen jullie dat?

[Miepermans]

DJMaze schreef op woensdag 2 mei 2018 @ 17:56:
Hoe zeggen jullie dat?

Daar is maar 1 oplossing voor, Trainen, Trainen, Trainen. Bij het bedrijf waar ik nu werkzaam ben staat het al een lange tijd op de agenda. Ondertussen is voor het gemak de FG-rol aan onze legal medewerker toegekend. Dat is natuurlijk niet overal vanzelfsprekend.

Ik vermoedt dat er op korte termijn door alle bedrijven wel iets mee gedaan MOET worden, en dan zal mogelijk ook het proces om de DPO/FG te kunnen bereiken meer bekendheid krijgen binnen zowel grote als kleine organisaties.

[Baris]

Chris_147 schreef op dinsdag 1 mei 2018 @ 07:36:
Mag ik bij deze thread aansluiten met mijn vragen?
Ik ben zelfstandig freelancer en hou dus ook gegevens bij van klanten om deze later opnieuw te kunnen contacteren.

1) Tot nu toe gebruikte ik hier vooral LinkedIn voor. Dit is op mijn persoon, niet op mijn bedrijf, moet ik hier dan goedkeuring voor hebben? Of is het goedkeuren van een connectie voldoende om in regel te zijn, ook al was dit voor GDPR uitkwam?

2) LinkedIn is echter beperkt, dus ben ik nu ook gegevens (naam, tel, email, bedrijf, functie) gaan bijhouden in Bitrix24. Mijn account daarvoor is op mijn bedrijfsnaam aangemaakt dus valt zeker onder GDPR. Ik neem aan dat ik dus elk een email moet sturen om hun goedkeuring te vragen hiervoor?

3) Ik geef ook trainingen. Daarbij vraag ik om evaluaties in te vullen en natuurlijk wil ik hun gegevens bijhouden voor mogelijke vervolgopleidingen. Is het voldoende om hen een papier te laten tekenen bij de start van de training?

4) Wat als ik niets bijhoudt in Bitrix24, maar bvb enkel email. Iemand stuurt mij een email en onderaan staan hun gegevens. Ik verwijder die email niet, moet ik dan ook toestemming vragen? Tenslotte kan ik met goede zoekmogelijkheden of goede folderstructuur quasi even snel hun gegevens vinden.

5) Is er een voorbeeld GRPD overeenkomst beschikbaar?

6) Ik werk voornamelijk in België en Nederland. Zijn er verschillen in de GDPR implementatie tussen deze landen?

1) Tot nu toe gebruikte ik hier vooral LinkedIn voor. Dit is op mijn persoon, niet op mijn bedrijf, moet ik hier dan goedkeuring voor hebben? Of is het goedkeuren van een connectie voldoende om in regel te zijn, ook al was dit voor GDPR uitkwam?

Zolang je inmail van Linkedin gebruikt voor het benaderen van je contacten, zie ik er geen probleem om je connecties te benaderen. Als ze geen inmail berichten meer willen ontvangen, zijn ze vrij om je te verwijderen Pas wel op, dit is alleen voor Inmail. Niet voor emails naar (prive) emailadressen van personen op Linkedin. Dan bouw je als het waren een e-maillijst op, waarbij je aan veel meer zaken moet voldoen (los van of ze hier toestemming voor geven of niet)
Interessant artikel misschien voor je? https://www.linkedin.com/...you-need-know-greg-cooper

2) LinkedIn is echter beperkt, dus ben ik nu ook gegevens (naam, tel, email, bedrijf, functie) gaan bijhouden in Bitrix24. Mijn account daarvoor is op mijn bedrijfsnaam aangemaakt dus valt zeker onder GDPR. Ik neem aan dat ik dus elk een email moet sturen om hun goedkeuring te vragen hiervoor?

Zeker. Ik zou je aanraden om je klanten te mailen over het doel van de verwerking, welke gegevens, waar (Bitrix24?) en hoelang ze worden opgeslagen etc. Het zou mooi zijn als je een privacy policy maakt op je zzp website en hier ook naar toe verwijst. Indien ze niet akkoord zijn.. dan weet je wat je moet doen.

3) Ik geef ook trainingen. Daarbij vraag ik om evaluaties in te vullen en natuurlijk wil ik hun gegevens bijhouden voor mogelijke vervolgopleidingen. Is het voldoende om hen een papier te laten tekenen bij de start van de training?

Gewoon expliciet op papier vermelden wat het doel van het verzamelen van de gegevens zijn, en dus niet verplichten om deze gegevens in te vullen. Hiermee heb in feite toestemming. Let hierbij weer op het feit dat je ze ten alle tijden het recht hebben om hun emailadres uit de e-maillijst te halen, dus bied hier de mogelijkheden voor!

4) Wat als ik niets bijhoudt in Bitrix24, maar bvb enkel email. Iemand stuurt mij een email en onderaan staan hun gegevens. Ik verwijder die email niet, moet ik dan ook toestemming vragen? Tenslotte kan ik met goede zoekmogelijkheden of goede folderstructuur quasi even snel hun gegevens vinden.

Vragen voor toestemming is altijd goed. Zolang je expliciet toestemming krijgt om deze gegevens te verwerken, dan kan je dit voor alleen het doel gebruiken.

5) Is er een voorbeeld GRPD overeenkomst beschikbaar?

Wat bedoel je hiermee? Heb je het dan over een verwerkersovereenkomst tussen jou en Bitrix24?

6) Ik werk voornamelijk in België en Nederland. Zijn er verschillen in de GDPR implementatie tussen deze landen?

Nee, de GDPR is een Europese verordening dus hierin verschilt niks. Wel kan er in de uitvoeringswet het een en ander verschillen (zoals wie de autoriteit is in het land, in ons geval de AP). Ik heb de verschillen niet zo paraat, maar dat zal je even zelf moeten Googlen of een andere Tweaker heeft misschien hier antwoord op

[ Voor 0% gewijzigd door Baris op 03-05-2018 11:03 . Reden: opmaak :) ]

[Arjant2]

Boermansjo schreef op dinsdag 17 april 2018 @ 14:10:
Ik vindt dit verhaal ook niet echt duidelijk.
Hier in ons bedrijf zit er enkel klanten data in het ERP. Dit is puur voor aankoop/verkoop...
Er wordt niks van data verwerkt of gebruikt voor tele-marketing ofzo.
De klant vult een klantenfiche in en deze data komt in het ERP-systeem.

Nu is er blijkbaar een firma langs geweest die ons zo'n heel 'GDPR' plan wil verkopen (x aantal workshops) omdat wij anders niet in regel zijn...
Mag zo'n bedrijf echt zomaar binnen vallen ?
Is dat niet juist heel het doel van deze wetgeving ?

Het opslaan in een bestand van dergelijke data valt al heel snel onder de AVG. Je komt er niet mee weg om te zeggen dat het niet voor telemarketing wordt gebruikt, dat laatste doet er in feite niet toe.
Als je persoonsgegevens opslaat dien je te voldoen aan de AVG.

[Brainscrewer]

DJMaze schreef op woensdag 2 mei 2018 @ 17:56:
Vandaag een bedrijf gebeld vanwege een datalek.
Of ik de Data Protection Officer / Functionaris voor de Gegevensbescherming kon spreken:

"wij hebben niemand met zo'n dure functienaam in dienst" 🙊

Dan maar een e-mailing partner gebeld:
"Ja top, hij is er vandaag niet. Ik zal je even doorverbinden met iemand" 👍

Dat de Overheid/AP geen campagne houdt voor het (klein)bedrijf is mij een raadsel want blijkbaar bij de grote jongens weet al het personeel wel wat er wordt bedoeld.

Nou is de term best onhandig.
Misschieen maar vragen naar "de persoon die over veiligheid gaat"?
Hoe zeggen jullie dat?

Ik zou beginnen met het team dat over de informatiebeveiliging gaat, en daar naar vragen. Vaak zijn deze teams wel op de hoogte van de interne procedures m.b.t. datalekken en kunnen op basis daarvan ook de FG bijgeschakelen. Eventueel zou je het zelfs via de ICT Servicedesk kunnen proberen.

Overigens is een FG pas in een drietal gevallen verplicht:

1. Overheidsorganisaties- en organen met uitzondering van gerechten bij uitoefening van hun rechterlijke taken;*

2. Organisaties die hoofdzakelijk zijn belast met verwerkingen die vanwege hun aard, omvang en/of doeleinden regelmatige en stelselmatige observatie op grote schaal van betrokkenen vereisen;*

3. Wanneer één van de kernactiviteiten van een organisatie het grootschalig verwerken van (bijzondere) persoonsgegevens is of gegevens met betrekking tot strafrechtelijke veroordelingen en strafbare feiten.*

* Bron: https://www.privacycompan...herming-fg-dpo-verplicht/

[Boermansjo]

Arjant2 schreef op donderdag 3 mei 2018 @ 11:20:
[...]

Het opslaan in een bestand van dergelijke data valt al heel snel onder de AVG. Je komt er niet mee weg om te zeggen dat het niet voor telemarketing wordt gebruikt, dat laatste doet er in feite niet toe.
Als je persoonsgegevens opslaat dien je te voldoen aan de AVG.

Mijn vraag was meer bedoeld over hoe men data die aanwezig is in een ERP moeten bekijken...
Als de klant niet wil dat zijn gegevens in het ERP systeem komt, wat moet je dan doen ? gewoon zeggen van sorry klant maar je kan geen orders plaatsten bij ons...

Ook kan je moeilijk de hele klant uit het systeem verwijderen als die dat wil. Of gaan al de grote spelers zoals AX of SAP hun pakket moeten aanpassen ?

[F_J_K]

Gegevens die nodig zijn om een overeenkomst uit te voeren mag je -voor dat doel- prima verwerken. Als je het in een elders gehost CRM of ERP doet dan is er een verwerkersovk nodig. In de regel hebben de grote jongens er wel een. Die je natuurlijk wel wilt lezen en begrijpen voor je er mee akkoord gaat.

En ja systemen van ook de grote spelers worden aangepast (of bij fatsoenlijk flexibele systemen: kan je zelf de inrichting anders doen. Bijvoorbeeld rechten en logging strakker, bepaalde velden niet meer verplichten of zelfs verwijderen, etc.).

Voorbeeld verwerkersovk: https://www.rijksoverheid...erwerkersovereenkomst-avg maar ga voor kleine opdrachtjes met grote spelers niet zelf een overeenkomst uitonderhandelen. Kijk of hun eigen standaarddocument voldoet, zo niet overweeg een andere leverancier.

Edit: https://blog.iusmentis.co...ogle-drive-onder-de-gdpr/ geeft een relevant voorbeeld.

[ Voor 8% gewijzigd door F_J_K op 03-05-2018 13:04 ]

[Arjant2]

Boermansjo schreef op donderdag 3 mei 2018 @ 12:13:
[...]


Mijn vraag was meer bedoeld over hoe men data die aanwezig is in een ERP moeten bekijken...
Als de klant niet wil dat zijn gegevens in het ERP systeem komt, wat moet je dan doen ? gewoon zeggen van sorry klant maar je kan geen orders plaatsten bij ons...

Ook kan je moeilijk de hele klant uit het systeem verwijderen als die dat wil. Of gaan al de grote spelers zoals AX of SAP hun pakket moeten aanpassen ?

F_J_K schreef op donderdag 3 mei 2018 @ 12:52:
Gegevens die nodig zijn om een overeenkomst uit te voeren mag je -voor dat doel- prima verwerken. Als je het in een elders gehost CRM of ERP doet dan is er een verwerkersovk nodig. In de regel hebben de grote jongens er wel een. Die je natuurlijk wel wilt lezen en begrijpen voor je er mee akkoord gaat.

Je mag inderdaad die gegevens verwerken als die voor het uitvoeren van de overeenkomst nodig zijn. MAAR daarmee val je nog steeds onder de AVG. Je zal dus maatregelen moeten nemen en die documenteren, je moet tevens je klanten informeren wat voor informatie je opslaat, waarom je die opslaat, wat ze moeten doen als ze het willen aanpassen cq verwijderen etc. Dus ook al is het alleen nodig voor het uitvoeren van een order of dienst, dan nog moet je alle bovenstaande stappen uitvoeren.

Het beste lees je dit gewoon even door. Is vrij duidelijk met ja/nee schema's en wat je moet doen:

https://www.rijksoverheid...ening-gegevensbescherming

En direct antwoord op je vraag, je moet die gegevens inderdaad verwijderen als de klant daarom vraagt als de opdracht is uitgevoerd. Tevens moet je zelf in je privacy policy aangeven aan de klant hoe lang zijn gegevens worden bewaard. En als een klant niet wil dat zijn gegevens opgenomen worden voor dat hij daadwerkelijk klant wordt, ja dan moet je hem weigeren als je die opdracht niet zonder die gegevens kan uitvoeren. Maar goed dit kan je in feite allemaal nalezen in de handleiding.

PS Disclaimer: ik ben ook geen specialist maar heb dit traject net vorige week in kaart gebracht voor ons bedrijf, vandaar dat ik er nu redelijk goed in zit. Elke situatie is net wat anders, maar met de handleiding kom je heel ver.

[ Voor 16% gewijzigd door Arjant2 op 03-05-2018 14:49 ]

[Chris_147]

@Baris bedankt voor de uitleg.
Zijn er voorbeelden van een privacy policy?
Wat moet er allemaal instaan?

[Baris]

Chris_147 schreef op donderdag 3 mei 2018 @ 16:26:
@Baris bedankt voor de uitleg.
Zijn er voorbeelden van een privacy policy?
Wat moet er allemaal instaan?

Je zou kunnen googlen op privacy policy en kijken of het aangepast is aan de AVG. Deze bijvoorbeeld? https://avgverenigingen.nl/privacy-policy/

Wel uiteraard aanpassen naar jou situatie.

[luuj]

Chris_147 schreef op donderdag 3 mei 2018 @ 16:26:
@Baris bedankt voor de uitleg.
Zijn er voorbeelden van een privacy policy?
Wat moet er allemaal instaan?

Je zou ook de tool van veiliginternetten.nl kunnen gebruiken om een privacy policy te genereren.

[Chris_147]

Bedankt!

[Baris]

luuj schreef op donderdag 3 mei 2018 @ 16:41:
[...]


Je zou ook de tool van veiliginternetten.nl kunnen gebruiken om een privacy policy te genereren.

Deze inderdaad! was het even vergeten, dank!

[Blueflame_Core]

Heeft iemand van jullie de model verwerkersovereenkomst arbit al eens in gevuld? Het kan namelijk aan mij liggen maar ik vind het vrij ingewikkeld om deze in te vullen.
Er staan namelijk dingen in dat ik denk huh, DE MINISTER/STAATSSECRETARIS VAN/VOOR [naam portefeuille] ???

Het zou misschien handig zijn als zo'n overeenkomst voor een ieder makkelijk is in te vullen?

Laat maar, ik kwam er op eens achter dat dit niet een algemene overeenkomst is maar echt een voor de overheid -.-

[ Voor 10% gewijzigd door Blueflame_Core op 07-05-2018 14:31 ]

[Verwijderd]

Na maanden hiermee bezig te zijn geweest denk ik eindelijk min of meer te snappen wat de bedoeling is en wat er van iedereen verwacht wordt. Echter zit ik nu nog met een laatste prangende vraag: wat is de meldplicht van de verwerker?
Ik kreeg van mijn hoster (mijn subverwerker dus) een contract aangeboden waarin stond dat hij - als verwerker - wettelijk geen melding van lekken màg maken bij de autoriteiten. Hij is enkel gehouden aan het melden van een lek bij de controller (verantwoordelijke), ik dus. Dat verbod om zelf meldingen te maken bij de overheden is volgens mij zijn persoonlijke interpretatie, maar er staat inderdaad niets van in de GDPR (verwerker: melding aan verantwoordelijke binnen aanvaardbare termijn - "without undue delay", voor de controller geldt een meldplicht aan de overheid binnen 72 uur, zie https://gdpr-info.eu/art-33-gdpr/).
Maar hoe zit het nu in mijn geval? Ik heb een online plaform dat door mijn klanten gebruikt wordt. Ik ben verwerker, mijn klanten zijn controllers of verantwoordelijke voor wat er in het platform komt (maar het gaat wel om data van personen). Ik beslis niet wat er gebeurt met de data en doe er verder niets mee, het is een tool voor de klant.
Stel nu dat mijn systeem gehackt wordt. Volstaat het dan dat ik mijn klanten (IT noobs met geen verstand van gdpr of wat dan ook) hiervan op de hoogte stel? Is het dan aan mijn klanten om dit door te geven aan de autoriteiten? Mag ik dat zelf niet eens?
Wat als het volledige systeem gekraakt wordt en alle data op straat komt te liggen (door een fout van mij of een van mijn subverwerkers).
Moet ik al mijn klanten op de hoogte stellen en is het dan aan de klant om de autoriteiten en de betrokken personen op de hoogte te stellen?

edit: nog een bijkomende maar gelijkaardige vraag: wat als een klant van mijn klant mij rechtstreeks contacteert om te vragen om "vergeten te worden". Ben ik verplicht hem uit mijn systeem te halen of moet ik hem naar mijn klant (de verantwoordelijke) doorverwijzen?

[ Voor 7% gewijzigd door Verwijderd op 11-05-2018 11:31 ]

[jfeelders]

Zijn de servers waar de informatie op gehost wordt van jou en heb je geen directe band met de persoonsgegevens die daarop verwerkt worden door je klanten dan ben jij de verwerker en moet je de verwerkersverantwoordelijken binnen 72 op de hoogte brengen van een datalek. Ook bij het recht om vergeten te worden moet je terug verwijzen naar de verwerkersverantwoordelijken.

[Yucon]

Nu heeft iedereen als het over GDPR gaat wel direct over ICT, maar volgens mij is er nog een minstens zo lastige hobbel. Bijna elk bedrijf heeft nog flinke papieren archieven. Daar is bijna geen doorkomen aan.. betekent dit dat je vrijwel gedwongen bent het domweg weg te gooien?

_{niet dat het perse verkeerd is flink op te ruimen, maar volgens mij is echt nog niemand daar in deze context mee bezig}

[ Voor 19% gewijzigd door Yucon op 11-05-2018 20:23 ]

[jfeelders]

Is er een privacyrisico met die papier archieven. Als je in je Privacybeleid hebt afgekaderd dat persoonsgegevens voor een doel verwerkt mogen worden dan is de vorm waarin die persoonsgegevens worden bewaard niet veel meerwerk. Uiteindelijk komt het neer op het opstellen van geheimhoudingsverklaringen voor je bestuurs-/commissieleden/interne gegevensverwerkers die met persoonsgegevens in aanraking komen.

[Falcon]

Onderstaande handleiding/guide vanuit NOREA is trouwens een handig hulpmiddel om je eigen organisatie eens te auditen:

https://www.norea.nl/nieu...ol-framework-gepubliceerd

Boekwerk van 70 pagina's, maar onder diverse topics staan controle punten beschreven.

[Verwijderd]

jfeelders schreef op vrijdag 11 mei 2018 @ 19:14:
Zijn de servers waar de informatie op gehost wordt van jou

Van wie de server is doet er niet toe lijkt me, hij kan best aan een hoster toebehoren en dat maakt dan geen verschil.

en heb je geen directe band met de persoonsgegevens die daarop verwerkt worden door je klanten dan ben jij de verwerker en moet je de verwerkersverantwoordelijken binnen 72 op de hoogte brengen van een datalek.

Dat klopt niet! De GDPR stelt vreemd genoeg dat de verwerker de verantwoordelijke zonder onredelijke vertraging (artikel 33.2) op de hoogte moet brengen, zonder te specifiëren wat die onredelijke vertraging is.
De verantwoordelijke moet de betrokkenen en de toezichthouder binnen 72 uur informeren

[Bob-B190]

Verwijderd schreef op woensdag 16 mei 2018 @ 10:40:
[...]

Van wie de server is doet er niet toe lijkt me, hij kan best aan een hoster toebehoren en dat maakt dan geen verschil.

[...]


Dat klopt niet! De GDPR stelt vreemd genoeg dat de verwerker de verantwoordelijke zonder onredelijke vertraging (artikel 33.2) op de hoogte moet brengen, zonder te specifiëren wat die onredelijke vertraging is.
De verantwoordelijke moet de betrokkenen en de toezichthouder binnen 72 uur informeren

Je trekt twee dingen samen: Betrokkene en toezichthouder alleen als er een ernstig risico is op schade voor de betrokkenen en dan onverwijld (dus niet binnen 72u). De toezichthouder alleen als er risico is op schade voor de betrokkene en dan heb je 72u (let op, telt door tijdens weekend en feestdagen).

[Bob-B190]

Verwijderd schreef op vrijdag 11 mei 2018 @ 09:39:
edit: nog een bijkomende maar gelijkaardige vraag: wat als een klant van mijn klant mij rechtstreeks contacteert om te vragen om "vergeten te worden". Ben ik verplicht hem uit mijn systeem te halen of moet ik hem naar mijn klant (de verantwoordelijke) doorverwijzen?

Verwijzen naar de verwerkingsverantwoordelijke. Jij handelt binnen de kaders zoals afgesproken in de verwerkersovereenkomst. De verantwoordelijke is verantwoordelijk voor het naleven van de rechten van de betrokkene. Als het goed is staat in de overeenkomst ook de gegevens van de FG, dus dat moet niet moeilijk zijn.

[Verwijderd]

Bob-B190 schreef op donderdag 17 mei 2018 @ 10:29:
[...]
Je trekt twee dingen samen: Betrokkene en toezichthouder alleen als er een ernstig risico is op schade voor de betrokkenen en dan onverwijld (dus niet binnen 72u). De toezichthouder alleen als er risico is op schade voor de betrokkene en dan heb je 72u (let op, telt door tijdens weekend en feestdagen).

klopt ook niet helemaal:

Artikel 33
1. Indien een inbreuk in verband met persoonsgegevens heeft plaatsgevonden, meldt de verwerkingsverantwoordelijke deze zonder onredelijke vertraging en, indien mogelijk, uiterlijk 72 uur ...aan de ...toezichthoudende autoriteit,

Artikel 34
1. Wanneer de inbreuk in verband met persoonsgegevens waarschijnlijk een hoog risico inhoudt voor de rechten en vrijheden van natuurlijke personen, deelt de verwerkingsverantwoordelijke de betrokkene de inbreuk in verband met persoonsgegevens onverwijld mee.

Er wordt nergens melding gemaakt van onverwijld meedelen aan de toezichthoudende authoriteit.

edit: overigens is onverwijld weer zo'n typisch vage term waar heel die gdpr vol mee staat.
Is het nu echt zo moeilijk om de dingen gewoon duidelijk te stellen?

[ Voor 6% gewijzigd door Verwijderd op 17-05-2018 11:44 ]

[F_J_K]

offtopic:
Onverwijld is m.i. juist duidelijk en vooral werkbaar. "Binnen 4 uur" is soms werkbaar en soms niet. "Binnen 72 uur" is soms werkbaar en soms niet, en soms veel te traag en soms met piepende banden haalbaar. Soms moet je vooral eerst de aandacht besteden aan voorkomen van verdere problemen. Onverwijld is dan prima verwoord. Toon achteraf desgevraagd maar aan dat je niet bent gaan treuzelen.

Zeker in wetgeving rond de IT moet je IMHO niet te concreet zijn, dan is je hele concrete tekst binnen no time achterhaald.

[Verwijderd]

Ik sponsor een website en mailomgeving voor een sportvereniging, gratis en voor nop, nu krijg ik een verwerkersovereenkomst, echter daarin zie ik dat ik als ik een datalek zou hebben dat ik aansprakelijk ben voor allerlei dingen inclusief schade. Nou begrijp ik dat op zich wel als je betalende klant bent, maar ik neig toch om niet te tekenen. Nou is mijn hosting wel goed op orde, 2fa, firewalls, etc, maar omdat ik dit gratis doe vind ik dit nogal een raar iets. Ben ik verplicht dit te tekenen ?

Op de website van de sportvereniging die niet door mij wordt onderhouden staan wel naw gegevens inclusief jongeren onder de 16.

Mijns inziens moeten ze dat eraf halen dan is die hele verwerkersovereenkomst ook niet nodig, het lijkt wel alsof ik me iets in de schoenen krijg geschoven als zij een fout maken., ( bijvoorbeeld verouderde wordpress installatie die ze daadwerkelijk ook hebben).

[ Voor 27% gewijzigd door Verwijderd op 21-05-2018 23:41 ]

[F_J_K]

Jij bent niet verplicht te tekenen als verwerker, maar je bent ook zonder tekenen verantwoordelijk en verplicht tot fatsoenlijk werk. En zij moeten voor vrijdag (!) stoppen als je niet tekent (en ook fatsoenlijk omspringt met de gegevens). Want, jij mag alleen in opdracht van hen verwerken. En zei mogen geen opdracht geven zonder verwerkersovk met de juiste afspraken. En er zijn diverse dingen die je moet regelen in de verwerkersovk, of niet en dan ook nul data meer hebben. (Die je natuurlijk de komende dagen dan netjes overhandigt incl alle documentatie, en dan na controle door hen alles verwijderd, incl je backups).

In dit geval zou een overeenkomst waar zo min mogelijk aansprakelijkheid bij jou ligt niet vreemd zijn. Nul aansprakelijkheid kan niet. Wel kan je de kans nihil maken door zelf fatsoenlijk en veilig te werken. Waaronder weigeren met verouderde software te werken als dat te veel risico geeft op datalekken. Al zou je in de overeenkomst kunnen vastleggen dat je slechts het os host en ze zelf de rest doen en ze zelf de beveiliging verzorgen. Als dat zo is dan.

Maar, ben je wel de verwerker? Of betaal je namens de vereniging een hoster / beheerder die direct een verwerkersovk kan aangaan? (En er vast een ‘op de plank heeft liggen’ die misschien voldoet).

[ Voor 6% gewijzigd door F_J_K op 22-05-2018 00:23 ]

[Verwijderd]

Je bent nooit verplicht een overeenkomst te tekenen.
De sportclub is verwerkingsverantwoordelijke en jij bent verwerker. Zij hebben rechten, maar zeker ook plichten en zij blijven aansprakelijk voor de gegevens die ze zelf verzamelen. Jouw aansprakelijkheid is tov de club.
Stuur ze zelf een voorstel van een overeenkomst waarin staat dat de schade die vergoed wordt nooit meer kan zijn dan het betaalde bedrag (is een redelijk standaard clausule), als ze niet akkoord zijn zoeken ze best een andere verwerker.

Mijns inziens moeten ze dat eraf halen dan is die hele verwerkersovereenkomst ook niet nodig

Dat zie je verkeerd.

edit: overigens ontslaat geen enkel contract iemand van de wettelijke verplichtingen en bepalingen van artikel 82

[ Voor 21% gewijzigd door Verwijderd op 22-05-2018 09:57 ]

[isomis]

Ik heb een paar van die stille hosting klanten met oude websites. Die negeren gewoon een verwerkersovereenkomst met mij af te sluiten. Hoe moet je daarmee omgaan? Ik host namelijk wel de websites.

[NiGeLaToR]

isomis schreef op dinsdag 22 mei 2018 @ 11:17:
Ik heb een paar van die stille hosting klanten met oude websites. Die negeren gewoon een verwerkersovereenkomst met mij af te sluiten. Hoe moet je daarmee omgaan? Ik host namelijk wel de websites.

De verantwoordelijke is degene die aansprakelijkheid heeft in GDPR gerelateerde zaken. Jij als verwerker kunt dus wel aangeven dat je graag een verwerkersovereenkomst afsluit, maar het is de verantwoordelijkheid van degene die verantwoordelijk is voor de verwerking. Ik zou in jouw positie dit nogmaals benadrukken en nogmaals een voorstel voor verwerkingovereenkomst toesturen en misschien zelfs eenzijdig aangeven je hier aan te gaan houden. Je hebt dan zo'n beetje alles gedaan om dit te regelen, terwijl je 'maar' verwerker bent.

Ik zou niet zover gaan zoals wat ik nu regelmatig bij m'n klanten aantref om te dreigen met opschorting van de dienstverlening als er geen verwerkersovereenkomst ligt. Dit is namelijk 'gewoon' contractbreuk en niet in ene mogelijk omdat er een compliancy wetgeving actief wordt die er al 2 jaar is. Een goede verwerkersovereenkomst is belangrijker dan een slechte die met haast maar getekend wordt.

[isomis]

NiGeLaToR schreef op dinsdag 22 mei 2018 @ 11:22:
[...]


De verantwoordelijke is degene die aansprakelijkheid heeft in GDPR gerelateerde zaken. Jij als verwerker kunt dus wel aangeven dat je graag een verwerkersovereenkomst afsluit, maar het is de verantwoordelijkheid van degene die verantwoordelijk is voor de verwerking. Ik zou in jouw positie dit nogmaals benadrukken en nogmaals een voorstel voor verwerkingovereenkomst toesturen en misschien zelfs eenzijdig aangeven je hier aan te gaan houden. Je hebt dan zo'n beetje alles gedaan om dit te regelen, terwijl je 'maar' verwerker bent.

Ik zou niet zover gaan zoals wat ik nu regelmatig bij m'n klanten aantref om te dreigen met opschorting van de dienstverlening als er geen verwerkersovereenkomst ligt. Dit is namelijk 'gewoon' contractbreuk en niet in ene mogelijk omdat er een compliancy wetgeving actief wordt die er al 2 jaar is. Een goede verwerkersovereenkomst is belangrijker dan een slechte die met haast maar getekend wordt.

Ben ik niet verantwoordelijk voor de verwerking? Ik heb namelijk ooit de website gemaakt en de verwerking is mogelijk doordat ik een server heb ingericht en daar een website op heb geplempt. Kortom, ik speel eigenlijk een soort hosting bedrijfje voor een aantal klanten. Deze staan allemaal op droplets bij digital oceaan. Of moet ik digital oceaan als verantwoordelijke zien?

[NiGeLaToR]

isomis schreef op dinsdag 22 mei 2018 @ 11:26:
[...]


Ben ik niet verantwoordelijk voor de verwerking? Ik heb namelijk ooit de website gemaakt en de verwerking is mogelijk doordat ik een server heb ingericht en daar een website op heb geplempt. Kortom, ik speel eigenlijk een soort hosting bedrijfje voor een aantal klanten. Deze staan allemaal op droplets bij digital oceaan. Of moet ik digital oceaan als verantwoordelijke zien?

Als je dit in opdracht doet van de eigenaar van de website, dan is de eigenaar van de website verantwoordelijk. als je zelf eigenaar bent, dan ben je zelf verantwoordelijk. Zoals je het schetst voer je het uit (tegen betaling) in opdracht van een ander, dus dan is die partij verantwoordelijk voor de gegegensverwerking en moet dit dan ook regelen. Een verwerkersovereenkomst is in principe - mits er persoonsgegevens verwerkt worden op de betreffende website - wel een redelijke must gebleken. De verantwoordelijke moet immers afspreken hoe de verantwoording die deze draagt wordt overgedragen op de verwerker en voor welke gegevens dit geldt.

Of het in jouw situatie écht zo prangend is hangt er een beetje vanaf. Als je 101 e-mailadressen van mensen hebt verzameld dan zou je kunnen stellen - niet zo boeiend, maar als je complete dossiers over mensen bijhoudt inclusief hun sexuele geaardheid dan zit je aan de andere kant van het spectrum. Die inschatting moet je - met hulp van wat leidraad - zelf maken.

[isomis]

NiGeLaToR schreef op dinsdag 22 mei 2018 @ 11:40:
[...]


Als je dit in opdracht doet van de eigenaar van de website, dan is de eigenaar van de website verantwoordelijk. als je zelf eigenaar bent, dan ben je zelf verantwoordelijk. Zoals je het schetst voer je het uit (tegen betaling) in opdracht van een ander, dus dan is die partij verantwoordelijk voor de gegegensverwerking en moet dit dan ook regelen. Een verwerkersovereenkomst is in principe - mits er persoonsgegevens verwerkt worden op de betreffende website - wel een redelijke must gebleken. De verantwoordelijke moet immers afspreken hoe de verantwoording die deze draagt wordt overgedragen op de verwerker en voor welke gegevens dit geldt.

Of het in jouw situatie écht zo prangend is hangt er een beetje vanaf. Als je 101 e-mailadressen van mensen hebt verzameld dan zou je kunnen stellen - niet zo boeiend, maar als je complete dossiers over mensen bijhoudt inclusief hun sexuele geaardheid dan zit je aan de andere kant van het spectrum. Die inschatting moet je - met hulp van wat leidraad - zelf maken.

Zijn verouderde websites, dus het komt niet verder dan een contact formulier dat mailt naar de info@ van het bedrijf. Ik ga het volgende verder afmaken:

• privacy verklaring voor eigen website
• alle klanten via lets encrypt over naar https en aanbieden om GA ip-masking proof te maken
• klanten nogmaals mailen dat GDPR eraan komt en dat ze dit intern moeten uitzoeken
• algemene voorwaarden GDPR proof maken en alle klanten op de hoogte brengen van onze nieuwe AV[\li]
• Grote klanten wijze op punten en aangeven dat ze hier iemand op moeten zetten.

Volgens mij is dan alles netjes geregeld

Volgens mij ben ik dan goed bezig.

[jfeelders]

Volgens mij is het toch zo dat in de AVG (ten opzichte van de WBP) de verantwoordelijkheid voor het goed omgaan met persoonsgegevens bij zowel de verwerkingsverantwoordelijke als de verwerker ligt? De verantwoordelijke moet zorgen dat alles netjes geregeld is maar als er een datalek is dan kan de verwerker ook verantwoordelijk worden gehouden. Als de verwerkingsverantwoordelijke geen passende maatregelen treft moet de verwerker zijn verantwoordelijkheid afkaarten.

[Yucon]

jfeelders schreef op zaterdag 12 mei 2018 @ 08:25:
Is er een privacyrisico met die papier archieven. Als je in je Privacybeleid hebt afgekaderd dat persoonsgegevens voor een doel verwerkt mogen worden dan is de vorm waarin die persoonsgegevens worden bewaard niet veel meerwerk. Uiteindelijk komt het neer op het opstellen van geheimhoudingsverklaringen voor je bestuurs-/commissieleden/interne gegevensverwerkers die met persoonsgegevens in aanraking komen.

Ze worden bewaard en bevatten mogelijk persoonsgegevens. Dat is ongeveer het niveau waarop tot waarop veel organisaties komen. Denk ook aan 10 m3 techinsche tekeningen waar iemand in 1993 eens een briefje met adresgegevens tussen gestopt heeft.

Je kunt moeilijk iemand inzicht geven in wat je over hem weet als je eigenlijk niet eens weet wat dat is.

niet dat ik paniek wil veroorzaken, dat soep wordt vast niet zo heet opgegeten. Maar volgens mij is het wel degelijk relevant. Mocht je denken dat die oude troep niet belangrijk is; stel maar eens voor het ongezien weg te gooien, en stel de vraag daarna nog eens.

[Killjoy]

isomis schreef op dinsdag 22 mei 2018 @ 12:05:
[...]


Zijn verouderde websites, dus het komt niet verder dan een contact formulier dat mailt naar de info@ van het bedrijf. Ik ga het volgende verder afmaken:

• privacy verklaring voor eigen website
• alle klanten via lets encrypt over naar https en aanbieden om GA ip-masking proof te maken
• klanten nogmaals mailen dat GDPR eraan komt en dat ze dit intern moeten uitzoeken
• algemene voorwaarden GDPR proof maken en alle klanten op de hoogte brengen van onze nieuwe AV[\li]
• Grote klanten wijze op punten en aangeven dat ze hier iemand op moeten zetten.

Volgens mij is dan alles netjes geregeld

Volgens mij ben ik dan goed bezig.

Inderdaad.

Om jezelf verder in te dekken:
- kijk naar de aard van de persoonsgegevens die je verwerkt en bepaal of de toegepaste beveiliging daarmee in overeenstemming is (zijn de getroffen maatregelen passend).
- Geef bij de opdrachtgever aan welke maatregelen je hebt getroffen en dat je bij uitblijven van reactie binnen x-termijn ervan uitgaat dat zij akkoord zijn.
- Geef bij opdrachtgever aan hoe jij omgaat met eventuele datalekken en dat jij die meldt bij opdrachtgever.
- Wees zo duidelijk mogelijk naar klanten welke persoonsgegevens verwerkt worden en waarom en verwijs expliciet naar de opdrachtgever.
- Geef bij opdrachtgever aan dat zij verantwoordelijk zijn voor de informatie naar betrokkenen (transparantiebeginsel) en het met jou maken van afspraken over afhandelen van beveiligingsincidenten / datalekken.

En het lijkt mij verstandig om dit niet via mail te doen, maar via aangetekende post.

jfeelders schreef op dinsdag 22 mei 2018 @ 18:55:
Volgens mij is het toch zo dat in de AVG (ten opzichte van de WBP) de verantwoordelijkheid voor het goed omgaan met persoonsgegevens bij zowel de verwerkingsverantwoordelijke als de verwerker ligt? De verantwoordelijke moet zorgen dat alles netjes geregeld is maar als er een datalek is dan kan de verwerker ook verantwoordelijk worden gehouden. Als de verwerkingsverantwoordelijke geen passende maatregelen treft moet de verwerker zijn verantwoordelijkheid afkaarten.

Correct. De AVG introduceert een aansprakelijkheidsprincipe voor verwerkers voor non-compliance ten aanzien van de werkzaamheden die voor een verwerkingsverantwoordelijke worden uitgevoerd.

[ Voor 53% gewijzigd door Killjoy op 23-05-2018 01:52 ]

[Verwijderd]

jfeelders schreef op dinsdag 22 mei 2018 @ 18:55:
Volgens mij is het toch zo dat in de AVG (ten opzichte van de WBP) de verantwoordelijkheid voor het goed omgaan met persoonsgegevens bij zowel de verwerkingsverantwoordelijke als de verwerker ligt? De verantwoordelijke moet zorgen dat alles netjes geregeld is maar als er een datalek is dan kan de verwerker ook verantwoordelijk worden gehouden. Als de verwerkingsverantwoordelijke geen passende maatregelen treft moet de verwerker zijn verantwoordelijkheid afkaarten.

Dat klopt, maar als de verwerker bijvoorbeeld security updates zou moeten doen voor een website die hij 15 jaar geleden heeft gemaakt, terwijl de verantwoordelijke weigert daar voor te betalen lijkt het me toch dat de verantwoordelijke in gebreke blijft. Niemand kan verwachten dat voor een projectje voor de sportclub eindeloos en gratis support wordt geleverd.

[jfeelders]

Dat is dan het gedeelte "Als de verwerkingsverantwoordelijke geen passende maatregelen treft moet de verwerker zijn verantwoordelijkheid afkaarten." Om, als het zo ver komt, niet verantwoordelijk gesteld te kunnen worden. Kwestie van 1 brief/document naar de verwerkingsverantwoordelijke.

[Verwijderd]

Vraagje. Als een klant een organisatie de opdracht geeft om zijn/haar persoonsgegevens te verwijderen, moet de organisatie de klant dan hiervan op de hoogte stellen zodra dit is gebeurd?

[Killjoy]

Verwijderd schreef op vrijdag 25 mei 2018 @ 18:13:
Vraagje. Als een klant een organisatie de opdracht geeft om zijn/haar persoonsgegevens te verwijderen, moet de organisatie de klant dan hiervan op de hoogte stellen zodra dit is gebeurd?

Ja. Zie AVG artikel 19

[Verwijderd]

Killjoy schreef op vrijdag 25 mei 2018 @ 18:58:
[...]

Ja. Zie AVG artikel 19

Dank u.

[Cobb]

Mijn zusje heeft een eigen website (http://crealetters.nl/).

Mensen doen bij haar kleine bestellingen, waarvoor zij hun persoonsgegevens verwerkt. Ze bewaart de gegevens van haar klanten niet, maar kan ook niet aantonen dat ze dat niet doet. Ze heeft ook geen nieuwsbrief of ites CRM achtigs.
Het is maar een kleine bijverdienste. Zou ze voldoen aan de wet als ze op de website aangeeft wat ze doet met de ontvangen persoonsgegevens?

[ThaStealth]

Ik heb natuurlijk zoals zovelen mailtjes gekregen ivm veranderende privacy voorwaardes. Meteen een goed moment om alle accounts eens op te schonen.
Ik kreeg er ook eentje van Wehkamp, meteen een mailtje teruggestuurd dat ze mijn gegevens mogen verwijderen

Hier kreeg ik weer als antwoord op dat ik dit zelf kon doen via hun portal, en dat als ze dat voor mij moesten doen ik maar een kopie van mijn ID moest sturen (foto en BSN doorhalen)... Hier ben ik natuurlijk niet erg happy mee, ik wil juist minder persoonsgegevens, niet meer...
Mag een klantenservice hierom vragen?

[F_J_K]

@Cobb ik mag hopen dat ze wel gegevens bewaart, namelijk de financiële administratie. Dus niet toezeggen dat alles wordt verwijderd. Maar inderdaad, aangeven dat wordt verwijderd (minuut na verzenden? Binnen maand of jaar?), muv de gegevens die verplicht zijn te bewaren (die verwijderen na 7 jaar?) Toestemming is niet nodig als alleen gebruikt voor uitvoer vd koopovereenkomst.

-

@ThaStealth verifiëren wie heeft verzocht te verwijderen lijkt me valide. Immers is ten onrechte (als iemand doet alsof door jou wordt gemaild) vernietigen niet de bedoeling. Je kunt vast wel vragen wat ze met de kopie doen en hoe snel die wordt verwijderd.

[ Voor 6% gewijzigd door F_J_K op 26-05-2018 11:44 ]

[Adr01]

Ik heb een vraagje, en ik heb niet het idee dat ik het onder "Tweakers Feedback" kwijt zou kunnen.

Voldoet Tweakers zelf wel aan de GDPR-wet?

Ik heb geen mogelijkheid om ergens cookies te weigeren. En ik heb het hier uiteraard over de niet functionele cookies zoals analytics an advertentie gerelateerde cookies.

Een anonieme analytics mag volgens mij, ik weet alleen niet zeker of Tweakers het geanonimiseerde analytics gebruikt?
Maar ook die gegevens zijn eigenlijk na een tijd te koppelen aan een gebruiker. (In theorie, met een beetje kans berekening) Nu is dit niet echt het probleem.

Maar de rest van de cookies welke met advertenties/marketing te maken hebben zullen toch echt een opt-out horen te krijgen? (Eigenlijk mogen deze niet standaard ingesteld zijn, en moet de gebruiker actief een opt-in uitvoeren)

Bij het niet accepteren van de regeling bij de cookiewall mag je de site niet op. En huidige gebruikers krijgen geen melding over de keuze op het moment. Naast dat je geen dienst mag weigeren als statistische of marketing cookies niet worden geaccepteerd door de gebruiker, is er geen actief consent geweest voor bestaande gebruikers die de site al eerder bezocht hebben.

Nu is het mogelijk dat er niets noemenswaardigs is veranderd aan de cookie/privacy regeling op Tweakers, maar dat moet dus wel gebeuren volgens mijn interpretatie van deze wetgeving.

Als dit meer een vraag is om over de mail te stellen dan ga ik dat doen. Maar ik hoor graag de mening/gedachtegang van anderen hierover.

[F_J_K]

Adr01 schreef op zaterdag 26 mei 2018 @ 15:31:
Ik heb een vraagje

Die vraag loopt al in LA: Voldoet Tweakers.net niet aan AVG/GDPR?

[WhatsappHack]

Had net een interessante situatie. Mensen moeten consent geven voor marketing mail naast functionele mail. Nu stond er in een aankondiging mail (bij een kleine groep klanten was de box door een bug per ongeluk al vooraf aangevinkt, dus die groep vroegen we opnieuw een opt-in te doen als ze dat willen) met een knop waarmee ze consent kunnen geven en dus een opt-in doen.

Bij een van de klanten heeft de virusscanner die link “aangeklikt” en een opt-in gedaan.
Ik ben benieuwd in hoeverre je daar als bedrijf de schuld van kan krijgen dat er dan geen bewuste consent is gegeven, je kan er weinig aan doen dat hun scanner dat doet. Lijkt me ook lastig zo’n scanner die links volgt, als ie dat ook met unsubscribe links doet dan blijft t lekker stil in je mailbox maar krijg je ook niet wat je wellicht juist wél wilde zien.

[ Voor 11% gewijzigd door WhatsappHack op 01-06-2018 00:55 ]

[Orion84]

WhatsappHack schreef op vrijdag 1 juni 2018 @ 00:52:
Had net een interessante situatie. Mensen moeten consent geven voor marketing mail naast functionele mail. Nu stond er in een aankondiging mail (bij een kleine groep klanten was de box door een bug per ongeluk al vooraf aangevinkt, dus die groep vroegen we opnieuw een opt-in te doen als ze dat willen) met een knop waarmee ze consent kunnen geven en dus een opt-in doen.

Bij een van de klanten heeft de virusscanner die link “aangeklikt” en een opt-in gedaan.
Ik ben benieuwd in hoeverre je daar als bedrijf de schuld van kan krijgen dat er dan geen bewuste consent is gegeven, je kan er weinig aan doen dat hun scanner dat doet. Lijkt me ook lastig zo’n scanner die links volgt, als ie dat ook met unsubscribe links doet dan blijft t lekker stil in je mailbox maar krijg je ook niet wat je wellicht juist wél wilde zien.

Kwestie van die link naar een pagina laten gaan waar je nog op een knop moet drukken, in plaats van het openen van die link direct beschouwen als consent / unsubscribe?

[wrcveen]

Ik heb de Google Analytics aan de AVG aangepast. Ik heb IP adres op anonimiseren gezet in header code op mijn website. Nu schijn je ook al die vinkjes in Analytics > property's uit te moeten zetten en de vinkjes bij remarketing.

Maar als het IP adres al anoniem is wat heeft Google er dan aan met deze functies? Ik wil die eigenlijk aan laten staan.

Ik wil namelijk meteen Analytics laten weten dat er een bezoeker is op de site (AVG compliant) en dan na een cookie melding waarop men voor akkoord kan klikken, Analytics nog een keer geladen wordt maar dan niet anoniem met al de functies onder die vinkjes. Als ze dan niet op akkoord klikken is het bezoek in ieder geval wel anoniem geregistreerd. Wat is jullie advies?

[ Voor 23% gewijzigd door wrcveen op 08-06-2018 12:51 ]

[Demonitzu]

De IP-adressen zijn niet helemaal anoniem, alleen de laatste octet wordt veranderd naar 0. Grote bedrijven en scholen zijn in dat geval niet anoniem, omdat zij intern alle octetten behalve het laatste octet met elkaar delen. Volgens het AP is dit feitelijk nog steeds een persoonsgegeven.

Als je de functies van het delen aan laat staan, dan is Google net als jou een verantwoordelijke en niet slechts alleen de bewerker. Volgens mij mag dit wel als je van tevoren toestemming aan de bezoeker vraagt, maar ik denk niet dat het technisch mogelijk is om bijvoorbeeld dit via een aanpassing in het javascript weer aan te zetten.

[Verwijderd]

Toshin schreef op vrijdag 8 juni 2018 @ 19:22:
De IP-adressen zijn niet helemaal anoniem, alleen de laatste octet wordt veranderd naar 0. Grote bedrijven en scholen zijn in dat geval niet anoniem, omdat zij intern alle octetten behalve het laatste octet met elkaar delen. Volgens het AP is dit feitelijk nog steeds een persoonsgegeven.

Sinds wanneer is een school of een bedrijf een privaat persoon?
Het is niet mogelijk om iemand specifiek in de school aan te wijzen met enkel het IP adres. Ik zie het probleem niet.

[kodak]

Bij een van de klanten heeft de virusscanner die link “aangeklikt” en een opt-in gedaan.
Ik ben benieuwd in hoeverre je daar als bedrijf de schuld van kan krijgen dat er dan geen bewuste consent is gegeven, je kan er weinig aan doen dat hun scanner dat doet.

Het doel van de wetgever is dat je als aanbieder de plicht hebt om alleen gegevens te verwerken waarvoor je toestemming hebt gekregen. Die toestemming moet door de klant ook bewust genoeg gekozen zijn. Het middel of de tekst om die keuze te krijgen staat hier niet ter discussie, dus gaat het om de verantwoordelijkheid en invloed. Als de klant zelf aan geeft dat het zijn eigen virusscanner was dan is dat zijn eigen verantwoordelijkheid dat de software van de klant het antwoord heeft aangepast. Zelfs al doet de software (of voor het zelfde gemak mitm malware) het onbewust voor de klant, het gebeurt in de omgeving waar hij keuzes maakt of heeft gemaakt op bepaalde risico's.

Een manier om het risico op dit onbewust handelen te voorkomen is om de keuze meteen als bevestiging terug te sturen naar de klant. Zo valt achteraf ook moeilijk door een klant te beweren dat die niet kon weten dat de bewuste keuze toch minder bewust zou zijn.

[Verwijderd]

kodak schreef op dinsdag 12 juni 2018 @ 14:04:
[...]

Het doel van de wetgever is dat je als aanbieder de plicht hebt om alleen gegevens te verwerken waarvoor je toestemming hebt gekregen. Die toestemming moet door de klant ook bewust genoeg gekozen zijn. Het middel of de tekst om die keuze te krijgen staat hier niet ter discussie, dus gaat het om de verantwoordelijkheid en invloed. Als de klant zelf aan geeft dat het zijn eigen virusscanner was dan is dat zijn eigen verantwoordelijkheid dat de software van de klant het antwoord heeft aangepast. Zelfs al doet de software (of voor het zelfde gemak mitm malware) het onbewust voor de klant, het gebeurt in de omgeving waar hij keuzes maakt of heeft gemaakt op bepaalde risico's.

Een manier om het risico op dit onbewust handelen te voorkomen is om de keuze meteen als bevestiging terug te sturen naar de klant. Zo valt achteraf ook moeilijk door een klant te beweren dat die niet kon weten dat de bewuste keuze toch minder bewust zou zijn.

Zag dit topic nu pas, maar er staan nogal wat misvattingen in over de AVG.
Zo wordt er nogal op toestemming gehamerd, terwijl dit van de 6 mogelijke verwerkingsgrondslagen de minst wenselijke is.
Het is dus zeker geen doel van de wetgever dat je overal toestemming voor hebt. Sterker nog, de wetgever en adviserende organen pleiten juist ervoor deze grondslag enkel te gebruiken als er geen andere grondslag mogelijk is.
En in veel gevallen kun je beter gerechtvaardigd belang gebruiken dan toestemming.

Ook is er niet altijd noodzaak voor expliciete toestemming, maar wel van ondubbelzinnige toestemming.
Dat zijn weer verschillende zaken.

Wat het voorbeeld van die virusscanner betreft, dat is toch het probleem van de betrokkene?
De verwerkende partij kan aantonen dat hij toestemming heeft gekregen door de logbestanden aan te leveren (aangevinkt op....tijd en datum). De betrokkene zal dit ontkennen, maar kan simpelweg zijn toestemming intrekken als het goed ingeregeld is bij de verantwoordelijke.
Overigens vind ik het een enorm vreemd verhaal van die virusscanner, maar dat terzijde.

[Killjoy]

Verwijderd schreef op dinsdag 7 augustus 2018 @ 11:00:
[...]

Zag dit topic nu pas, maar er staan nogal wat misvattingen in over de AVG.
Zo wordt er nogal op toestemming gehamerd, terwijl dit van de 6 mogelijke verwerkingsgrondslagen de minst wenselijke is.
Het is dus zeker geen doel van de wetgever dat je overal toestemming voor hebt. Sterker nog, de wetgever en adviserende organen pleiten juist ervoor deze grondslag enkel te gebruiken als er geen andere grondslag mogelijk is.
En in veel gevallen kun je beter gerechtvaardigd belang gebruiken dan toestemming.

Ook is er niet altijd noodzaak voor expliciete toestemming, maar wel van ondubbelzinnige toestemming.
Dat zijn weer verschillende zaken.

Het is een verzameltopic geworden. Het gebruik van de verschillende grondslagen wordt een aantal keren benoemd.

Overigens begon dit topic met een verwijzing naar Salesforce. Die hebben nu een datalek.

[CAPSLOCK2000]

Verwijderd schreef op dinsdag 7 augustus 2018 @ 11:00:
Zo wordt er nogal op toestemming gehamerd, terwijl dit van de 6 mogelijke verwerkingsgrondslagen de minst wenselijke is.
Het is dus zeker geen doel van de wetgever dat je overal toestemming voor hebt. Sterker nog, de wetgever en adviserende organen pleiten juist ervoor deze grondslag enkel te gebruiken als er geen andere grondslag mogelijk is.
En in veel gevallen kun je beter gerechtvaardigd belang gebruiken dan toestemming.

"Wenselijk" en "beter" voor wie? Vanuit het oogpunt van een organisatie is toestemming vragen inderdaad maar lastig. Het is een stuk prettiger als je gewoon je gang kan gaan zonder toestemming te vragen.

Een andere insteek is dat we eigenlijk tegen dit gedrag zijn met een paar uitzonderingen, zoals een gerechtvaardigd belang. Toestemming vragen is de 'escape'. Als er geen enkele goede reden is om gegevens te verzamelen kun je het altijd nog doen zonder goede reden door de gebruiker om toestemming te vragen. Dat vind de wetgever niet wenselijk maar je kan het je burgers ook niet verbieden.

Het is maar vanuit welke invalshoek je er naar kijkt.

[kodak]

Verwijderd schreef op dinsdag 7 augustus 2018 @ 11:00:
Zag dit topic nu pas, maar er staan nogal wat misvattingen in over de AVG.
Zo wordt er nogal op toestemming gehamerd, terwijl dit van de 6 mogelijke verwerkingsgrondslagen de minst wenselijke is.

Dan lees ik graag waaruit een volgorde van wenselijkheid valt op te maken. De wetgever heeft geen volgorde aangegeven. Of er een grondslag bestaat en welke grondslag(en) van toepassing zijn hangt van de situatie af.Het is uiteraard voor te stellen dat er nogal wat partijen zijn die liever persoonsgegevens van derden verwerken op basis van een ander belang dan ondubbelzinige toestemming. Bijvoorbeeld doordat een (zelfgeclaimed) gerechtvaardigd belang juridisch aantrekkelijker lijkt om extra doelen zoals marketing mogelijk te maken. Of omdat het juridisch niet aantrekkelijk is dat ondubbelzinnige toestemming een eis is waar je op afgerekend kan worden als je het niet kan bewijzen. Ondubbelzinnig is immers geen lichte term.

Wat het voorbeeld van die virusscanner betreft, dat is toch het probleem van de betrokkene?
De verwerkende partij kan aantonen dat hij toestemming heeft gekregen door de logbestanden aan te leveren (aangevinkt op....tijd en datum). De betrokkene zal dit ontkennen, maar kan simpelweg zijn toestemming intrekken als het goed ingeregeld is bij de verantwoordelijke.

Ik zie niet in waarom het onjuist verwerken van persoonsgegevens hier enkel het probleem van de betrokkene zou zijn en niet van de verwerker. Zoals ik het specifieke geval lees is de situatie dat de verwerker zelf een keuze maakt om middels het voorleggen van een expliciete keuze toestemming vraagt voor een specifieke verwerking. Dat maakt ook dat de verwerker dan moet kunnen onderbouwen waaruit blijkt dat het ontvangen antwoord representatief is voor de keuze van de betrokkene. Dat een betrokkene het recht heeft om een eerdere keuze te wijzigen is geen reden om het alleen een probleem van de betrokkene te maken. Je kan er als verwerker op afgerekend worden.

[Killjoy]

kodak schreef op dinsdag 7 augustus 2018 @ 14:08:
[...]
Dan lees ik graag waaruit een volgorde van wenselijkheid valt op te maken. De wetgever heeft geen volgorde aangegeven. Of er een grondslag bestaat en welke grondslag(en) van toepassing zijn hangt van de situatie af.Het is uiteraard voor te stellen dat er nogal wat partijen zijn die liever persoonsgegevens van derden verwerken op basis van een ander belang dan ondubbelzinige toestemming. Bijvoorbeeld doordat een (zelfgeclaimed) gerechtvaardigd belang juridisch aantrekkelijker lijkt om extra doelen zoals marketing mogelijk te maken. Of omdat het juridisch niet aantrekkelijk is dat ondubbelzinnige toestemming een eis is waar je op afgerekend kan worden als je het niet kan bewijzen. Ondubbelzinnig is immers geen lichte term.

In de context van de voorwaarden die gelden bij verwerking op basis van het toestemmingsvereiste, is toestemming inderdaad de vluchtstrook. Kijk daarbij niet alleen naar de artikelen van de AVG, maar ook naar de overwegingen. Zo moet toestemming vrij gegeven kunnen worden. Inhouden of intrekken van toestemming mag geen negatieve gevolgen hebben voor de betrokkene, er mag geen gezagsverhouding bestaan tussen de betrokkene en de beoogd verwerker, er dient een administratie van gegeven en ingetrokken toestemming te worden bijgehouden, enz.

Verder is de afweging ook cultureel bepaald. In Duitsland wordt meer waarde gegeven aan de grondslag 'toestemming'.

[Verwijderd]

Wat @Killjoy zegt. Als je een beetje inleest in de materie is er een algemeen consensus dat toestemming gewoon een ontzettende vervelende verwerkingsgrond is en dat heeft niks te maken met de betrokkenen inderdaad. Maar dat is ook helemaal niet relevant! Want als je een andere grondslag hebt dan volg je de AVG immers en handel je niet in strijd met de AVG.
Zoals het door @kodak en @CAPSLOCK2000 gebracht wordt ga je bijna uit van misbruik zodra je niet met toestemming werkt en wordt de privacy geschonden. Maar zo werkt het niet. Bedrijven die misbruik maken en niet conform AVG handelen misbruiken toestemming even hard als de andere grondslagen.
Expliciete toestemming is enkel nodig bij risicovolle gegevens, waaronder de artikel 9 categorieën. Impliciete handelingen (zoals poseren) zijn dan meestal onvoldoende.
Toestemming is dus de minst wenselijke, (met de toevoeging) als er ook een andere grondslag mogelijk is. Je kunt namelijk ook later niet meer even wisselen van grondslag. Als je toestemming hebt gekozen zit je daar aan vast.

kodak schreef op dinsdag 7 augustus 2018 @ 14:08:
Ik zie niet in waarom het onjuist verwerken van persoonsgegevens hier enkel het probleem van de betrokkene zou zijn en niet van de verwerker. Zoals ik het specifieke geval lees is de situatie dat de verwerker zelf een keuze maakt om middels het voorleggen van een expliciete keuze toestemming vraagt voor een specifieke verwerking. Dat maakt ook dat de verwerker dan moet kunnen onderbouwen waaruit blijkt dat het ontvangen antwoord representatief is voor de keuze van de betrokkene. Dat een betrokkene het recht heeft om een eerdere keuze te wijzigen is geen reden om het alleen een probleem van de betrokkene te maken. Je kan er als verwerker op afgerekend worden.

Omdat de verantwoordelijkheid van de verwerkingsverantwoordelijke grenzen heeft. Als je dochter van 10 jouw gegevens correct invult en toestemming verleent voor verwerking dan mag je daar als verantwoordelijke even hard op vertrouwen als dat een virusscanner een box aantikt.
De verwerkingsverantwoordelijke kunt prima aantonen waar en wanneer je toestemming verkregen hebt, dat er aan de verlenende kant iets fout gaat komt niet voor rekening van de ontvangende kant. Die heeft netjes de toestemming gedocumenteerd en stopt de verwerking als deze ingetrokken wordt.
Onderbouwen dat een antwoord representatief is gaat maar zo ver. Anders kan iedereen zeggen dat toestemming nooit verleend is, terwijl dit juist wel het geval is. Wat wil je meer dan je toestemming documenteren inclusief aangeleverde gegevens? De WP29 documentatie over toestemming is heel duidelijk dat de verantwoordelijke moet kunnen aantonen toestemming ontvangen te hebben op een correcte wijze, als het voor de verantwoordelijke onmogelijk is om te controleren wie dan het vakje aankruist (minderjarige of virusscanner) en het technisch onredelijk bezwarend is om dat te verhinderen (onmogelijk met een minderjarige die falsifieert nagenoeg) dan houdt het op.
Er is dus geen sprake van onjuist verwerken waar de verantwoordelijke schuldig aan is. In het hele privacy debat is er continue een belangenafweging. Die afweging zal met de nieuwe wetgeving vaker en sneller in het voordeel van de betrokkene uitpakken, maar die rechten zijn ook niet ongelimiteerd. Verre van zelfs. Daarom is het intrekken van toestemming ook niet met terugwerkende kracht en heeft het soms geen effect als iets bijvoorbeeld gepubliceerd is.
Je verwerkt dus ook niet onjuist gegevens, maar je toestemming is (naar blijkt) verkeerd verkregen buiten je weten en mogelijkheden om.

Over het culturele dat klopt heel erg! Wel apart voor een Europese regeling die eenheid moet scheppen, maar zo is het. Gerechtvaardigd belang wordt veel mee aangegrepen in de noordelijke lidstaten dan in de zuidelijke. In Italië moet je zelfs gerechtvaardigd belang bij de toezichthouder laten goedkeuren......ondoenlijk.

[kodak]

Verwijderd schreef op dinsdag 7 augustus 2018 @ 15:29:
Zoals het door @kodak en @CAPSLOCK2000 gebracht wordt ga je bijna uit van misbruik zodra je niet met toestemming werkt en wordt de privacy geschonden.

Ik kan niet voor @CAPSLOCK2000 spreken, maar mijn opmerkingen gaan over de situatie waar de toestemming de grondslag is. Ruimer interpreteren heeft geen zin, tenzij je perse overal tegen aan wil schoppen.


[...]

Omdat de verantwoordelijkheid van de verwerkingsverantwoordelijke grenzen heeft. ...
Onderbouwen dat een antwoord representatief is gaat maar zo ver. Anders kan iedereen zeggen dat toestemming nooit verleend is, terwijl dit juist wel het geval is. Wat wil je meer dan je toestemming documenteren inclusief aangeleverde gegevens? De WP29 documentatie over toestemming is heel duidelijk dat de verantwoordelijke moet kunnen aantonen toestemming ontvangen te hebben op een correcte wijze, als het voor de verantwoordelijke onmogelijk is om te controleren wie dan het vakje aankruist (minderjarige of virusscanner) en het technisch onredelijk bezwarend is om dat te verhinderen (onmogelijk met een minderjarige die falsifieert nagenoeg) dan houdt het op.

De Nederlandse wetgever heeft de wettekst over de toestemming grondslag geformuleerd met onderandere het woord ondubbelzinnig. De tekst slaat zowel op de toestemming als wie het gegeven heeft. Bij ondubbelzinnige toestemming moet elke twijfel zijn uitgesloten. Het moet dus volstrekt duidelijk zijn òf de betrokkene toestemming heeft gegeven. Maar ook dat het door de betrokkene is gegeven. De eerste casus waaruit zou blijken dat men dan ook kan volstaan met een situatie waarbij met minder, dus met twijfel, kan worden volstaan moet nog komen. Tot die tijd lijkt het mij juridisch onverantwoord om er gemakshalve vanuit te gaan dat de uitleg van ondubbelzinnig met minder toe kan en ook onverantwoord om aan te nemen dat het alleen zou slaan op het deel dat doestemming is gegeven. Dat het naar mening van de verwerker onwerkbaar zou zijn om elke twijfel uit te sluiten is het risico voor de verwerker.

[Verwijderd]

De Nederlandse wetgever heeft simpelweg ondubbelzinnig overgenomen van de vertaling van de AVG. De voormalige WP29 is verder heel duidelijk over het begrip en hoe te interpreteren. Inclusief hoe ver de verantwoordelijkheid reikt. En er wordt niet van de verwerkingsverantwoordelijke verwacht dat je onwerkbare situaties werkbaar maakt. Oftewel, ook al is dat risico voor de verwerkingsverantwoordelijke, het is een acceptabel en te nemen risico. De AVG geeft zelfs aan dat ondoenlijke situaties de uitzondering is die toegestaan is. Het moet werkbaar blijven en dat wordt erkend. Met veranderende technieken kan onwerkbaar weer werkbaar worden en dat moet je goed in de gaten houden als verantwoordelijke.

[Killjoy]

Over het culturele dat klopt heel erg! Wel apart voor een Europese regeling die eenheid moet scheppen, maar zo is het. Gerechtvaardigd belang wordt veel mee aangegrepen in de noordelijke lidstaten dan in de zuidelijke. In Italië moet je zelfs gerechtvaardigd belang bij de toezichthouder laten goedkeuren......ondoenlijk.

Dit was in Italië zo geregeld onder de lokale implementatie van de Richtlijn 95/46/EG. Maar nu niet meer

kodak schreef op woensdag 8 augustus 2018 @ 00:55:

De Nederlandse wetgever heeft de wettekst over de toestemming grondslag geformuleerd met onderandere het woord ondubbelzinnig. De tekst slaat zowel op de toestemming als wie het gegeven heeft. Bij ondubbelzinnige toestemming moet elke twijfel zijn uitgesloten. Het moet dus volstrekt duidelijk zijn òf de betrokkene toestemming heeft gegeven. Maar ook dat het door de betrokkene is gegeven. De eerste casus waaruit zou blijken dat men dan ook kan volstaan met een situatie waarbij met minder, dus met twijfel, kan worden volstaan moet nog komen. Tot die tijd lijkt het mij juridisch onverantwoord om er gemakshalve vanuit te gaan dat de uitleg van ondubbelzinnig met minder toe kan en ook onverantwoord om aan te nemen dat het alleen zou slaan op het deel dat doestemming is gegeven. Dat het naar mening van de verwerker onwerkbaar zou zijn om elke twijfel uit te sluiten is het risico voor de verwerker.

Verwijderd schreef op woensdag 8 augustus 2018 @ 06:35:
De Nederlandse wetgever heeft simpelweg ondubbelzinnig overgenomen van de vertaling van de AVG. De voormalige WP29 is verder heel duidelijk over het begrip en hoe te interpreteren. Inclusief hoe ver de verantwoordelijkheid reikt. En er wordt niet van de verwerkingsverantwoordelijke verwacht dat je onwerkbare situaties werkbaar maakt. Oftewel, ook al is dat risico voor de verwerkingsverantwoordelijke, het is een acceptabel en te nemen risico. De AVG geeft zelfs aan dat ondoenlijke situaties de uitzondering is die toegestaan is. Het moet werkbaar blijven en dat wordt erkend. Met veranderende technieken kan onwerkbaar weer werkbaar worden en dat moet je goed in de gaten houden als verantwoordelijke.

Ondubbelzinnige toestemming heeft primair betrekking op de wijze waarop de toestemming wordt verkregen. Het moet voor betrokkene volledig transparant zijn waarvoor deze toestemming verleent. Uit de wijze waarop de betrokkene de toestemming verleent, moet blijken dat het een bewuste handeling is. Dus een klink op een link mag niet, een vinkbox wel; mits deze niet vooringevuld is. Ook moet de verwerkingsverantwoordelijke kunnen aantonen dat de betrokkene dit heeft gedaan. Dus dat vereist ook een administratie.

De wetgever laat meer ruimte voor wat betreft het controleren van de identiteit van de betrokkene. Er wordt gesproken over alle redelijke maatregelen. Dat betekent dat de verwerkingsverantwoordelijke een risicoafweging moet maken van wat in de context van de betreffende verwerking, als redelijk wordt geacht.

[Verwijderd]

Killjoy schreef op woensdag 8 augustus 2018 @ 11:31:
[...]

Dit was in Italië zo geregeld onder de lokale implementatie van de Richtlijn 95/46/EG. Maar nu niet meer


[...]


[...]


Ondubbelzinnige toestemming heeft primair betrekking op de wijze waarop de toestemming wordt verkregen. Het moet voor betrokkene volledig transparant zijn waarvoor deze toestemming verleent. Uit de wijze waarop de betrokkene de toestemming verleent, moet blijken dat het een bewuste handeling is. Dus een klink op een link mag niet, een vinkbox wel; mits deze niet vooringevuld is. Ook moet de verwerkingsverantwoordelijke kunnen aantonen dat de betrokkene dit heeft gedaan. Dus dat vereist ook een administratie.

De wetgever laat meer ruimte voor wat betreft het controleren van de identiteit van de betrokkene. Er wordt gesproken over alle redelijke maatregelen. Dat betekent dat de verwerkingsverantwoordelijke een risicoafweging moet maken van wat in de context van de betreffende verwerking, als redelijk wordt geacht.

Grappig, de Italiaanse advocaat die ik hierover sprak meldde dit ook in februari/maart. Toen was die wijziging nog niet erdoor vermoed ik.
Redelijkheid moet je zelf weer kunnen verdedigen, dus discussie zal er altijd zijn. Boetes zie ik dan wel veel minder snel komen, eerder een aanbeveling.

[Madshark]

Sommige PC games hebben anti-cheat software, dat in je PC geheugen gaat graven naar bepaalde processen of raw data. Deze informatie wordt vervolgens doorgestuurd naar het 'hoofdkantoor'.
Nu vroeg ik me af, gezien dit informatie is wat duidelijk gekoppeld is aan jouw als persoon, of deze info ook op te vragen valt onder AVG/GDPR wetgeving ?
Want eigenlijk ben ik wel benieuwd welke informatie ze allemaal aan het vergaren zijn.

[ Voor 3% gewijzigd door Madshark op 18-10-2018 02:19 ]

[F_J_K]

Als de gegevens aan jou zijn te relateren (of jouw PC, jouw spel-serienummer, jouw IP-adres, etc): ja. En dat je dat recht hebt moeten ze je zelf al hebben verteld op hun website / in de voorwaarden als het spel van na mei 2018 is dan. Maar als het goed is hebben ze weinig info daarover, omdat het wordt verwijderd zodra bleek dat je niet hebt gecheat in die sessie.

https://store.steampowered.com/privacy_agreement/ bijvoorbeeld beschrijft (zo op het eerste gezicht) beide keurig. Maar je zou dus een verzoek kunnen doen en specifiek vragen om alles dat ze hebben rond de anti-cheat.

offtopic:
Waarbij ik me kan voorstellen dat er voortaan een vlaggetje bij je naam gaan staan als iemand die potentieel cheat of cheat-tools maakt

[Chris_147]

Hallo, ook enkele vragen ivm GDPR:

- ik geef trainingen, voor KMO Portefeuille moet ik aanwezigheidslijsten, certificaten, evaluaties, facturen en dergelijke 10 jaar bewaren. Wat moet ik doen als die persoon dat niet wil? Lijsten, evaluaties en certificaten anonymiseren (regel van persoon zwart maken?)
Moet ik dan alle emailwisseling met die persoon ook verwijderen?

- ik gebruik Matomo (piwik) op mijn website om bezoek een beetje op te volgen. Is er overzicht hoe ik dat moet instellen om in orde te zijn met de GDPR?

[Peatsmoke]

Hoe voert ze dan een sluitende administratie?
Je zult toch ergens iets moeten bijhouden van bestellingen, al is het maar omdat je ook naar De Belastingdienst zaken moet kunnen aantonen.

oude reactie

[ Voor 41% gewijzigd door Peatsmoke op 15-12-2018 07:32 ]

[F_J_K]

@Chris_147 1. van wie moet je het 10 jaar bewaren? Een wet, het contract tussen jou en de betrokkene, je eigen verwerkingsregister/privacyverklaring? Dat maakt uit voor het antwoord. Zo ook: op basis waarvan verwerk je het ueberhaupt: een overeenkomst, toestemming, iets anders? Als toestemming: weg zodra toestemming wordt ingetrokken en je niet een andere grondslag hebt. Als wet: de wet is de wet.

Ik zou denken: zodra jullie de gegevens verwijderen kunnen jullie niet meer verifieren dat het certificaat bij de betreffende persoon hoort en is het certificaat ongeldig.

2. nee. Hangt ook van de details af. Zet geen cookies, vraag geen gegevens, bewaar geen logs, en het is klaar. Zodra je dat wel doet, hangt het er vanaf hoe en wat.

Ik zou voorstellen een eigen topic te openen met meer concrete info. Zo te lezen ben je Belg. https://www.gegevensbesch...bereid-je-voor-13-stappen is een begin.

[Chris_147]

@F_J_K KMO Portefeuille is van de Vlaamse overheid, om daaraan te voldoen voor audits moet ik bewaren, wet dus.
Ivm het certificaat: echt belangrijk is het certificaat niet, het is eigenlijk enkel een aanwezigheidscertificaat, maar de KMO Portefeuille verplicht me wel dat af te leveren. Het echte certificaat krijgt men na een examen van een andere partij.

[jfeelders]

Chris_147 schreef op zaterdag 15 december 2018 @ 07:26:
Hallo, ook enkele vragen ivm GDPR:

- ik geef trainingen, voor KMO Portefeuille moet ik aanwezigheidslijsten, certificaten, evaluaties, facturen en dergelijke 10 jaar bewaren. Wat moet ik doen als die persoon dat niet wil? Lijsten, evaluaties en certificaten anonymiseren (regel van persoon zwart maken?)
Moet ik dan alle emailwisseling met die persoon ook verwijderen?

- ik gebruik Matomo (piwik) op mijn website om bezoek een beetje op te volgen. Is er overzicht hoe ik dat moet instellen om in orde te zijn met de GDPR?

Betreft het niet onderdelen die noodzakelijk zijn voor het uitvoeren van de overeenkomst en dat er dus geen toestemming nodig is?