Algemene verordening gegevensbescherming - GDPR / AVG

Pagina: 1 2 Laatste
Acties:

Onderwerpen


Acties:
  • +2 Henk 'm!

Anoniem: 696166

Topicstarter
In mei volgend jaar wordt deze ingrijpende Algemene verordening gegevensbescherming of General Data Protection Regulation (GDPR) actief. Ik kan me niet voorstellen dat er geen vragen zijn/gaan komen van tweakers die hiermee te maken gaan krijgen. De implicaties van de GDPR zijn potentieel enorm: bij overtredingen kunnen boetes opgelegd worden tot 20 miljoen euro (of 4% van de wereldwijde omzet als dat getal groter is).
Het lijkt me dan ook nuttig om hier een topic over te starten.
Voor alle duidelijkheid: de GDPR gaat niet enkel over IT, maar bijvoorbeeld ook over papieren documenten, bewakingscamera's,...

Een van de zaken die verplicht zijn (en eigenlijk al waren volgens de verschillende nationale wetgevingen) is het informed consent. Om gegevens van een persoon te verwerken moet men kunnen aantonen dat men van die persoon impliciet de toelating heeft gekregen voor de gegevensverwerking.
Nu is mijn vraag: wat met webapplicaties waar gebruikers gegevens invoeren van anderen (bv. een online CRM applicatie). Hoe kan een bedrijf als Salesforce informed consent krijgen van de personen die in hun applicatie worden ingegeven door hun gebruikers?

Acties:
  • 0 Henk 'm!

  • F_J_K
  • Registratie: Juni 2001
  • Niet online

F_J_K

Moderator CSA/PB

Front verplichte underscores

Salesforce is toch slechts de verwerker van de data? Hun klant dient te zorgen dat e.e.a. goed is ingeregeld. Zowel intern (procedures) als richting Salesforce: verwerkersovereenkomst, verifiëren dat Salesforce's developers privacy by design als uitgangspunt hanteren, etc.

En inderdaad, zo goed als alle (werkzame) Tweakers zullen hier mee te maken hebben. Zowel degenen die in of met IT werken als die degenen die met papier werken.

[ Voor 24% gewijzigd door F_J_K op 14-08-2017 12:24 ]

'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind' (Terry Pratchett, Eric)


Acties:
  • 0 Henk 'm!

Anoniem: 696166

Topicstarter
Hallo F_J_K, bedankt voor de input.
Dat klinkt inderdaad logisch, maar ik blijf toch met vragen zitten. Volgens de verordening en bijhorende uitleg is voor het soort data dat typisch in een boekhoudpakket zit (ik veronderstel dat we bij uitbreiding een CRM ook in die categorie mogen zetten) geen Privacy Impact Assessment of "Gegevensbeschermingseffectbeoordeling" nodig, noch expliciete toestemming om deze gegevens op te nemen (immers is er de wettelijke verplichting om deze gegevens bij te houden omwille van boekhoudkundige redenen).
Expliciete toestemming is echter wel nodig bij het delen van gegevens met derden. In deze lijkt salesforce mij de derde partij te zijn waarmee de gegevens gedeeld worden.
Ik ben er zeker van dat de EU niet de hele business van dit soort bedrijven onderuit wil halen met deze verordening, maar hoe moeten wij eenvoudige tweakers hiermee omgaan?

Acties:
  • +1 Henk 'm!

  • Orion84
  • Registratie: April 2002
  • Laatst online: 18:13

Orion84

Admin General Chat / Wonen & Mobiliteit

Fotogenie(k)?

Specifiek voor Salesforce zou je eens kunnen kijken naar wat ze daar zelf over zeggen: https://www.salesforce.co...force-gdpr-july-2017.html

The problem with common sense is that it's not all that common. | LinkedIn | Flickr


Acties:
  • 0 Henk 'm!

Anoniem: 696166

Topicstarter
Hallo Orion84. Die had ik inderdaad ook al gevonden. De info is daar weinig concreet, zoals ook in dit topic op het salesforce forum duidelijk wordt. Men vraagt er duidelijke hulp van het bedrijf, onder meer specifiek over het consent.
Er staat weinig concrete info over waarom ze dan aan de GDPR voldoen en waarom hun klanten zonder problemen informatie over anderen mogen invoeren zonder consent (als dat al zo is, want dat is me niet duidelijk).

Voor alle duidelijkheid: salesforce gebruikte ik enkel als voorbeeld, het gaat me meer om de algemene verplichtingen van de GDPR.

Acties:
  • 0 Henk 'm!

  • Orion84
  • Registratie: April 2002
  • Laatst online: 18:13

Orion84

Admin General Chat / Wonen & Mobiliteit

Fotogenie(k)?

Zoals @F_J_K ook al aangeeft: die consent is iets tussen het bedrijf dat Salesforce gebruikt en de persoon wiens gegevens worden ingevoerd (bijvoorbeeld een klant van dat bedrijf).

Daarnaast moeten er uiteraard afspraken zijn tussen salesforce en de bedrijven die salesforce gebruiken, maar (tenzij ik me ontzettend vergis) hoeft salesforce zelf geen consent te verzamelen voor elk individueel stukje persoonsgegevens dat door bedrijven die salesforce gebruiken worden ingevoerd.

The problem with common sense is that it's not all that common. | LinkedIn | Flickr


Acties:
  • +2 Henk 'm!

  • Killjoy
  • Registratie: November 2000
  • Laatst online: 18:09

Killjoy

Klingon lawn products

Om bij het voorbeeld te blijven. De webapplicaties waar de topicstarter het over heeft, zijn feitelijk diensten die door Salesforce worden aangeboden. Met deze dienst kan een partij persoonsgegevens verwerken ten behoeve van een met een eigen klant gesloten overeenkomst. Dat kan de a-grond zijn (toestemming, of informed consent zoals hier benoemd) maar ook een andere grondslag van de AVG artikel 6, lid 1.

Nu ben ik niet bekend met Salesforce, maar het lijkt mij een aanbieder van SAAS oplossingen. De partij die de dienst bij Salesforce afneemt (klant), is de verwerkingsverantwoordelijke en dient derhalve aan de verplichtingen te voldoen die de AVG aan de verwerkingsverantwoordelijke stelt. Daaronder valt onder andere dat de verwerkingsverantwoordelijke de rechtmatigheid van de verwerking heeft vastgelegd. Salesforce kun je beschouwen als verwerker die in opdracht van de verwerkingsverantwoordelijke persoonsgegevens verwerkt. Salesforce is er niet voor verantwoordelijk om te bepalen of de verwerking rechtmatig is.

Verwerkingsverantwoordelijke moet met verwerker een verwerkersovereenkomst sluiten. Daarin leg je tevens afspraken over wat Salesforce wel en niet mag met de opgeslagen gegevens, meldplicht datalekken, beveiliging, enz.

Natuurlijk heeft Salesforce ook verplichtingen. De diensten moeten ook aan de AVG doen. Bijvoorbeeld verwijdering van gegevens moet mogelijk zijn, privacy by design/default toegepast, passend beveiligd e.d. En Salesforce moet zelf een register van verwerkingen bij moeten houden.

Dat is wat ik uit de topicstart en de reacties van TS kan distilleren. Als je specifiek iets wil weten, vraag het dan ook even specifiek ;)

Het is den ambtenaar verboden gedurende den werktijd alcoholhoudende dranken te gebruiken, bij zich te hebben of in de dienstlokalen te bewaren.


Acties:
  • +2 Henk 'm!

  • F_J_K
  • Registratie: Juni 2001
  • Niet online

F_J_K

Moderator CSA/PB

Front verplichte underscores

Orion84 schreef op maandag 14 augustus 2017 @ 17:07:
Daarnaast moeten er uiteraard afspraken zijn tussen salesforce en de bedrijven die salesforce gebruiken, maar (tenzij ik me ontzettend vergis) hoeft salesforce zelf geen consent te verzamelen voor elk individueel stukje persoonsgegevens dat door bedrijven die salesforce gebruiken worden ingevoerd.
Sterker nog: ze mogen m.i. geen toestemming vragen. Ze mogen immers de persoonsgegevens niet gebruiken om contact met de personen op te nemen voor de toestemming: alleen verwerken voor de doelen die zijn afgesproken met de verantwoordelijke (de klant). Als ik een band heb met het bedrijf van @Anoniem: 696166, zet die mijn gegevens (NAW, jaaromzet, etc) in hun CRM. Dat CRM wordt als SaaS-dienst beheerd door bijv. Salesforce, maar Salesforce mag niets anders met mijn gegevens dan opslaan, backuppen, tonen aan rodolvo, etc.
En ze zullen het na opdracht daartoe door een rechter ook overhandigen aan de overheid. En dat is een reden waarom je heel erg voorzichtig moet zijn met bedrijven met banden buiten (kort gezegd) Europa. Ik ben benieuwd hoe lang de privacy shield standhoudt.

'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind' (Terry Pratchett, Eric)


Acties:
  • 0 Henk 'm!

  • Thralas
  • Registratie: December 2002
  • Laatst online: 16:50
Killjoy schreef op maandag 14 augustus 2017 @ 21:18:
Natuurlijk heeft Salesforce ook verplichtingen.
Je lijkt goed geinformeerd, dus met enig gevaar wil ik toch een puntje aankaarten:
De diensten moeten ook aan de AVG doen. Bijvoorbeeld verwijdering van gegevens moet mogelijk zijn, privacy by design/default toegepast, passend beveiligd e.d. En Salesforce moet zelf een register van verwerkingen bij moeten houden.
Salesforce lijkt me primair een Amerikaans bedrijf, waarmee ze vooral onderhavig zijn aan Amerikaans recht, toch? Als ik zo 1-2-3 door de GDPR-posts van ze klik lijken ze vooral bezorgd om hun klanten en zich te richten op het exporteren van gegevens richting de VS.

Ze moeten al dat soort zaken wel faciliteren om hun klanten uit de EU te kunnen behouden, maar als de data eenmaal bij een Amerkaanse provider staat dan lijkt me dat buiten de reikwijdte van de GDPR te vallen?

Uiteindelijk blijft de verantwoordelijke partij binnen de EU, dus die zullen de verantwoording moeten dragen over de overdracht van persoonsgegevens naar de Salesforce-systemen in de VS.

Acties:
  • 0 Henk 'm!

  • Killjoy
  • Registratie: November 2000
  • Laatst online: 18:09

Killjoy

Klingon lawn products

Thralas schreef op maandag 14 augustus 2017 @ 23:27:

Salesforce lijkt me primair een Amerikaans bedrijf, waarmee ze vooral onderhavig zijn aan Amerikaans recht, toch? Als ik zo 1-2-3 door de GDPR-posts van ze klik lijken ze vooral bezorgd om hun klanten en zich te richten op het exporteren van gegevens richting de VS.

Ze moeten al dat soort zaken wel faciliteren om hun klanten uit de EU te kunnen behouden, maar als de data eenmaal bij een Amerkaanse provider staat dan lijkt me dat buiten de reikwijdte van de GDPR te vallen?

Uiteindelijk blijft de verantwoordelijke partij binnen de EU, dus die zullen de verantwoording moeten dragen over de overdracht van persoonsgegevens naar de Salesforce-systemen in de VS.
Op zich maakt het niet uit of het een Amerikaans bedrijf is of niet. Willen ze zaken doen met Europese bedrijven in Europa, dan moeten ze voldoen aan de AVG. En dus passende waarborgen treffen dat data niet in handen komt van onbevoegden (als de Amerikaanse overheid). Maar inderdaad; dat staat op gespannen voet met de Patriot Act. Als soort van waarborg hebben we 'gelukkig' het Privacy Shield...

Het is den ambtenaar verboden gedurende den werktijd alcoholhoudende dranken te gebruiken, bij zich te hebben of in de dienstlokalen te bewaren.


Acties:
  • +2 Henk 'm!

  • Bomsan
  • Registratie: April 2015
  • Niet online
Anoniem: 696166 schreef op maandag 14 augustus 2017 @ 11:27:

Een van de zaken die verplicht zijn (en eigenlijk al waren volgens de verschillende nationale wetgevingen) is het informed consent. Om gegevens van een persoon te verwerken moet men kunnen aantonen dat men van die persoon impliciet de toelating heeft gekregen voor de gegevensverwerking.
De belangrijkste wettelijke grondslagen voor het verwerken van persoonsgegevens zijn op dit moment uitdrukkelijke toestemming, uitvoeren van een overeenkomst en wettelijke verplichting. De overige (drie) zijn vaker niet dan wel van toepassing. De(ze) grondslagen zijn vrijwel identiek onder de AVG. Een impliciete toestemming is straks echter juist niet (meer) toegestaan onder de AVG. Toestemming moet aantoonbaar worden gegeven, impliciet kan dus niet (meer), zie art 7.1. Hiernaast moet toestemming in eenvoudige en begrijpelijke taal worden gevraagd en altijd kunnen worden ingetrokken. Laatste is ook niet mogelijk bij een impliciete toestemming - als onduidelijk is dat die is gegeven, wat vaak het geval zal zijn.
Nu is mijn vraag: wat met webapplicaties waar gebruikers gegevens invoeren van anderen (bv. een online CRM applicatie). Hoe kan een bedrijf als Salesforce informed consent krijgen van de personen die in hun applicatie worden ingegeven door hun gebruikers?
Expliciete toestemming is echter wel nodig bij het delen van gegevens met derden. In deze lijkt salesforce mij de derde partij te zijn waarmee de gegevens gedeeld worden.
De persoonsgegevens die in een CRM worden ingevoerd, moeten rechtmatig zijn verkregen door de verantwoordelijke. Dat kan op basis van toestemming zijn, meestal echter uitvoering van een overeenkomst. Het plaatsen van die persoonsgegevens in een CRM is het laten verwerken van die persoonsgegevens door een derde. Daarvoor zou dus nu al een verwerkersovereenkomst moeten worden aangegaan met die derde, onder de AVG dus ook. Zoals F_J_K terecht zegt, een bedrijf als Salesforce mag helemaal niets met de persoonsgegevens, anders dan wat is afgesproken - in lijn met het doel waarvoor de persoonsgegevens zijn verstrekt.

De AVG is verder alleen van toepassing op een bedrijf gevestigd buiten de EU als er goederen of diensten worden aangeboden aan betrokkenen in de EU (art 3.2). De AVG is ook van toepassing op vestigingen van een verantwoordelijke of verwerker in de EU die als activiteit het verwerken van persoonsgegevens hebben, ongeacht waar de verwerking plaatsvindt (art 3.1). Dit is bij Salesforce het geval.

Let wel er is m.i. nog (heel) veel onduidelijkheid over toepassing van de AVG, zowel in NL als in de EU. De NL Uitvoeringswet AVG moet bijvoorbeeld nog worden vastgesteld, hierin wordt o.a. de huidige Wet Bescherming Persoonsgegevens ingetrokken. Er zijn al diverse guidelines verschenen van de Article 29 Working Party, met toelichting op onderdelen van de AVG, er volgt er zeker nog een, ik vermoed nog meerdere. Tenslotte zal pas na de datum van toepassing (25 mei 2018) echte duidelijkheid ontstaan, met name op basis van jurisprudentie - en opgelegde boetes.

Toch een goed initiatief dit topic, wel lastig om zo meer helderheid te creëren over complexe wetgeving O-)

Acties:
  • 0 Henk 'm!

Anoniem: 696166

Topicstarter
Bedankt aan alle reageerders voor de interessante reacties.
Ik vind de situatie bijzonder complex (de oorspronkelijk publicatie bevat 99 artikels over 88 pagina's in juridisch jargon).

Ik (en zoals mijn zoektocht mij leerde, velen met mij) zit met veel vragen over de pseudonimisatie, een vage term waar iedereen wel ongeveer van begrijpt wat men bedoelt, maar niemand schijnt te durven zeggen wat er nu concreet moet gebeuren.
Ten eerste is het niet duidelijk of pseudonimisering nu verplicht is of niet. De verordening maakt 15 keer melding van de term maar telkens in dubbelzinnige zinnen. Het is niet duidelijk of het om een veplichting gaat dan wel om een voorbeeld van een goede oplossing ("passende maatregelen, zoals pseudonimisering").
Ik begrijp zelfs uit dit heel interessante artikel dat een EU werkgroep er opheldering over zou moeten leveren, maar dat nog niet gedaan heeft

Als we bij salesforce blijven en we ervan uitgaan dat de pseudonomisering verplicht is: ik veronderstel dat ermee bedoelt wordt dat de persoonsgegevens gescheiden worden van de overige data in salesforce.

De gebruikers van salesforce moeten echter wel het hele plaatje zien waardoor de gegevens terug "ge-de-pseudonimiseerd" worden weergegeven in de applicatie. De meerwaarde is dan toch eerder beperkt?

Wat dient er technisch te gebeuren? Volstaat het om de gebruikersgegevens (geëncrypteerd ongetwijfeld) in een aparte tabel te steken in een andere database zoals ik op de enige website las die met een concrete oplossing komt?
Welke concrete technische oplossingen voldoen aan de definitie die de EU geeft aan pseudonimiseren?

  • Bomsan
  • Registratie: April 2015
  • Niet online
Persoonsgegevens zijn alle gegevens die herleidbaar zijn tot een natuurlijk persoon. De gegevens moeten zijn verkregen voor een specifiek doel. Gegevens mogen verder niet langer worden bewaard dan noodzakelijk.
Als het doel verdwijnt moeten de gegevens in principe ook verdwijnen (hierop zijn echter uitzonderingen). Dit kan door de gegevens te wissen, als dit niet mogelijk of wenselijk is kan het ook door anonymisering of (in mijn ogen, als anonymisering ook niet mogelijk of wenselijk is) door pseudonymisering.

Anonymisering leidt tot onherleidbare gegevens (de naam Jan Jansen wordt veranderd A6% B8*tt$, zonder dat de sleutel wordt bewaard - als die er al is).
Pseudonymisering leidt tot in beginsel onherleidbare gegevens (de naam Jan Jansen wordt gewijzigd in UqH Uqhw3h, de manier van versleuteling wordt bewaard - met zeer beperkte toegang).
Zie ook de overwegingen 26 en 28 van de verordening op p.5 (NL versie).
Anoniem: 696166 schreef op woensdag 16 augustus 2017 @ 16:11:
Ten eerste is het niet duidelijk of pseudonimisering nu verplicht is of niet.
Dat is het zeker niet: het is slechts een middel tot een doel. De verordening is in de basis duidelijk over vereisten: als er staat "moet (...) kunnen aantonen" dan is het een verplichting. Gelukkig (" ") worden hierop vaak uitzonderingen gemaakt. :X
ik veronderstel dat ermee bedoelt wordt dat de persoonsgegevens gescheiden worden van de overige data in salesforce.
De gebruikers van salesforce moeten echter wel het hele plaatje zien waardoor de gegevens terug "ge-de-pseudonimiseerd" worden weergegeven in de applicatie. De meerwaarde is dan toch eerder beperkt?
Zie hiervoor: het gaat om het (zeer) beperkt toegankelijk maken van de pseudonymiseerde gegevens. De meeste gebruikers mogen dan geen toegang meer hebben tot de gegevens. Wellicht is pseudonymisering echter (nog) helemaal niet nodig. Er zijn vele redenen om gegevens langer te bewaren dan voor het doel noodzakelijk is. Zie ook overweging 65 van de verordening en artikel 5 lid 1 onder e (bvb wetenschappelijk of historisch onderzoek, statistische doeleinden of voor vaststelling, uitoefening of onderbouwing van een rechtsvordering).
Wat dient er technisch te gebeuren? Volstaat het om de gebruikersgegevens (geëncrypteerd ongetwijfeld) in een aparte tabel te steken in een andere database zoals ik op de enige website las die met een concrete oplossing komt? Welke concrete technische oplossingen voldoen aan de definitie die de EU geeft aan pseudonimiseren?
Dit is m.i. niet te beantwoorden. Alle omstandigheden waaronder persoonsgegevens worden verwerkt zullen dit bepalen, inclusief de aard van de gegevens. Gewone persoonsgegevens (NAW) behoeven "minder" beveiliging dan bijzondere (ras, religie). Dat blijkt uit het gebruik van woorden als "passend(e bescherming)" en "naar de aard van de gegevens". Encryptie lijkt mij sowieso onvermijdelijk bij anonymisering of pseudonymisering. Een gescheiden database lijkt mij alleen zinvol als die database door vrijwel niemand is te benaderen, dat zal je ook op een apart gedeelte van een bestaande database moeten kunnen bereiken. Mijn IT kennis is echter helaas te beperkt om dat goed te beoordelen. Het meest van belang lijkt mij om te voorkomen, dat persoonsgegevens alsnog kunnen worden herleid door in beginsel onleesbare gegevens te combineren met andere (persoons)gegevens.
Ik begrijp zelfs uit dit heel interessante artikel dat een EU werkgroep er opheldering over zou moeten leveren, maar dat nog niet gedaan heeft
De auteur van dit artikel hoopt m.i. op een (nieuwe) guideline of opinion van de Article 29 Working Party. Het is de vraag of die er gaat komen, vooralsnog is er alleen de oude opinion uit 2014 over anonymisering (ook vermeld in het artikel), dus gebaseerd op de huidige EU richtlijn.

Zie hier waarschijnlijk de grootste uitdaging van de AVG: er is zowel juridische kennis als IT kennis nodig om de AVG goed te (laten) implementeren. Nullen en enen lijken zich goed te verhouden tot zwart op wit geschreven teksten, probleem is dat zwart-wit heel vaak grijs wordt. De verhouding is dan snel zoek. 8)

Acties:
  • 0 Henk 'm!

Anoniem: 696166

Topicstarter
Hallo bomsan, bedankt voor de uitgebreide reactie.
Ik begrijp er werkelijk hoe langer hoe minder van. Men legt een zeer zware verantwoordelijkheid op de schouders van letterlijk elke ondernemer die actief is in Europa met mogelijks bijzonder zware boetes. Men laat echter na om duidelijkheid te verschaffen over hoe men verwacht dat diezelfde ondernemers aan deze wetgeving moeten voldoen.

Hoe ik de situatie nu begrijp zal het uiteindelijk een rechter zijn die beslist of de "passende maatregelen" zijn genomen in geval van problemen. De eerste veroordeelde heeft dan gewoon pech gehad.

Misschien is er een rol voor de tweakers redactie weggelegd om een diepgaand artikel aan deze problematiek te wijden?

Acties:
  • 0 Henk 'm!

  • Bomsan
  • Registratie: April 2015
  • Niet online
De NL overheid kan m.i. sowieso veel meer doen aan bewustwording, alhoewel in de media de AVG steeds meer wordt opgepikt.

Duidelijkheid is helaas vaak context afhankelijk, dat is meestal het geval met complexe wetgeving. Er zijn best veel goede informatiebronnen te vinden op internet die je verder kunnen helpen, in de eerste plaats natuurlijk de website van de AP. De andere kant is dat men op internet vaak maximaal strak in de leer zit qua interpretatie van de AVG, als je ruimte wilt onderzoeken moet je een expert raadplegen.

Het zal met boetes en veroordelingen overigens - in NL en in het begin - wel meevallen denk ik. De figuur van de dwangsom zal in NL (eerst) gehanteerd worden voordat men boetes gaat opleggen. Onderzoeken wat je doet en waarom, dat goed motiveren en vastleggen zal helpen om boetes en sancties te voorkomen.

Acties:
  • 0 Henk 'm!

  • Thralas
  • Registratie: December 2002
  • Laatst online: 16:50
Bomsan schreef op woensdag 16 augustus 2017 @ 13:21:
De AVG is ook van toepassing op vestigingen van een verantwoordelijke of verwerker in de EU die als activiteit het verwerken van persoonsgegevens hebben, ongeacht waar de verwerking plaatsvindt (art 3.1). Dit is bij Salesforce het geval.
Dank! Dat was me niet duidelijk.
Bomsan schreef op donderdag 17 augustus 2017 @ 12:58:
Anonymisering leidt tot onherleidbare gegevens (de naam Jan Jansen wordt veranderd A6% B8*tt$, zonder dat de sleutel wordt bewaard - als die er al is).
Volgens mij gebruik je hier 'sleutel' in de context van cryptografie; het lijkt me nu juist dat er bij anonimisatie uberhaupt geen sprake van een sleutel is.

Stel je hebt een database met IP-adressen (en niet meer dan dat); dan kun je individuele entries anonimiseren door ze te vervangen door een willekeurig gekozen nummer. Komt geen sleutel aan te pas, maar volgens mij zijn we het in principe wel eens voor wat betreft deze definitie.
Pseudonymisering leidt tot in beginsel onherleidbare gegevens (de naam Jan Jansen wordt gewijzigd in UqH Uqhw3h, de manier van versleuteling wordt bewaard - met zeer beperkte toegang).
Zie ook de overwegingen 26 en 28 van de verordening op p.5 (NL versie).
Het feit dat je het hier over een sleutel en toegang hebt, suggereert dat het de bedoeling is dat pseudoniemen inherent herleidbaar zouden zijn, terwijl dat niet het idee is, toch? Enkel dat er praktische problemen zijn die anonimisatie onmogelijk maken.

Naar mijn idee betekent pseudonimisatie enkel dat men met aanvullende gegevens/datasets tóch een pseudoniem zou kunnen herleiden naar een persoon, waarbij er o.a. rekening dient te worden gehouden met de moeite die dat kost.

Een beter voorbeeld lijkt me het pseudonimiseren zoals Tweakers dat doet, als iemand wil worden 'uitgeschreven'. Alle gegevens worden daarmee uit een gebruikersprofiel gehaald (de posts even buiten beschouwing gelaten) en de gebruiker wordt aangeduid met z'n user id.

Is iemand daarmee anoniem? Nee, want een serverbeheerder kan ongetwijfeld op basis van het user id in serverlogs graven naar bijbehorende IP-adressen. Maar het doel is in ieder geval (grotendeels) bereikt ten aanzien van het 'publiek'.

Een praktisch probleem ten aanzien van pseudonimisatie wat me zo snel te binnen schiet is het feit dat bedrijven (volgens mij) verplicht zijn om facturen te bewaren voor de Belastingdienst. Nog net wat vervelender dan een IP-adres in de serverlogs.

Correct me if I'm wrong

Acties:
  • 0 Henk 'm!

  • Bomsan
  • Registratie: April 2015
  • Niet online
Thralas schreef op vrijdag 18 augustus 2017 @ 18:43:
Volgens mij gebruik je hier 'sleutel' in de context van cryptografie; het lijkt me nu juist dat er bij anonimisatie uberhaupt geen sprake van een sleutel is.
(...)
Komt geen sleutel aan te pas, maar volgens mij zijn we het in principe wel eens voor wat betreft deze definitie.
We zijn het eens...
Naar mijn idee betekent pseudonimisatie enkel dat men met aanvullende gegevens/datasets tóch een pseudoniem zou kunnen herleiden naar een persoon, waarbij er o.a. rekening dient te worden gehouden met de moeite die dat kost.
Dat is precies wat ik bedoel en volgens mij ook wat is beoogd met het invoeren van pseudonimisering.
Een praktisch probleem ten aanzien van pseudonimisatie wat me zo snel te binnen schiet is het feit dat bedrijven (volgens mij) verplicht zijn om facturen te bewaren voor de Belastingdienst. Nog net wat vervelender dan een IP-adres in de serverlogs.
De wettelijke administratieplicht (bewaarplicht) is meestal 7 jaar, o.a. volgens het BW en de Algemene Wet Rijksbelastingen. Het is dus een wettelijke verplichting, die zet een recht (verzoek) tot het wissen van gegevens opzij. Dat kan in de praktijk problemen opleveren als persoonsgegevens slechts gedeeltelijk gekoppeld zijn aan een factuur (bijvoorbeeld) en gedeeltelijk niet. Wat verwijder je dan immers. Praktisch oplossen lijkt mij, bewaren wat (strikt) noodzakelijk is voor de administratie en overige niet noodzakelijke of relevante gegevens verwijderen of anonimiseren.
Correct me if I'm wrong
Mostly right ;)

Acties:
  • +1 Henk 'm!

  • THW Mark
  • Registratie: December 2000
  • Laatst online: 04-06 10:41
Wellicht nuttig voor anderen die hier mee aan de slag gaan, Deze guide heeft een redelijk pragmatisch overzicht van stappen die je als organisatie moet doorgaan voor het compliant worden.

Ik moet zeggen dat het voor (web)developers nog steeds wel iets te wollig is. Ik zou zelf wel een soort van Checklist willen hebben van zaken die je echt moet regelen in je software. Op zich komt dit redelijk in de buurt, maar eigenlijk nog steeds teveel organisatorisch. Iemand andere suggesties?

Acties:
  • 0 Henk 'm!

  • Orion84
  • Registratie: April 2002
  • Laatst online: 18:13

Orion84

Admin General Chat / Wonen & Mobiliteit

Fotogenie(k)?

De vraag is of je je hier als developer heel druk over zou moeten maken? Tenzij je het soort developer bent dat end to end ook requirements verzamelt een design doet etc., maar dat is sec gezien geen development werk.

Sowieso zal de vertaalslag van het organisatorische/functionele "wat" naar het technische "hoe" al snel nogal bedrijfspecifiek zijn en lastig te vangen in generieke checklists.

Dergelijke checklists (zeker zodra ze op detail niveau gaan) hebben sowieso nogal een enorm risico dat mensen zich blindstaren op de checklist en niet meer nadenken. Dat zie je ook terug in informatiebeveiliging, waar soms meer waarde gehecht wordt aan compliance dan aan daadwerkelijk veilig zijn.

The problem with common sense is that it's not all that common. | LinkedIn | Flickr


Acties:
  • +1 Henk 'm!

  • celshof
  • Registratie: December 2009
  • Laatst online: 01:17
Orion84 schreef op dinsdag 3 oktober 2017 @ 15:50:
Dat zie je ook terug in informatiebeveiliging, waar soms meer waarde gehecht wordt aan compliance dan aan daadwerkelijk veilig zijn.
Ik heb ervaring met de implementatie van PCI DSS en ben laatst bij een conferentie over de GDPR geweest. Bij beide is heel duidelijk dat administratie een hoofddoel is. Je moet een boel hebben vastgelegd in papieren procedures en dat lijkt wel haast belangrijker dan het daadwerkelijk volgen van je processen.

Acties:
  • 0 Henk 'm!

  • Yucon
  • Registratie: December 2000
  • Nu online

Yucon

*broem*

celshof schreef op dinsdag 3 oktober 2017 @ 15:57:
[...]
Ik heb ervaring met de implementatie van PCI DSS en ben laatst bij een conferentie over de GDPR geweest. Bij beide is heel duidelijk dat administratie een hoofddoel is. Je moet een boel hebben vastgelegd in papieren procedures en dat lijkt wel haast belangrijker dan het daadwerkelijk volgen van je processen.
Ik heb in de wandelgangen wel wat opmerkingen gehoord als "je mag alleen informatie verzamelen die je nodig hebt. Wij hebben zoveel mogelijk informatie nodig omdat we hier iets van willen leren, dus zitten we goed" ok, dit is een tikje aangedikt, maar het idee is duidelijk. Je voelt aan je water dat dat niet de geest van de GDPR is. Betekent dit dat je er toch mee weg komt mits het op papier aardig uit ziet?

Acties:
  • 0 Henk 'm!

  • celshof
  • Registratie: December 2009
  • Laatst online: 01:17
Yucon schreef op dinsdag 3 oktober 2017 @ 19:27:
[...]

Ik heb in de wandelgangen wel wat opmerkingen gehoord als "je mag alleen informatie verzamelen die je nodig hebt. Wij hebben zoveel mogelijk informatie nodig omdat we hier iets van willen leren, dus zitten we goed" ok, dit is een tikje aangedikt, maar het idee is duidelijk. Je voelt aan je water dat dat niet de geest van de GDPR is. Betekent dit dat je er toch mee weg komt mits het op papier aardig uit ziet?
Ik verwacht van niet, maar zonder meer achtergrond is dat wat moeilijk te zeggen. Als het 'er van leren' een gerechtvaardigd doel is en ook bij het afgeven van het doel duidelijk aan de personen gecommuniceerd en we het niet over bijzondere persoonsgegevens hebben, is er wel een kans dat het mag,
Uiteraard moeten de gegevens dan wel alleen beschikbaar zijn voor die mensen die het nodig hebben en niet voor anderen.

Acties:
  • 0 Henk 'm!

Anoniem: 986601

De wettelijke administratieplicht (bewaarplicht) is meestal 7 jaar, o.a. volgens het BW en de Algemene Wet Rijksbelastingen. Het is dus een wettelijke verplichting, die zet een recht (verzoek) tot het wissen van gegevens opzij. Dat kan in de praktijk problemen opleveren als persoonsgegevens slechts gedeeltelijk gekoppeld zijn aan een factuur (bijvoorbeeld) en gedeeltelijk niet. Wat verwijder je dan immers. Praktisch oplossen lijkt mij, bewaren wat (strikt) noodzakelijk is voor de administratie en overige niet noodzakelijke of relevante gegevens verwijderen of anonimiseren.
Waar baseer je deze uitspraak op? Heb je hier een bron van? Ik ben namelijk niet bekend met het feit dat het BW voorrang heeft op AVG? Ik zou het graag van je aannemen hoor! ;)

Acties:
  • 0 Henk 'm!

  • Binnetie
  • Registratie: November 2000
  • Laatst online: 26-07 22:15
Ook ik ben hier door benaderd door mijn leidinggevende. Ik moet een 'update' geven van de nieuwe wet. Zelf ben ik een beetje de schakel tussen systeembeheer en de eindgebruiker.

Ik probeer een beetje te achterhalen wat mijn rol hierin zou kunnen zijn.

Wij gebruiken bijv. AFAS voor CRM/ERP, financiën en personeelsadministratie. Dit is gekoppeld aan onze Active Directory (voor Single Sign On) waarin ik de gebruiker aanmaak.
Ons AD synced naar Office365 waar onze e-mail afgehandeld wordt.

Onze servers/infra etc worden extern beheerd en voor AFAS hebben we een medewerker die hierin gespecialiseerd is.

Inhoudelijk doe ik niets met AFAS (alleen mijn uren invullen en declaraties), ik zorg alleen voor het Single Sign On deel.
Iemand die een handson heeft?

Acties:
  • +2 Henk 'm!

  • Orion84
  • Registratie: April 2002
  • Laatst online: 18:13

Orion84

Admin General Chat / Wonen & Mobiliteit

Fotogenie(k)?

Klinkt alsof jij niet de juiste persoon bent om dit onderwerp bij te beleggen. GDPR is iets dat uiteindelijk in de implementatie ook technische wijzigingen zou kunnen vereisen, maar zeker niet iets wat je vanuit de techniek (en voor zover ik begrijp zit jij meer aan de technische IT kant) zou moeten aanvliegen.

The problem with common sense is that it's not all that common. | LinkedIn | Flickr


Acties:
  • 0 Henk 'm!

  • Binnetie
  • Registratie: November 2000
  • Laatst online: 26-07 22:15
Orion84 schreef op maandag 30 oktober 2017 @ 16:00:
Klinkt alsof jij niet de juiste persoon bent om dit onderwerp bij te beleggen. GDPR is iets dat uiteindelijk in de implementatie ook technische wijzigingen zou kunnen vereisen, maar zeker niet iets wat je vanuit de techniek (en voor zover ik begrijp zit jij meer aan de technische IT kant) zou moeten aanvliegen.
Zoiets dacht ik ook al, maar mijn leidinggevende kwam dit zo specifiek bij mij beleggen...
Bij welke afdelingen zou dit dan meer komen te liggen? Precies wat je aangeeft, bij de implementatie zou er vanuit technisch oogpunt ook wat voor mij inzitten. Maar in het voortraject zou er een andere kartrekker moeten zijn.

Acties:
  • +1 Henk 'm!

  • F_J_K
  • Registratie: Juni 2001
  • Niet online

F_J_K

Moderator CSA/PB

Front verplichte underscores

SSO is het minste probleem. Ik zou haast stellen dat het grootste probleem is dat je leidinggevende denkt dat privacy ihkv de GDPR een technisch iets is :P Zoals Orion84 zegt: het is ook een beetje techniek, maar nadruk op -ook-. Voldoende kennis hebben van de informatiestromen, processen, applicaties is natuurlijk wel erg een pre.

Waar ligt zeggenschap over aanpassen van de werkprocessen en de organisatie? Wie heeft zicht op de (verwerkers- en overige) overeenkomsten met de externe partijen?
Daar ligt eerder de verantwoordelijkheid. Prima als dat bij jou wordt belegd, maar dan moet je er wel zowel affiniteit hebben als gezag voor krijgen.

'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind' (Terry Pratchett, Eric)


Acties:
  • 0 Henk 'm!

  • Binnetie
  • Registratie: November 2000
  • Laatst online: 26-07 22:15
Dankjewel beiden. Dat is mijn leidinggevende die hier zeggenschap over heeft (verantwoordelijk voor de backoffice voor HRM, financiën en ICT).
Via via werden we geattendeerd op een kennissessie van een ICT dienstverlener: https://www.unicaschutte-...ywetgeving-gdpr-apeldoorn misschien dat daarom naar mij gewezen wordt.

Ik werk samen met een externe ICT dienstverlener, die hier ongetwijfeld bepaalde zaken in zullen gaan doen samen met mij. Qua applicaties verzorg ik de toegang tot AFAS, etc, maar inhoudelijk werkt elke afdeling met een eigen online applicatie waarvan ze zelf de toegangsaccounts beheren (denk aan systeem voor ziektemeldingen, recruitment tools voor de werving en selectie van collega's).

Acties:
  • 0 Henk 'm!

  • robbierzz
  • Registratie: November 2006
  • Laatst online: 11-07 10:36
Binnetie schreef op dinsdag 31 oktober 2017 @ 15:50:
Dankjewel beiden. Dat is mijn leidinggevende die hier zeggenschap over heeft (verantwoordelijk voor de backoffice voor HRM, financiën en ICT).
Via via werden we geattendeerd op een kennissessie van een ICT dienstverlener: https://www.unicaschutte-...ywetgeving-gdpr-apeldoorn misschien dat daarom naar mij gewezen wordt.

Ik werk samen met een externe ICT dienstverlener, die hier ongetwijfeld bepaalde zaken in zullen gaan doen samen met mij. Qua applicaties verzorg ik de toegang tot AFAS, etc, maar inhoudelijk werkt elke afdeling met een eigen online applicatie waarvan ze zelf de toegangsaccounts beheren (denk aan systeem voor ziektemeldingen, recruitment tools voor de werving en selectie van collega's).
Aangezien je leidinggevende wel de verantwoording heeft voor HRM/FA/ICT zal hij wellicht wél de noodzaak voelen 'iets' in zijn (of haar..) team te realiseren in dit kader. Als je als bedrijf SaaS achtige applicaties gebruikt, ben je nog steeds verantwoordelijk om te voldoen aan de GDPR. Weliswaar zul je je leverancier aansturen op de te nemen maatregelen, maar je zult zelf duidelijk richting moeten geven aan de leverancier over de te nemen maatregelen.

Als ik kijk naar hoe we binnen onze eigen organisatie hiermee aan de slag zijn (+- 250 medewekers), hebben we onze Compliance / Risk management officer (tevens DPO) naar voren geschoven om een plan te maken en dit te bespreken met juridische zaken en onze security officer. Die laatste zorgt vervolgens weer voor de vertaling richting IT projecten als dat noodzakelijk blijkt.

En zelfs in dit samenwerkingsverband zie je dat het heel lastig blijkt om de regelgeving op de juiste manier te interpreteren en de vertaling te maken naar veranderpojecten.

Dance with the stars


Acties:
  • 0 Henk 'm!

  • connectcase
  • Registratie: Oktober 2007
  • Laatst online: 11-07 19:58
Er is theorie genoeg te vinden op het Internet, al dan niet met gehuld in mysteries....

Maar weet iemand toevallig een praktische to-do list te vinden? Met simpele aanpassingen die vereist zijn voor gegevensverzameling via je website / webshop?

Uit alle theorie die ik inmiddels heb doorgebladerd wordt me eerlijk gezegd nog steeds niet duidelijk OF en WAT ik aan mijn cookiebanner moet wijzigen.....

Acties:
  • 0 Henk 'm!

Verwijderd

Weet er iemand hoe men in het kader van de gdpr moet omgaan met een CRM systeem?
Mag ik nog leads ingeven in een CRM zonder de uitdrukkelijke toestemming van de betrokkene (dat is namelijk gewoonweg onmogelijk)?
Is het toegestaan om een telefoongesprek met iemand die (nog) geen klant is te loggen in een CRM systeem?
Wordt er een verschil gemaakt tussen een professionele lead (vb. de contactgegevens van de sales manager van een organisatie) en een particulier?

Acties:
  • 0 Henk 'm!

  • F_J_K
  • Registratie: Juni 2001
  • Niet online

F_J_K

Moderator CSA/PB

Front verplichte underscores

Het is een belangenafweging die je moet maken. Heb toestemming, of gerechtvaardigd belang. Direct marketing kan zo’n belang zijn. Maar dan moet je ze wel de gelegenheid geven om bezwaar te maken en dan de gegevens wissen. Bv door bij nieuwsbrief een optout.

Je moet die leads natuurlijk wel zelf hebben gegenereerd, niet gekocht. Als gekocht, dan zeker weten dat het met toestemming is. Op papier.

Tel.gesprek: als je belang hebt etc ja. Bijv voor terugbelverzoek of info toezending. Wel wissen zodra de gegevens niet meer relevant zijn, dus bv na ‘nee’ in een volgende gesprek. (Of toestemming vragen of je ooit nog eens mag bellen/mailen).

De alg contactinfo van een bedrijf is geen persoonsgegeven, die van de verkoper wel. De Sales meneer geeft overigens vast graag toestemming..

Gaan veel organisaties gewoon blijven doen wat ze altijd al doen? Ik denk het wel :o

'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind' (Terry Pratchett, Eric)


Acties:
  • 0 Henk 'm!

  • Enki
  • Registratie: Januari 2004
  • Laatst online: 17-07 13:26
Hier min of meer hetzelfde: HRM had van de moedermaatschappij opdracht gekregen aan te tonen dat we ons conformeren aan de GDPR-regulering. Dus schakelde ze mij in "om op de een of andere manier aan te tonen dat privacy-gevoelige data beveiligd is op ons netwerk". Toen ik vroeg wat ze zich daarbij voorstelde, antwoordde ze dat misschien screenshots van de permissions op sommige netwerkfolders wel handig zouden zijn... 8)7

Ik kan me toch niet voorstellen dat dit voldoende is? Ik ben me al dagenlang aan het inlezen, maar ik heb nog nauwelijks een idee wat er in ons concreet geval nu precies nodig is. Leest ook zo lekker, dat wollige juridische taalgebruik... :r

Only two things are infinite, the universe and human stupidity, and I'm not sure about the former - Albert Einstein


Acties:
  • 0 Henk 'm!

  • Stoelpoot
  • Registratie: September 2012
  • Niet online
Enki schreef op maandag 4 december 2017 @ 15:48:

Ik kan me toch niet voorstellen dat dit voldoende is? Ik ben me al dagenlang aan het inlezen, maar ik heb nog nauwelijks een idee wat er in ons concreet geval nu precies nodig is. Leest ook zo lekker, dat wollige juridische taalgebruik... :r
Stuur anders even een mailtje naar HRM wat voor mogelijkheden zij voorstellen om dat aan te tonen? Gewoon menselijk contact is 9/10x een stuk duidelijker.

Als ze daar geen gehoor geven: Stuur die screenshots en wacht totdat ze nee zeggen, dan nog een keer aangeven dat ze geen duidelijke mogelijkheid geven om dat te doen.

Acties:
  • 0 Henk 'm!

  • Enki
  • Registratie: Januari 2004
  • Laatst online: 17-07 13:26
HRM had dit twee weken geleden in een 1-op-1 gesprek aan mij doorgegeven en er gelijk bij gezegd dat ze er zelf ook geen ruk van snapte. Ik heb inderdaad weinig andere keuze dan de screenshots aan te leveren zoals ze vraagt, het is meer dat ik geen zin heb om na een paar weken, als er weer een oekaze van het hoofdkantoor terug komt, me er helemaal weer opnieuw in te moeten verdiepen!

Only two things are infinite, the universe and human stupidity, and I'm not sure about the former - Albert Einstein


Acties:
  • 0 Henk 'm!

  • Der Rudi
  • Registratie: Mei 2002
  • Laatst online: 18:14
Tip: kijk eens bij bijvoorbeeld ICTRecht. Die geven een aantal trainingen/cursussen over dit topic, ook voor 'leken'. Dan krijg je iig een goed lopend verhaal te horen en kun je je vragen ook direct kwijt.

Acties:
  • 0 Henk 'm!

  • fustire
  • Registratie: Oktober 2006
  • Laatst online: 05-08-2022
De AVG is bijzonder uitgebreid. Interessant is wat de artikel 29 werkgroep, een werkgroep van alle Europese privacytoezichthouders, te zeggen heeft over verschillende onderwerpen. Zo is er over de (D)PIA al een advies gekomen. In die adviezen legt de Artikel 29 groep op in ieder geval een iets praktischer manier uit wat de AVG inhoudt.

Wat wel duidelijk is dat organisaties concreet het volgende moeten doen:
  1. verwerkersovereenkomsten met een ieder die namens hen persoonsgegevens verwerkt
  2. privacyafspraken met je personeel (bijvoorbeeld in de vorm van een protocol)
  3. privacyverklaring op je website (wanneer je daar persoonsgegevens verzameld, als onderdeel van de informatieplicht
Daarnaast moeten organisaties een privacyregister aanleggen wanneer ze niet-incidenteel persoonsgegevens verwerken.De Nederlandse Autoriteit Persoonsgegevens heeft nog niet verduidelijkt wat daarmee bedoeld wordt. De Belgische Privacycommissie heeft al aangegeven dat het verwerken van slechts klantgegevens in een CRM al niet-incidenteel is, kort gezegd moet vrijwel elke organisatie een privacyregister aanleggen.

Dan hebben we nog de (D)PIA. De Artikel 29 groep heeft 9 criteria opgesteld om vast te stellen of een organisatie een PIA moet doen. In het advies wordt gezegd dat wanneer je verwerkingsactiviteit aan meer dan één criterium voldoet, je een PIA moet doen. De NOREA, beroepsorganisatie van IT-auditors, heeft een handreiking voor het doen van een PIA opgesteld.

De Functionaris voor de Gegevensbescherming (FG/DPO) is vereist in gevallen wanneer de overheid persoonsgegevens verwerkt of wanneer sprake is van grootschalige verwerking van bijzondere persoonsgegevens als kerntaak van een onderneming, of wanneer sprake is van de verwerking van strafrechtelijke gegevens als kerntaken van de onderneming. Hier is dus veel minder snel sprake van. Een FG moet een natuurlijk persoon zijn en moet kennis hebben van de organisatie van de verantwoordelijke en van het privacyrecht uiteraard. De IAPP heeft al, toch wel vrij prijzige, cursussen waarin je opgeleid wordt tot Certified Information Privacy Professional/Europe.

Ik wilde even kort een toelichting geven op vragen die ik in dit topic tegenkwam. Deze post is uiteraard niet volledig, en is ook zeker zo niet bedoeld. Mocht iemand vragen hebben naar aanleiding van mijn post, shoot!

Acties:
  • 0 Henk 'm!

  • Onbekend
  • Registratie: Juni 2005
  • Nu online

Onbekend

...

Over 5 maanden is het 25 mei 2018, en ik weet zeker dat ik niet de enige ben die nog niet precies weet hoe je het gdpr compleet kunt toepassen. :)

Ik heb zo ook mijn vragen en neem aan dat jullie die vragen ook hebben gehad ;)


Zijn bedrijfsgegevens ook persoonsgegevens? Dus het adres van het bedrijf zelf, maar ook het e-mailadres en mobiel nummer van jouw contactpersoon daar?


Stel je bent een webshop. Een nieuwe particuliere klant meldt zich aan, koopt een (duur) product, je stuurt een factuur, klant betaalt en die vraagt daarna om de verwijdering van zijn/haar persoonsgegevens.
Voor de belastingdienst moet je de persoonsgegevens bewaren om die factuur te reproduceren. Als die gegevens zijn verwijderd, kan je niet meer bewijzen dat die factuur terecht was. Hoe gaat dat?


Is het intern gebruiken van namen van de werknemers ook verwerking persoonsgegevens? Bij software-ontwikkeling wordt vaak het versiebeheer gebruikt, waarbij bij elke wijziging allerlei gegevens worden opgeslagen zoals gebruikersnaam, tijdstip en ip-adres. Deze hoeven hoop ik toch niet verwijderd te worden? ;)


Audits. Het zelfde als hierboven, maar dat voor normale gebruikers. In software kan een audit bij worden gehouden wie welke wijziging in de data heeft gemaakt. Als de werknemer het bedrijf verlaat en deze wil al zijn gegevens verwijderd hebben, moeten alle historische audits dan aangepast worden?

Speel ook Balls Connect en Repeat


Acties:
  • 0 Henk 'm!

  • Croga
  • Registratie: Oktober 2001
  • Laatst online: 25-07 17:39

Croga

The Unreasonable Man

Onbekend schreef op maandag 25 december 2017 @ 11:06:

Zijn bedrijfsgegevens ook persoonsgegevens? Dus het adres van het bedrijf zelf, maar ook het e-mailadres en mobiel nummer van jouw contactpersoon daar?
Alles wat naar een persoon te herleiden is zijn persoonsgegevens. Het adres van een bedrijf dus niet, maar het EMail adres en telefoonnummer van een persoon wel.

Stel je bent een webshop. Een nieuwe particuliere klant meldt zich aan, koopt een (duur) product, je stuurt een factuur, klant betaalt en die vraagt daarna om de verwijdering van zijn/haar persoonsgegevens.
Voor de belastingdienst moet je de persoonsgegevens bewaren om die factuur te reproduceren. Als die gegevens zijn verwijderd, kan je niet meer bewijzen dat die factuur terecht was. Hoe gaat dat?
Waarom moet je de persoonsgegevens bewaren om een factuur te reproduceren? De factuur kun je opslaan als PDF en daarmee dus reproduceren. De persoonsgegevens hoeven daarvoor niet in een database te blijven staan. Nog sterker; als je de factuur zou willen reproduceren vanuit een database met persoonsgegevens loop je het risico dat je na verhuizing van de persoon de factuur niet meer kunt reproduceren. Ofwel: Gewoon de persoonsgegevens uit de database verwijderen, de PDF van de factuur in de administratie bewaren en je hebt voldaan aan beide wetten.

Acties:
  • 0 Henk 'm!

  • Onbekend
  • Registratie: Juni 2005
  • Nu online

Onbekend

...

Croga schreef op maandag 25 december 2017 @ 11:14:
[...]

Alles wat naar een persoon te herleiden is zijn persoonsgegevens. Het adres van een bedrijf dus niet, maar het EMail adres en telefoonnummer van een persoon wel.
De als een persoon vraagt om zijn gegevens te verwijderen moet je dat doen. En als vervolgens het bedrijf zelf vraagt wie in hemelsnaam iets heeft besteld heb je geen idee meer wie dat heeft gedaan? :S
[...]

Waarom moet je de persoonsgegevens bewaren om een factuur te reproduceren? De factuur kun je opslaan als PDF en daarmee dus reproduceren. De persoonsgegevens hoeven daarvoor niet in een database te blijven staan. Nog sterker; als je de factuur zou willen reproduceren vanuit een database met persoonsgegevens loop je het risico dat je na verhuizing van de persoon de factuur niet meer kunt reproduceren. Ofwel: Gewoon de persoonsgegevens uit de database verwijderen, de PDF van de factuur in de administratie bewaren en je hebt voldaan aan beide wetten.
Voor een factuur moet je kunnen aangeven waar de gegevens van de factuur vandaan komen (zoals verkeerd factuuradres).
En het reproduceren van een factuur gebeurd altijd op basis wat in de audit-records staat (zelfde als valutakoersen bijvoorbeeld), en niet op basis van huidige gegevens natuurlijk. :)

Speel ook Balls Connect en Repeat


Acties:
  • 0 Henk 'm!

  • Croga
  • Registratie: Oktober 2001
  • Laatst online: 25-07 17:39

Croga

The Unreasonable Man

Onbekend schreef op maandag 25 december 2017 @ 12:36:
De als een persoon vraagt om zijn gegevens te verwijderen moet je dat doen. En als vervolgens het bedrijf zelf vraagt wie in hemelsnaam iets heeft besteld heb je geen idee meer wie dat heeft gedaan? :S
De bestelling staat als document in je systeem, niet in een database. Je bent verplicht de bestelling zelf te bewaren. Je bent ook verplicht de persoonsgegevens uit de database te verwijderen. De twee sluiten elkaar niet uit.
Voor een factuur moet je kunnen aangeven waar de gegevens van de factuur vandaan komen (zoals verkeerd factuuradres).
En het reproduceren van een factuur gebeurd altijd op basis wat in de audit-records staat (zelfde als valutakoersen bijvoorbeeld), en niet op basis van huidige gegevens natuurlijk. :)
Beiden zijn niet database-gebonden maar document-gebonden. Ook dit sluit elkaar weer niet uit.

Dit is, wat je noemt, een "false dichotomy". Er is geen tegenstrijdigheid, er zijn twee compleet verschillende systemen en compleet verschillende wetten die op geen enkele manier met elkaar interacteren.
ALS je tenminste je systemen fatsoenlijk op orde hebt en niet probeert document-gebaseerde gegevens in een relationele database op te slaan......

Acties:
  • 0 Henk 'm!

  • BCC
  • Registratie: Juli 2000
  • Laatst online: 18:08

BCC

Onbekend schreef op maandag 25 december 2017 @ 11:06:
Over 5 maanden is het 25 mei 2018, en ik weet zeker dat ik niet de enige ben die nog niet precies weet hoe je het gdpr compleet kunt toepassen. :)

Ik heb zo ook mijn vragen en neem aan dat jullie die vragen ook hebben gehad ;)


Zijn bedrijfsgegevens ook persoonsgegevens? Dus het adres van het bedrijf zelf, maar ook het e-mailadres en mobiel nummer van jouw contactpersoon daar?
Ja

Stel je bent een webshop. Een nieuwe particuliere klant meldt zich aan, koopt een (duur) product, je stuurt een factuur, klant betaalt en die vraagt daarna om de verwijdering van zijn/haar persoonsgegevens.
Voor de belastingdienst moet je de persoonsgegevens bewaren om die factuur te reproduceren. Als die gegevens zijn verwijderd, kan je niet meer bewijzen dat die factuur terecht was. Hoe gaat dat?
Je zegt: over 5 jaar worden ze vanzelf vernietigd want zo lang moeten we ze bewaren voor de belastingdienst. Vervolgens zorg je voor een procedure waar dat ook ECHT gebeurd.

Is het intern gebruiken van namen van de werknemers ook verwerking persoonsgegevens?
Ja en je moet de beveiligingsincidenten van je hr leverancier correct verwerken en evt melden.
Bij software-ontwikkeling wordt vaak het versiebeheer gebruikt, waarbij bij elke wijziging allerlei gegevens worden opgeslagen zoals gebruikersnaam, tijdstip en ip-adres. Deze hoeven hoop ik toch niet verwijderd te worden? ;)
Als medewerker dit wil lijkt me dit een terechte vraag. Een goed wederantwoord kan ook zijn : over 5 jaar of als het project gearchiveerd wordt, wordt het geanonimiseerd. En een procedure daarvoor inrichten.

Audits. Het zelfde als hierboven, maar dat voor normale gebruikers. In software kan een audit bij worden gehouden wie welke wijziging in de data heeft gemaakt. Als de werknemer het bedrijf verlaat en deze wil al zijn gegevens verwijderd hebben, moeten alle historische audits dan aangepast worden?
Nee, zie vorige vraag. En een proces dat Na 5 jaar de audit weggooit.

Waar ik hier 5 jaar roep, moet je uiteraard een termijn kiezen die zinnig is voor de toepassing.

Ik ben met mijn werk vanuit de it veel hiermee bezig en het is veel meer een procedurele aangelegenheid dan een programmeertechnische. Het maakt voor de wet niet uit of jij 1x per jaar met de hand oude persoonsgegevenss uit de db gooit of dat de software dit zelf , als er maar nagedacht is over hoelang welke data bewaard wordt en daarna ook daadwerkelijk weggegooid wordt.

[ Voor 11% gewijzigd door BCC op 25-12-2017 15:50 ]

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.


Acties:
  • +1 Henk 'm!

  • F_J_K
  • Registratie: Juni 2001
  • Niet online

F_J_K

Moderator CSA/PB

Front verplichte underscores

Croga schreef op maandag 25 december 2017 @ 13:08:
De bestelling staat als document in je systeem, niet in een database. Je bent verplicht de bestelling zelf te bewaren. Je bent ook verplicht de persoonsgegevens uit de database te verwijderen. De twee sluiten elkaar niet uit.
Een gestructureerd document dat gestructureerd is opgeslagen. En kan als zodanig nog prima een 'bestand' zijn zoals beschreven in de AVG. Al zou het een klantdossier in papieren mappen zijn, dan nog.

Gegevens die je wettelijk moet bewaren, moet je bewaren. Dan heb je een prima gerechtvaardigd belang. Als je de persoonsgegevens dan nog wat minder makkelijk vindbaar maakt, door alleen in de pdf op te nemen, dan des te beter. Bijv. art. 6.1f is dan al een reden om alsnog te bewaren (belangenafweging).
Onbekend schreef op maandag 25 december 2017 @ 11:06:

Is het intern gebruiken van namen van de werknemers ook verwerking persoonsgegevens? Bij software-ontwikkeling wordt vaak het versiebeheer gebruikt, waarbij bij elke wijziging allerlei gegevens worden opgeslagen zoals gebruikersnaam, tijdstip en ip-adres. Deze hoeven hoop ik toch niet verwijderd te worden?
Naam van de melder is een erg relevant gegeven.
(Zeker) zolang men werkzaam is dan mag je toch gewoon de eigen medewerkernamen gebruiken? Het zou wat zijn als het salarissysteem die namen niet mag kennen :P

Audits. Het zelfde als hierboven, maar dat voor normale gebruikers. In software kan een audit bij worden gehouden wie welke wijziging in de data heeft gemaakt. Als de werknemer het bedrijf verlaat en deze wil al zijn gegevens verwijderd hebben, moeten alle historische audits dan aangepast worden?
Zolang er gerechtvaardigd belang is om ze te bewaren, bijv. tot 7 jaar bewaren voor het geval er later nog een reden is om de audit trail te checken. Natuurlijk wel a) toegang tot de logs sterk beperken tot mensen en situaties dat het nodig is (maar dat wil je sowieso) en b) een procedure hebben om N jaar oude meuk alsnog te verwijderen (idem).

'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind' (Terry Pratchett, Eric)


Acties:
  • 0 Henk 'm!

  • BCC
  • Registratie: Juli 2000
  • Laatst online: 18:08

BCC

Dear Santa,

I am writing to invoke my right to be removed from the naughty list, as per Article 17(1) of the EU GDPR and hereby withdraw my consent for my information to be ever held there as per Article 7(3).

Yours faithfully,
Timmy (age 5)

PS I would like a red bike for xmas

😀 via https://twitter.com/pwnal...status/945353758137049088

[ Voor 12% gewijzigd door BCC op 26-12-2017 16:56 ]

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.


Acties:
  • 0 Henk 'm!

  • BCC
  • Registratie: Juli 2000
  • Laatst online: 18:08

BCC

Dit heb ik helaas al een paar keer van dichtbij gezien : nieuws: Nijmeegse tandartspraktijk waarschuwt voor datalek na ransomwareaanval bedrijven die proactief de nieuwe wetgeving toepassen worden met de grond gelijk gemaakt in de media/social media.. waarom?

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.


Acties:
  • 0 Henk 'm!

Anoniem: 696166

Topicstarter
Croga schreef op maandag 25 december 2017 @ 13:08:
[...]
De bestelling staat als document in je systeem, niet in een database. Je bent verplicht de bestelling zelf te bewaren. Je bent ook verplicht de persoonsgegevens uit de database te verwijderen. De twee sluiten elkaar niet uit.
[...]
De GDPR maakt zeer duidelijk en ondubbelzinnig een uitzondering voor gegevens die omwille van wettelijke redenen moeten bijgehouden worden. Facturatiegegevens vallen hier onder en moeten (mogen!) dus NIET verwijderd worden.
Wat is overigens het verschil tussen "een systeem" en "een database"? Een boekhoudkundig pakket heeft ook een database en daaruit mag je de persoon niet verwijderen. Er wordt nergens iemand verplicht om bestellingen als documenten te bewaren ipv in een database. Dat document kan trouwens zelf ook in een database staan.
Waarom moet je de persoonsgegevens bewaren om een factuur te reproduceren? De factuur kun je opslaan als PDF en daarmee dus reproduceren.
Als de persoonsgegevens in de pdf staan en jij bewaart die PDF, bewaar je per definitie die persoonsgegevens. Het is totaal irrelevant of die moeilijker (is dat trouwens wel zo?) te extraheren zijn (want ik denk dat je daarop doelt). Een PDF is niet veiliger dan een database.
De GDPR is van toepassing op letterlijk elk aspect van de bedrijfsvoering, niet enkel op electronische gegevens. Als een bedrijf bewakingscamera's heeft hangen vallen die ook onder de GDPR.
De persoonsgegevens hoeven daarvoor niet in een database te blijven staan.
Ik kan me niet voorstellen dat er 1 boekhoudpakket bestaat dat de factuurgegevens niet op die manier bijhoudt.
Nog sterker; als je de factuur zou willen reproduceren vanuit een database met persoonsgegevens loop je het risico dat je na verhuizing van de persoon de factuur niet meer kunt reproduceren.
De facturatiegegevens van de persoon worden in elk boekhoudpakket opgeslagen in de factuurtabel, samen met het factuurnummer en alle andere gegevens.
Ofwel: Gewoon de persoonsgegevens uit de database verwijderen, de PDF van de factuur in de administratie bewaren en je hebt voldaan aan beide wetten.
Dat is onwettig. Je bent verplicht om een volledig klantenbestand bij te houden met alle relevante gegevens. Dit gebeurt overal en altijd electronisch.
Of denk je werkelijk dat pakweg Proctor&Gamble of Shell enkel wat PDF'jes van hun honderdduizenden facturen bewaren? Dat is totaal onwerkbaar. Een boekhouding is meer dan wat PDF factuurtjes.
Elk bedrijf is verplicht een klantenbestand bij te houden met wettelijk bepaalde gegevens van die klanten.
Hoe denk je dat een belastingsdienst zijn controles kan uitvoeren zonder een klantenbestand van het bedrijf?

Acties:
  • 0 Henk 'm!

  • Croga
  • Registratie: Oktober 2001
  • Laatst online: 25-07 17:39

Croga

The Unreasonable Man

Anoniem: 696166 schreef op dinsdag 16 januari 2018 @ 10:26:
De GDPR maakt zeer duidelijk en ondubbelzinnig een uitzondering voor gegevens die omwille van wettelijke redenen moeten bijgehouden worden. Facturatiegegevens vallen hier onder en moeten (mogen!) dus NIET verwijderd worden.
Wat is overigens het verschil tussen "een systeem" en "een database"? Een boekhoudkundig pakket heeft ook een database en daaruit mag je de persoon niet verwijderen. Er wordt nergens iemand verplicht om bestellingen als documenten te bewaren ipv in een database. Dat document kan trouwens zelf ook in een database staan.
Er is geen verschil tussen "een systeem" en "een database". er is wel een verschil tussen iets opslaan als een document en iets opslaan als relationele gegevens.

De facturatiegegevens hoeven niet als relationele gegevens opgeslagen te zijn. Nog sterker; dit mag niet. Een factuur opslaan als relationele gegevens zorgt dat De Waarheid kan veranderen en dat mag niet. Dus is het beter de factuur als document op te slaan waardoor het ook niet meer persé persoonsgegevens zijn (het adres, bijvoorbeeld, is niet meer aan een persoon gekoppeld maar aan een factuur).
Dat is onwettig. Je bent verplicht om een volledig klantenbestand bij te houden met alle relevante gegevens. Dit gebeurt overal en altijd electronisch.
Koel. Leg dat eens uit aan de belastingdienst dan. Die vinden mijn PDF-based factuur gegevens namelijk meer dan voldoende.
Elk bedrijf is verplicht een klantenbestand bij te houden met wettelijk bepaalde gegevens van die klanten.
Hoe denk je dat een belastingsdienst zijn controles kan uitvoeren zonder een klantenbestand van het bedrijf?
De belastingdienst heeft geen enkel recht van een bedrijf een klantenbestand te eisen. Hoe ze dan controles uitvoeren? Dat is hun eigen probleem, niet het probleem van het bedrijf. Al zou het bedrijf alleen papieren facturen bewaren dan voldoen ze nogsteeds volledig aan de wet en heeft de belastingdienst niets te klagen.

Acties:
  • 0 Henk 'm!

Verwijderd

https://financien.belgium...jaarlijkse_klantenlisting
toegegeven, het gaat om btw-plichtigen, maar ook dat kunnen gewoon personen zijn.
facturatiegegevens hoeven niet als relationele gegevens opgeslagen te zijn
dat beweert ook niemand, normaal wordt dat in de factuurtabel opgeslagen

[ Voor 6% gewijzigd door Verwijderd op 16-01-2018 13:10 ]


Acties:
  • 0 Henk 'm!

Verwijderd

Anoniem: 696166 schreef op maandag 14 augustus 2017 @ 11:27:
Een van de zaken die verplicht zijn (en eigenlijk al waren volgens de verschillende nationale wetgevingen) is het informed consent. Om gegevens van een persoon te verwerken moet men kunnen aantonen dat men van die persoon impliciet de toelating heeft gekregen voor de gegevensverwerking.
Nu is mijn vraag: wat met webapplicaties waar gebruikers gegevens invoeren van anderen (bv. een online CRM applicatie). Hoe kan een bedrijf als Salesforce informed consent krijgen van de personen die in hun applicatie worden ingegeven door hun gebruikers?
Na heel wat opzoekingswerk hier mijn bevindingen ivm GDPR:
Salesforce is volgens de GDPR een gegevensverwerker (data processor), de klanten van salesforce zijn de verwerkingsverantwoordelijken (data controller). Het is aan de klanten om ervoor te zorgen dat de data die ze in salesforce steken voldoen aan de vereisten van de GDPR. Salesforce zelf heeft uiteraard als processor ook verantwoordelijkheden.
Voor het ingeven van gegevens van klanten en werknemers (en ongetwijfeld ook leveranciers en sommige andere zakelijke contacten) is geen informed consent nodig volgens artikel 47 van de GDPR, dat gaat over gerechtvaardigd belang en stelt oa.:
gerechtvaardigd belang kan bijvoorbeeld aanwezig zijn wanneer sprake is van een relevante en passende verhouding tussen de betrokkene en de verwerkingsverantwoordelijke, in situaties waarin de betrokkene een klant is of in dienst is van de verwerkingsverantwoordelijke
Ook voor prospecten (typisch ook in een CRM gestoken) lijkt dat niet altijd nodig te zijn (maar afhankelijk van geval tot geval), zoals uitgelegd in dit uitstekende artikel.

Over de vereisten van de data protection officer en data protection impact assessment lees ik tegenstrijdigheden. Het lijkt er voorlopig op dat hier enkel aan moet voldaan worden door grote bedrijven (>250 werknemers) of indien men gevoelige gegevens behandeld zoals uiteengezet in artikel 75:
Het qua waarschijnlijkheid en ernst uiteenlopende risico voor de rechten en vrijheden van natuurlijke personenkan voortvloeien uit persoonsgegevensverwerking die kan resulteren in ernstige lichamelijke, materiële of immateriële schade, met name: waar de verwerking kan leiden tot discriminatie, identiteitsdiefstal of -fraude, financiële verliezen, reputatieschade, verlies van vertrouwelijkheid van door het beroepsgeheim beschermde persoonsgegevens, ongeoorloofde ongedaanmaking van pseudonimisering, of enig ander aanzienlijk economisch of maatschappelijk nadeel; wanneer de betrokkenen hun rechten en vrijheden niet kunnen uitoefenen of worden verhinderd controle over hun persoonsgegevens uit te oefenen; wanneer persoonsgegevens worden verwerkt waaruit ras of etnische afkomst, politieke opvattingen, religie of levensbeschouwelijke overtuigingen, of vakbondslidmaatschap blijkt, en bij de verwerking van genetische gegevens of gegevens over gezondheid of seksueel gedrag of strafrechtelijke veroordelingen en strafbare feiten of daarmee verband houdende veiligheidsmaatregelen; wanneer persoonlijke aspecten worden geëvalueerd, om met name beroepsprestaties, economische situatie, gezondheid, persoonlijke voorkeuren of interesses, betrouwbaarheid of gedrag, locatie of verplaatsingen te analyseren of te voorspellen, teneinde persoonlijke profielen op te stellen of te gebruiken; wanneer persoonsgegevens van kwetsbare natuurlijke personen, met name van kinderen, worden verwerkt; of wanneer de verwerking een grote hoeveelheid persoonsgegevens betreft en gevolgen heeft voor een groot aantal betrokkenen.
Al bij al is de hele wetgeving een hele boterham en lijkt het toch op een sterke bijkomende administratieve last op de schouders van (vooral de kleine) ondernemers.

Acties:
  • 0 Henk 'm!

  • BCC
  • Registratie: Juli 2000
  • Laatst online: 18:08

BCC

Er wordt gekeken naar uitstel voor kleinere ondernemingen? Hoorde ik van de week een keer op BNR. Maar dan weet je ook dat alle grote bedrijven een BV afsplitsen en die tot "verantwoordelijke" entiteit bombareren, dus het lijkt me geen goed plan. Dat zie je nu ook al bij toeleveranciers van ziekenhuizen. Ziekenhuis dwingt een bewerkersovereenkomst af met idiote boeteclausules. Resultaat is veel schild BVs tussen de leverancier en het ziekenhuis....

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.


Acties:
  • 0 Henk 'm!

Verwijderd

Ik betwijfel sterk dat een grote onderneming zich ervan af kan maken met het afsplitsen van ... ja van wat eigenlijk? Zijn klantenbestand?
Alles en iedereen die iets met persoonsgegevens doet (dus letterlijk ELKE onderneming) valt onder gdpr.

Acties:
  • 0 Henk 'm!

  • Lethalis
  • Registratie: April 2002
  • Niet online
Anoniem: 696166 schreef op dinsdag 16 januari 2018 @ 10:26:
[...]
De GDPR maakt zeer duidelijk en ondubbelzinnig een uitzondering voor gegevens die omwille van wettelijke redenen moeten bijgehouden worden. Facturatiegegevens vallen hier onder en moeten (mogen!) dus NIET verwijderd worden.
Maar stel je houdt een telefoonnummer en / of e-mailadres van een klant bij in een debiteurenadministratie. Wat moet je daar dan mee?

De reden dat ik hier nu op reageer, is omdat toevallig vandaag 2 klanten van ons zijn begonnen over de nieuwe wet en eentje heeft zelfs al een overeenkomst naar ons gestuurd waarin wij de "Verwerker" zijn (in verband met het gebruik van onze software waar hij zijn klantgegevens dus in beheert). Zichzelf wijst hij als "Verwerkingsverantwoordelijke" aan.

Voor zover ik het begrijp, valt alle verantwoordelijkheid voor het verkrijgen van toestemming e.d. dus onder zijn rol. En moeten wij aan allerlei eisen voldoen op het vlak van gegevensbeveiliging. Daarnaast moet onze software bepaalde functionaliteit bevatten om gegevens te verwijderen, in te zien, enzovoorts.

Maar voor de rest is het nog vrij onduidelijk. Sowieso zijn we maar een kleine onderneming die software maakt (lees amper 10 man) en zijn er op dit gebied geen dingen officieel geregeld hier. Er is geen informatiebeveiligingsbeleid of wat dan ook.

De vraag is echter ook wat we hiermee aan moeten. Want we houden geen gevoelige gegevens vast. En de gegevens die we vastleggen zijn echt puur voor de facturering en debiteurenadministratie. Verder dan NAW + e-mailadres en telefoonnummer gaat het niet.

Ask yourself if you are happy and then you cease to be.


Acties:
  • 0 Henk 'm!

Verwijderd

Lees mijn voorlaatste post: wat je beschrijft valt onder gerechtvaardigd belang.
Jullie zijn verwerkers (processor) en je klanten verwerkingsverantwoordelijke (controller). Beide groepen moeten aan bepaalde vereisten voldoen

Acties:
  • 0 Henk 'm!

  • Lethalis
  • Registratie: April 2002
  • Niet online
Verwijderd schreef op vrijdag 2 februari 2018 @ 22:10:
Lees mijn voorlaatste post: wat je beschrijft valt onder gerechtvaardigd belang.
Jullie zijn verwerkers (processor) en je klanten verwerkingsverantwoordelijke (controller). Beide groepen moeten aan bepaalde vereisten voldoen
Het is mij alleen niet duidelijk aan welke eisen wij - als verwerker - moeten voldoen.

Heb je daar nog meer informatie over?

PS
Onze software staat lokaal bij de klant op zijn eigen hardware, dus de gegevens staan niet bij ons. Het is dus offline. Maakt dit nog uit?

[ Voor 12% gewijzigd door Lethalis op 03-02-2018 20:51 ]

Ask yourself if you are happy and then you cease to be.


Acties:
  • 0 Henk 'm!

  • The Lord
  • Registratie: November 1999
  • Laatst online: 15:28
Lethalis schreef op zaterdag 3 februari 2018 @ 20:43:
[...]
Het is mij alleen niet duidelijk aan welke eisen wij - als verwerker - moeten voldoen.
De verantwoordelijke moet aan de wet voldoen; jullie als software leverancier moeten dit m.b.t. de software faciliteren. Anders heb je geen bestaansrecht meer; maakt wat dat betreft niet uit of het cloud of onpremise is.

Als verantwoordlijke verzoek tot vergeten krijgt dan zal alle data die niet vanwege rechtsredenenen bewaart dient te worden verwijdert moeten worden betreffende de betrokkene. B.v. dat wat nodig is voor een sluitende boekhouding moet je dus wel bewaren.

â›”geeft geen inhoudelijke reacties meerâ›”


Acties:
  • 0 Henk 'm!

  • BCC
  • Registratie: Juli 2000
  • Laatst online: 18:08

BCC

Lethalis schreef op zaterdag 3 februari 2018 @ 20:43:
[...]

Het is mij alleen niet duidelijk aan welke eisen wij - als verwerker - moeten voldoen.

Heb je daar nog meer informatie over?

PS
Onze software staat lokaal bij de klant op zijn eigen hardware, dus de gegevens staan niet bij ons. Het is dus offline. Maakt dit nog uit?
Kunnen we in dit topic even de termen Sub-bewerker en Bewerker en Verantwoordelijke hanteren zoals in de wet? Anders word de discussie wel erg ingewikkeld :D - Oh ik zie dat heel veel mensen bewerker verwerker noemen :?

Als software leverancier ben jij meestal een bewerker/subbewerker. In die rol wil jij nooit verantwoordelijk gehouden worden voor de data van je klanten (de verantwoordelijken). Jullie acties en afspraken met je klant (zoals een bewerkersovereenkomst afsluiten) moeten hiermee in lijn zijn. Als je je als bewerker namelijk gaat gedragen als verantwoordelijke, dan ben je volgens de wet ook verantwoordelijk.

Globaal gezien zijn er eigenlijk drie zaken die je als bewerker moet doen:
1) In kaart brengen welke data je hebt, waarom en een opruim beleid hebben. Dit zijn de zogenaamde Privacy Impact Assesments (PIA). Dit moet je eigenlijk elk jaar checken met je accountant.
2) Een procedure hebben om je klanten (de verantwoordelijken) te informeren als er zich een incident heeft voorgedaan bij jezelf of een subbewerker en ALLES documenteren als dit gebeurd.
3) Een procedure hebben om datalekken waarbij jezelf verantwoordelijke bent te administreren en eventueel te melden aan het AP. Hiermee bedoel ik de situatie waar je bijvoorbeeld een eigen CRM of HR pakket hebt waar een incident mee plaatsvind.

Of de software on- of offline staat maakt niet uit. Als je een fout vind die mogelijk een incident kan opleveren bij de klant, zul je hem dat moeten melden en zelf moeten administreren dat jij het gemeld hebt volgende de bestaande richtsnoer procedures.

Nou zal jullie klant (de verantwoordelijke) officieel zelf een Pia moeten doen en dan aan jullie opdracht gaan geven om bepaalde missende features te implementeren in jullie software om zaken als recht om vergeten te worden ed af te dekken. De praktijk is meestal echter dat de leverancier meer begrijpt van het proces dan de klant. Het is dus (zoals genoemd) slim om die features alvast te bouwen om zo je klant te helpen, maar je moet dus erg oppassen dat jij hierbij niet teveel verantwoordelijkheid naar je toetrekt.

[ Voor 17% gewijzigd door BCC op 07-02-2018 13:32 ]

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.


Acties:
  • 0 Henk 'm!

  • BCC
  • Registratie: Juli 2000
  • Laatst online: 18:08

BCC

Dit kom ik helaas ook steeds mer tegen: Cyberverzekering, ervaringen? :(

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.


Acties:
  • 0 Henk 'm!

  • Sunnie
  • Registratie: April 2006
  • Laatst online: 25-07 17:29
BCC schreef op woensdag 7 februari 2018 @ 12:20:
[...]


Kunnen we in dit topic even de termen Sub-bewerker en Bewerker en Verantwoordelijke hanteren zoals in de wet? Anders word de discussie wel erg ingewikkeld :D - Oh ik zie dat heel veel mensen bewerker verwerker noemen :?

Als software leverancier ben jij meestal een bewerker/subbewerker. In die rol wil jij nooit verantwoordelijk gehouden worden voor de data van je klanten (de verantwoordelijken). Jullie acties en afspraken met je klant (zoals een bewerkersovereenkomst afsluiten) moeten hiermee in lijn zijn. Als je je als bewerker namelijk gaat gedragen als verantwoordelijke, dan ben je volgens de wet ook verantwoordelijk.

Globaal gezien zijn er eigenlijk drie zaken die je als bewerker moet doen:
1) In kaart brengen welke data je hebt, waarom en een opruim beleid hebben. Dit zijn de zogenaamde Privacy Impact Assesments (PIA). Dit moet je eigenlijk elk jaar checken met je accountant.
2) Een procedure hebben om je klanten (de verantwoordelijken) te informeren als er zich een incident heeft voorgedaan bij jezelf of een subbewerker en ALLES documenteren als dit gebeurd.
3) Een procedure hebben om datalekken waarbij jezelf verantwoordelijke bent te administreren en eventueel te melden aan het AP. Hiermee bedoel ik de situatie waar je bijvoorbeeld een eigen CRM of HR pakket hebt waar een incident mee plaatsvind.

Of de software on- of offline staat maakt niet uit. Als je een fout vind die mogelijk een incident kan opleveren bij de klant, zul je hem dat moeten melden en zelf moeten administreren dat jij het gemeld hebt volgende de bestaande richtsnoer procedures.

Nou zal jullie klant (de verantwoordelijke) officieel zelf een Pia moeten doen en dan aan jullie opdracht gaan geven om bepaalde missende features te implementeren in jullie software om zaken als recht om vergeten te worden ed af te dekken. De praktijk is meestal echter dat de leverancier meer begrijpt van het proces dan de klant. Het is dus (zoals genoemd) slim om die features alvast te bouwen om zo je klant te helpen, maar je moet dus erg oppassen dat jij hierbij niet teveel verantwoordelijkheid naar je toetrekt.
Het lijkt me beter om in dat geval dan de terminologie van de nieuwe wetgeving te hanteren en niet die van de (oude) Wbp. De mensen in dit topic die bewerker verwerker noemen hebben namelijk gelijk, onder de nieuwe wetgeving heet een bewerker (Wbp) een verwerker. Voor de duidelijkheid:

Verantwoordelijke (Wbp) wordt verwerkingsverantwoordelijke (AVG)
Bewerker (Wbp) wordt verwerker (AVG)
Bewerkersovereenkomst (Wbp) wordt verwerkersovereenkomst (AVG)

Acties:
  • 0 Henk 'm!

  • valkenier
  • Registratie: Maart 2000
  • Laatst online: 26-07 16:48
Als bestuur van een kleine sportvereniging krijgen we hier ook mee te maken. Het overkoepelende verbond heeft bij de stichting AVG een soort online tool afgenomen, waarmee je kunt checken of je vereniging AVG proof is en waar je aan moet voldoen. Als je dat leest wordt je toch een tikje moedeloos. Documenteren, protocollen, geheimhoudingsverklaringen. Waar ze kleine verenigingen mee opzadelen zeg. Het gaat op die site tot aan het advies om vooral je webcam af te plakken "omdat cybercriminelen die zouden kunnen hacken" OMG.

Acties:
  • +1 Henk 'm!

  • Killjoy
  • Registratie: November 2000
  • Laatst online: 18:09

Killjoy

Klingon lawn products

Lethalis schreef op zaterdag 3 februari 2018 @ 20:43:
[...]

Het is mij alleen niet duidelijk aan welke eisen wij - als verwerker - moeten voldoen.

Heb je daar nog meer informatie over?

PS
Onze software staat lokaal bij de klant op zijn eigen hardware, dus de gegevens staan niet bij ons. Het is dus offline. Maakt dit nog uit?
Jazeker. Je bent geen Verwerker wanneer de software en het datawarehouse staan bij de klant (verwerkingsverantwoordelijke) en geen enkele van de door jullie geleverde diensten (zoals functioneel beheer, applicatiebeheer, databasebeheer, e.d) ertoe leidt dat je toegang hebt tot de opgeslagen persoonsgegevens. Dan ben je alleen een leverancier van software.

Maar je bent er natuurlijk wel voor verantwoordelijk dat de software AVG-compliant is ontwikkeld. Denk aan privacy by design/default, passende beveiligingsmaatregelen als encryptie van gevoelige gegevens, autorisatiestructuren conform 'need to know' principe e.d.

Denk er trouwens ook aan dat je van je klanten ook persoonsgegevens beheert ten behoeve van CRM-doeleinden. Dat is in het gerechtvaardigd belang van jullie zelf. Daarvoor ben je dus Verwerkingsverantwoordelijk.

[ Voor 9% gewijzigd door Killjoy op 08-02-2018 13:12 ]

Het is den ambtenaar verboden gedurende den werktijd alcoholhoudende dranken te gebruiken, bij zich te hebben of in de dienstlokalen te bewaren.


Acties:
  • 0 Henk 'm!

  • jfeelders
  • Registratie: Januari 2001
  • Laatst online: 25-07 06:51

jfeelders

Kwaliteit voor kwantiteit...

Valt een hostingprovider waar je je site/userdatabase geplaatst hebt en die verder niets doet met die gegevens ook onder een verwerker waar dus een verwerkersovereenkomst mee afgesloten moet worden? Ik zie daar nergens iets over staan...

Acties:
  • 0 Henk 'm!

  • F_J_K
  • Registratie: Juni 2001
  • Niet online

F_J_K

Moderator CSA/PB

Front verplichte underscores

Ja, als je site enige persoonsgegevens kan verwerken.

'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind' (Terry Pratchett, Eric)


Acties:
  • 0 Henk 'm!

  • jfeelders
  • Registratie: Januari 2001
  • Laatst online: 25-07 06:51

jfeelders

Kwaliteit voor kwantiteit...

De leden en admins kunnen persoonsgegevens invoeren, opslaan, weergeven, wijzigen, nieuwsbrieven versturen naar. De hosting provider verwerkt geen persoonsgegens maar biedt enkel een service om data op te slaan. Volgens https://ictrecht.nl/2015/...-niet-en-wat-zet-je-erin/ lijkt er dan geen verwerkersovereenkomst met de hosting provider nodig te zijn. De vraag is misschien: wat valt onder de term 'verwerken'?

[ Voor 73% gewijzigd door jfeelders op 10-02-2018 22:12 ]


Acties:
  • +1 Henk 'm!

  • The Lord
  • Registratie: November 1999
  • Laatst online: 15:28
jfeelders schreef op zaterdag 10 februari 2018 @ 21:55:
De hosting provider verwerkt geen persoonsgegens maar biedt enkel een service om data op te slaan.
Als je voldoende maatregelen neemt zou dit mogelijk zijn. Maar ik gok erop dat dit niet het geval is; de provider kan dus de data kan lezen, muteren, vernietigen, etc. en is daarmee een verwerker in de zin van de wet.

â›”geeft geen inhoudelijke reacties meerâ›”


Acties:
  • +1 Henk 'm!

Verwijderd

Een hoster is volgens mij altijd een verwerker.
Volgens de GDPR worden IP adressen al als persoonsgegevens beschouwd (http://privacylawblog.fie...constitute-personal-data/ : It's been made clear in the General Data Protection Regulation ("GDPR") that IP addresses should be considered as personal data as the text includes "online identifier", in the definition of "personal data". Recital 30 clarifies that "online identifier" includes IP addresses). Einde discussie.
Een contactformulier: persoonsgegevens
inschrijving nieuwsbrief: persoonsgegevens

[ Voor 30% gewijzigd door Verwijderd op 21-02-2018 14:07 ]


  • CasGas
  • Registratie: November 1999
  • Laatst online: 23-07 15:44

CasGas

.

Weet iemand eigenlijk wel hoe hard het is dat je per mei voldoet aan die wetgeving?

Zoals persoonsgegevens mailen, dat zou beveiligd moeten volgens de wetgeving, maar is dat op die datum ook een harde eis, of als je laat zien dat je er wel mee bezig bent dat het dan ook goed is?

Volgens de wetgeving moet het "state of the art" zijn, maarja, dat is per bedrijf ook wel verschillend. Een bank heeft daar een andere definitie van dan een mkb bedrijf met 5 man lijkt mij zo, als je het al kan definiëren.

Is er bijvoorbeeld ook een soort grace period, of zitten we daar eigenlijk al in en moet iedereen nu opeens gaan rennen omdat het nu wel heel dichtbij komt?

Sony A7III | Sony a6300 | Sony ZV-E1 | 12 2.0 | 21 1.4 | 24 1.4 | 35 2.8 | 50 1.4 | 135 1.8 | 16-28 2.8 | 16-70 4 | 28-75 2.8


  • Orion84
  • Registratie: April 2002
  • Laatst online: 18:13

Orion84

Admin General Chat / Wonen & Mobiliteit

Fotogenie(k)?

Die grace period was dus de afgelopen paar jaar (exacte periode weet ik zo niet). De wet is namelijk al van kracht, alleen wordt er pas vanaf mei gehandhaafd.

Overigens verwacht ik wel dat boetes niet zwart-wit zullen zijn in de trant dat als je niet perfect alles op orde hebt dat je dan direct de maximale boete krijgt. Als je het deels op orde hebt en een plan kan laten zien om het verder op orde te brengen vermoed ik dat je een lagere (of geen of voorwaardelijke) boete krijgt.

The problem with common sense is that it's not all that common. | LinkedIn | Flickr


Verwijderd

Zoals persoonsgegevens mailen, dat zou beveiligd moeten volgens de wetgeving,
Waar staat dat?
en wat bedoel je er eigenlijk mee?
maar is dat op die datum ook een harde eis, of als je laat zien dat je er wel mee bezig bent dat het dan ook goed is?
nee, je moet je documentatie en procedures op orde hebben
Volgens de wetgeving moet het "state of the art" zijn, maarja, dat is per bedrijf ook wel verschillend. Een bank heeft daar een andere definitie van dan een mkb bedrijf met 5 man lijkt mij zo, als je het al kan definiëren.
zeer terechte opmerking. Wat is state of the art?
Het zal erop neerkomen dat een rechter zal belissen of hieraan voldaan werd of niet in het geval er al problemen waren opgetreden,
Is er bijvoorbeeld ook een soort grace period, of zitten we daar eigenlijk al
Die grace period is 2 jaar geleden begonnen bij de oorspronkelijke publicatie van de verordening....
25 mei is de harde start van de GDPR.

  • The Lord
  • Registratie: November 1999
  • Laatst online: 15:28
Verwijderd schreef op donderdag 22 februari 2018 @ 11:55:
Waar staat dat?
en wat bedoel je er eigenlijk mee?
Grappig en vermoeiend; die discussie komt altijd weer op tafel. Persoonsgegevens moeten adequaat beveiligd worden (al voordat de GDPR op 25 mei 2016 in werking trad overigens).
E-mail is zonder aanvullende maatregelen onveilig. Tref je de juiste maatregelen dan mag je best een persoonsgegeven per e-mail versturen.
nee, je moet je documentatie en procedures op orde hebben
Per 25 mei 2018 wordt de GDPR gehandhaafd. Dus je kan zo een dwingende aanwijzing krijgen als je een persoonsgeven per e-mail verstuurd zonder afdoende (aanvullende) maatregelen. Als dan blijkt dat op basis van het advies 'nee, je moet je documentatie en procedures op orde hebben' lijkt het mij zeer aannemelijk (imho ook terecht) als er vervolgens een boete wordt opgelegd. Dat de verantwoordlijke deze vervolgens verhaald op de adviseur lijkt me een logische volgende stap.
zeer terechte opmerking. Wat is state of the art?
Het zal erop neerkomen dat een rechter zal belissen of hieraan voldaan werd of niet in het geval er al problemen waren opgetreden,
Ik kom regelmatig tegen dat een bedrijf als product een webapplicatie aanbiedt, maar nog nooit van OWASP heeft gehoord. Vaak worden er, niet gehinderd door enige kennis, want dat is te duur, bad-practices toegepast waar de standaard good-practice al sinds jaar en dag duidelijk beschreven staat.
In zo een geval kun je best gaan procederen tegen de opgelegde boete, maar de kans van slagen zal dan heeeeel klein zijn.
En zo zijn er veel meer 'de-facto' standaarden, regelgeving in de branche en specifiekere wetgeving (b.v. voor medische gegevens).

â›”geeft geen inhoudelijke reacties meerâ›”


Acties:
  • +1 Henk 'm!

Verwijderd

The Lord schreef op donderdag 22 februari 2018 @ 12:22:
[...]
Persoonsgegevens moeten adequaat beveiligd worden (al voordat de GDPR op 25 mei 2016 in werking trad overigens).
E-mail is zonder aanvullende maatregelen onveilig. Tref je de juiste maatregelen dan mag je best een persoonsgegeven per e-mail versturen.
maar wat is dan een "juiste maatregel" in het geval van persoonsgegevens via email?
...Als dan blijkt dat op basis van het advies 'nee, je moet je documentatie en procedures op orde hebben' lijkt het mij zeer aannemelijk (imho ook terecht) als er vervolgens een boete wordt opgelegd.
die begrijp ik niet.... je doet uitschijnen dat ik verkeerd was, waarom? Wat is volgens jou dan wel de juiste stelling? Dat je je documentatie en procedures niet op orde moet hebben?
Dat de verantwoordlijke deze vervolgens verhaald op de adviseur lijkt me een logische volgende stap.
Begrijp ik goed dat je nu beweert dat iemand een persoonlijke boete voor een fout die helemaal onder zijn verantwoordelijkheid valt kan verhalen op een anonieme persoon op het internet omdat die iets zou gezegd hebben waaruit de boete zou kunnen voortgekomen zijn?
Let the judge decide....
Ik kom regelmatig tegen dat een bedrijf als product een webapplicatie aanbiedt, maar nog nooit van OWASP heeft gehoord. Vaak worden er, niet gehinderd door enige kennis, want dat is te duur, bad-practices toegepast waar de standaard good-practice al sinds jaar en dag duidelijk beschreven staat.
In zo een geval kun je best gaan procederen tegen de opgelegde boete, maar de kans van slagen zal dan heeeeel klein zijn.
En zo zijn er veel meer 'de-facto' standaarden, regelgeving in de branche en specifiekere wetgeving (b.v. voor medische gegevens).
Niemand zal tegenspreken dat het gebruik van een php 3.0 mysql extension zonder filtering van de input een probleem is. Maar er is een gigantisch grote grijze zone tussen dit en een server aflsuiten van de buitenwereld in fort knox.
Uiteindelijk zullen rechtzaken hier gaan beslissen wat wel en niet moet en mag.

Verwijderd

PS
Onze software staat lokaal bij de klant op zijn eigen hardware, dus de gegevens staan niet bij ons. Het is dus offline. Maakt dit nog uit?
Het lijkt me dat dit zeer zeker uitmaakt.
Jullie zijn leverancier van software maar komen niet met de data de klanten in die software ingeven in contact. Jullie zijn uiteraard verantwoordelijk voor de veiligheid en functionaliteit van de software, maar jullie zijn geen dataprocessor, net zomin als mozilla een dataprocessor is omdat ik via hun software mijn (of misschien iemand anders) persoonsgegevens ingeef op verschillende websites en net zomin als microsoft een dataprocessor is omdat ik brieven met persoonsgegevens opmaak in mijn (offline) word 2007 en statistieken bijhoud met persoonsgegevens in excel (wel natuurlijk als ik gebruik zou maken van hun cloud diensten).
Als jullie op een of andere manier met de data in contact komen (backups op jullie server bijvoorbeeld) verandert dat de zaak volledig.

Acties:
  • 0 Henk 'm!

Anoniem: 696166

Topicstarter
hallo allen, ik ben blij dat ik blijkbaar niet alleen ben in mijn worsteling met de gdpr....
Ik blijf met een aantal vragen zitten. Er wordt in den treure herhaald dat er "consent" moet zijn voor gegevensverwerking, maar in veel gevallen is dat toch totaal niet werkbaar?
Wat als iemand mij belt of mailt (gegevens gevonden via een website) en met mij een afspraak maakt voor een vergadering. Mag ik die persoon zijn gegevens in een agenda noteren? Of moet ik eerst een mail sturen (mag niet, want ik heb geen toestemming om zijn emailadres te verwerken!) vragen van hem waarin hij me de toestemming geeft? Dat is toch totaal niet haalbaar en kan nooit de bedoeling zijn?
In het document van de belgische privacycommissie staat:
de toestemming kan niet worden afgeleid uit een stilzwijgen, een vooraf aangevinkt vakje of uit een niet-handelen
en ook
de verwerkingsverantwoordelijke in staatmoet zijn om aan te tonen dat toestemming werd gegeven.
hoe past dit in mijn gegevensverwerking in de agenda?

Acties:
  • 0 Henk 'm!

  • BCC
  • Registratie: Juli 2000
  • Laatst online: 18:08

BCC

Hoe ik het zou doen:
Je schrijft een PIA waarin je alle sales activiteiten omschrijft + bijbehorende data. Mensen die bellen voor een afspraak is daar een scenario van. De procedure is bijvoorbeeld dat je de gegevens noteert in je CRM / outlook agenda / whatever, want dat is aantoonbaar nodig voor je normale bedrijfsprocedure. Hierbij geef je aan HOE de gegevens in het CRM zijn gekomen.

Vervolgens moet je zorgen dat er een procedure is, welke zorgdraagt dat deze data na een bepaalde tijd vernietigd wordt. Misschien wordt het namelijk helemaal geen klant of wil deze persoon niet meer in jullie systeem voorkomen.

Mocht er ooit een rechtzaak komen, dan heb je een procedure en moet je voor kan leggen aan het AP, die deze gaat toetsen op redelijkheid.

Als je je meer wil indekken, kun je een nieuwe lead ook expliciet aangeven dat je hem/haar in je CRM gaat opnemen als lead en kun je eventueel de procedure toelichten.

[ Voor 14% gewijzigd door BCC op 28-02-2018 16:14 ]

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.


Acties:
  • +1 Henk 'm!

Verwijderd

Een PIA is (meestal) niet nodig voor zoiets. Het volstaat om het in je dataregister te noteren.
PIA is enkel nodig in specifieke gevallen (het wordt aangeraden door de privacycommisies om het altijd te doen maar het is geen verplichting volgens de gdpr, uitgezonderd bepaalde gevallen met hoog risico).
Toestemming is niet nodig omdat het onder een ander item kan gecategoriseerd worden: gerechtvaardigd gebruik. Dat is een parapluterm waar veel misbruik van zal gemaakt worden en die vaak te onpas zal gebruikt worden, maar ik denk dat er in dit geval weinig tegen in te brengen is dat het hier inderdaad van toepassing is.

Acties:
  • 0 Henk 'm!

  • ElectricHead
  • Registratie: Maart 2002
  • Laatst online: 14-07 17:59

ElectricHead

Xbox Live: Gortoth666

Ik zit me nu al een paar dagen in te lezen in de AVG. Man man man, wat een droge kost. Lekkere duidelijke omschrijvingen ook op de site van de AP...... Goed ouderwetsch Nederlands, zullen we maar zeggen. :)

Als MKB'er/ondernemer wordt ik een beetje gek van deze regeltjes. Dan denk ik dat ik iets heb wat voldoet, maar dan bedenk ik me ineens dat er best wel een aantal bedrijven (lees callcenters) zijn die mij informatie toe sturen om met mijn klanten in contact te gaan komen.

Om even te verduidelijken. Wij hebben een glaszet bedrijf en we werken voor particulieren, verzekeringen en woningbouwverenigingen. Ik keek eerst ui alleen mezelf hoe we de gegevens binnen krijgen en ineens bedenk ik me: Hoe zit dat met de informatie die ik via de woningbouw e.d. krijg?
Ik kan dit omschrijven uiteraard in een document, maar moeten zij niet ook op een bepaalde manier aan die regels gaan voldoen? En wat houdt dit in voor mij? Ben ik dan een verwerker?

Snap wel dat men vind dat je hier op tijd mee moet beginnen. God allemachtig.

Do, or do not. There is no try. - Master Yoda


Acties:
  • 0 Henk 'm!

Verwijderd

Hoe ik het nu begrijp:
- Data Processor / Verwerker: degene die data beheert voor iemand, vb.: microsoft, google, salesforce, alle andere cloudgebaseerde diensten waar andere data in kunnen geven
- Data Controller / verantwoordelijke: degene die de data ingeeft, opslaat, gebruikt: jij
Als je de data van een andere instantie krijgt ben jij de verantwoordelijke. Die andere instantie vermoedelijk ook.

Acties:
  • 0 Henk 'm!

  • BCC
  • Registratie: Juli 2000
  • Laatst online: 18:08

BCC

Eeh, dat is wat koet door de bocht :) je kan voor sommige processen verantwoordelijke zijn en voor andere bewerker. Het hangt van de relatie af die je hebt tov de data en of je je ook gedraagd zoals je in die relatie mag verwachten.

En deze is nuttig voor het mkb http://ec.europa.eu/justice/smedataprotect/index_en.htm

[ Voor 75% gewijzigd door BCC op 28-02-2018 19:01 ]

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.


Acties:
  • 0 Henk 'm!

Verwijderd

ja dat wilde ik ook zo zeggen.
verwerker: verwerkt de data voor iemand anders
controller: is die iemand anders waarvoor de data wordt verwerkt. De controller kan ook verwerker zijn natuurlijk.

Acties:
  • 0 Henk 'm!

  • The Lord
  • Registratie: November 1999
  • Laatst online: 15:28
Verwijderd schreef op donderdag 22 februari 2018 @ 13:00:
maar wat is dan een "juiste maatregel" in het geval van persoonsgegevens via email?
Tsja, dat hangt er van af... Versleutelen om vetrouwelijkheid te waarborgen is wel het minimale. En dat kan op heel veel manieren bereikt worden.
die begrijp ik niet.... je doet uitschijnen dat ik verkeerd was, waarom? Wat is volgens jou dan wel de juiste stelling? Dat je je documentatie en procedures niet op orde moet hebben?
Hmm, dat kan mijn interpretatie van de zin zijn. :) In de praktijk wordt met 'documentatie en procedures op orde' veel te vaak een papieren werkelijkheid bedoeld; met andere woorden het staat er wel, maar men werkt niet zo.
Begrijp ik goed dat je nu beweert dat iemand een persoonlijke boete voor een fout die helemaal onder zijn verantwoordelijkheid valt kan verhalen op een anonieme persoon op het internet omdat die iets zou gezegd hebben waaruit de boete zou kunnen voortgekomen zijn?
Let the judge decide....
Ja! >:)
Nou, ik bedoel het in een iets directere advies relatie dan dat. Desalniettemin; zou het gaan om een expert (geldt ook hier voor het forum) en er wordt direct op een casus geadviseerd dan is dat zo gek nog niet.
Niemand zal tegenspreken dat het gebruik van een php 3.0 mysql extension zonder filtering van de input een probleem is. Maar er is een gigantisch grote grijze zone tussen dit en een server aflsuiten van de buitenwereld in fort knox.
Uiteindelijk zullen rechtzaken hier gaan beslissen wat wel en niet moet en mag.
Ik denk dat je voorbeeld eerder riching strafrechterlijke vervolging kan gaan in geval van een aanzienlijk datalek. Dat is zo ongeveer zo laakbaar als mensen aan het hart gaan opereren thuis, omdat je een scalpel hebt gekocht; of zoiets. >:)

Ik verwacht dat een hoop juist niet voor een rechter gaat komen; daar waar industire geaccepteerde best- good en badpractices zijn zal een gang naar de rechter met grote waarschijnlijkheid resulteren in een boete i.p.v. een last onder dwangsom c.q. dwingende aanwijzing. Dan moet je wel een redelijk bord voor je kop hebben denk je toch nog je gelijk te gaan halen.

De echt grijze vlakken zal zeker juriprudentie laten ontstaan, maar ik zie dit voorlopig eerder bij de grote data-afhankelijke bedrijven gaan gebeuren.

â›”geeft geen inhoudelijke reacties meerâ›”


Acties:
  • +1 Henk 'm!

  • Killjoy
  • Registratie: November 2000
  • Laatst online: 18:09

Killjoy

Klingon lawn products

Verwijderd schreef op woensdag 28 februari 2018 @ 19:02:
ja dat wilde ik ook zo zeggen.
verwerker: verwerkt de data voor iemand anders
controller: is die iemand anders waarvoor de data wordt verwerkt. De controller kan ook verwerker zijn natuurlijk.
Het klinkt simpel, maar in de praktijk kan het behoorlijk complex zijn. De verwerkingsverantwoordelijke (controller) is degene die de doeleinden en de middelen van de verwerking bepaalt. Een ingeschakelde derde partij is verwerker (data processor) wanneer deze persoonsgegevens verwerkt voor de verwerkingsverantwoordelijke, maar dat doet dat in grote lijnen zoals opgedragen door de verwerkingsverantwoordelijke. De afspraken zijn vastgelegd in een verwerkersovereenkomst.

In de praktijk zie je vaak dat de verwerker een mate van vrijheid hebben om hun eigen werkzaamheden in te richten. Hoe groter de keuzevrijheid, des de groter de kans dat een verwerker zich feitelijk gedraagt als (mede)verwerkingsverantwoordelijke. Waarbij de vraag moet worden gesteld of dit al dan niet terecht is.

Overigens is een verwerker altijd verwerkingsverantwoordelijke voor de zogenaamde 'eigen werkzaamheid'. Daaronder vallen in ieder geval bedrijfsvoeringsactiviteiten, zoals personeelsbeheer e.d.

Het is den ambtenaar verboden gedurende den werktijd alcoholhoudende dranken te gebruiken, bij zich te hebben of in de dienstlokalen te bewaren.


Acties:
  • 0 Henk 'm!

Anoniem: 1049233

Knip, dit is zo spam.

[ Voor 97% gewijzigd door F_J_K op 07-03-2018 20:55 ]


Acties:
  • 0 Henk 'm!

  • zoenvisje
  • Registratie: April 2010
  • Laatst online: 12-12-2024
Anoniem: 1049233 schreef op woensdag 7 maart 2018 @ 14:10:


- Hoe u kunt bepalen waar content zich bevindt, wat het is en hoe waardevol het is;
- Welke voorbereiding u moet treffen om content eenvoudig te verplaatsen;
- Een best practice aanpak voor het verplaatsen en opschonen van uw content;
- Hoe u de waarde van uw huidige content landschap kunt vergroten;
- Tips en tricks voor een roadmap naar een gezond en GDPR compliant content landschap;
Op zich interessant maar het oogt niet zo diepgaand?

Acties:
  • 0 Henk 'm!

  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 18:11

Jazzy

Moderator SSC/PB

Moooooh!

Omdat het lokkertjes zijn in de hoop dat de bezoekers dit bedrijf vervolgens in de arm nemen voor de uitwerking, bekend concept. :) Gerapporteerd trouwens, volgens mij hoort dit niet op het forum.

Zelf heb ik me beroepsmatig tot nu toe buiten de GDPR kunnen houden, als IT-er zijn andere collega's hier mee bezig voor deze klant. Grappig genoeg vroeg te voorzitter van onze vereniging mij gisteren of ik voor de vereniging kan gaan meedenken over GDPR. Zal vanaf nu dus gaan meelezen en me hier in verdiepen.

Exchange en Office 365 specialist. Mijn blog.


Acties:
  • 0 Henk 'm!

  • BCC
  • Registratie: Juli 2000
  • Laatst online: 18:08

BCC

Er zijn de wereld aan consultants nu bezig mooie documenten te schrijven en veel koffie-vergaderingen te houden over mogelijke boetes idd.

De crux van dit geheel zit hem volgens mij in het feit dat het precies tussen de Compliancy en de IT afdeling invalt. En dat je ook product owners nodig hebt om echt zinnige dingen te zeggen/doen. Vooralsnog vind ik het erg leuk om praktisch te pionieren in dit onontgonnen gebied :D!

En ik denk dat de wetgeving voor veel burgers en voor veel bedrijven een hele verbetering gaat opleveren.

[ Voor 14% gewijzigd door BCC op 16-03-2018 20:50 ]

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.


Acties:
  • 0 Henk 'm!

  • tc-t
  • Registratie: September 2015
  • Laatst online: 05-04-2021
Ik ben SysAdmin op een (internationaal actief) Belgisch bedrijf en moet tot mijn spijt vaststellen dat de directie de GDPR-wetgeving niet al te serieus neemt.

DPO? Nee hoor, we schrijven zelf wel een memo over alle aspecten die met de nieuwe GDPR wetgeving te maken hebben. (we = voornamelijk de directrice).


Concreet heb ik volgende vraag: we hebben onlangs (2 weken geleden) een nieuwe website gelanceerd, en meteen zijn er ook LinkedIn-, Facebook- en YouTube-accounts aangemaakt. Die hadden we voorheen niet.
Het personeel wordt aanbevolen/gepusht om accounts aan te maken en te connecteren met de bedrijfsprofielen in kwestie. Voor Linked-In compleet met handleiding hoe een account aangemaakt kan worden...

Ik weet ondertussen dat die social media accounts niet door onze eigen medewerkers beheerd worden (had gekund: we hebben een verkoopafdeling en een marketing man) maar door een externe partije: een soort kruising tussen webdesign en marketing bedrijf.

In alle communicatie naar het personeel wordt gesuggereerd (het staat er niet letterlijk) dat het hier om ons bedrijfsaccount gaat, en nergens wordt er ook maar aan gerefereerd dat het eigenlijk om een externe partij gaat.

Los van het feit dat ik dat niet netjes en zelfs misleidend vind, vraag ik me af of ze met de nakende GDPR-regelgeving niet verplicht zijn dat te melden.
Het bedrijf in kwestie ziet toch gegevens/data/contacten die zij anders niet zouden zien, en er wordt door de directie aan onze eigen medewerkers de indruk gewekt dat enkel iemand van ons bedrijf die gegevens ziet, terwijl dat zo niet is.

De directrice weigert tot op heden om algemeen kenbaar te maken wie er achter die accounts zit.
Ze vindt dat op deze vorm van beheer de GDPR-wetgeving niet van toepassing is.

Heeft ze daarin gelijk, of niet:

Ik zie eigenlijk 2 problemen:
* het bedrijf in kwestie krijt zaken te zien die anders niet te zien zouden krijgen
* onze eigen medewerker deelt dus onbewust zaken met een partij waarvan hij/zijn niet eens weet dat ze die informatie te zien krijgen.


Of zie ik het verkeerd?

Acties:
  • +1 Henk 'm!

  • DiedX
  • Registratie: December 2000
  • Laatst online: 26-07 22:33
Gaat het om persoonsgegevens : ja. Worden ze uit vrije wil gegeven : nee. Absoluut onaanvaardbaar.

Ik ga hier zelf wat kort door de bocht heen. Als werkgever heb je een bijzondere relatie: je hebt macht over je werknemer.

Wat hier in het kort gebeurd is dat de werknemer geforceerd wordt om zijn privacy op te geven voor de werkgever. Dit is niet acceptabel, en niet conform AVG.

Het probleem is: wanneer is dat wél het geval? Als een werknemer wéét dat er geen sancties volgen als hij 'nee' zegt, dan is er geen probleem, maar wanneer is dat het geval?

[ Voor 70% gewijzigd door DiedX op 23-03-2018 20:55 ]

DiedX supports the Rolandâ„¢, Sound Blasterâ„¢ and Ad Libâ„¢ sound cards


Acties:
  • 0 Henk 'm!

  • F_J_K
  • Registratie: Juni 2001
  • Niet online

F_J_K

Moderator CSA/PB

Front verplichte underscores

Natuurlijk mag een bedrijf derde partijen inhuren om bepaalde taken uit te voeren. Denk je dat iedere medewerker van een groot bedrijf weet welke partij de boekhouding doet, waar het SaaS HR-systeem draait, wie de mailserver host, etc.? Nee. Wel dient het bedrijf goede afspraken te zijn overeengekomen, incl verwerkersovereenkomst.

Edit, de GDPR is zeker wel van toepassing, natuurlijk. Vraag is alleen welke maatregel / acties nodig zijn.

[ Voor 14% gewijzigd door F_J_K op 23-03-2018 22:21 ]

'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind' (Terry Pratchett, Eric)


Acties:
  • 0 Henk 'm!

  • Killjoy
  • Registratie: November 2000
  • Laatst online: 18:09

Killjoy

Klingon lawn products

De bevoegdheden van een werkgever zijn natuurlijk vrij ruim waar het gaat om het voorschrijven van wat een medewerker wel en niet mag. Ik acht het redelijk dat de werkgever dit kan opleggen aan medewerkers die zich op basis van functie/rol/werkzaamheden bezighouden met externe communicatie. Maar niet als het gaat om binnendienst. Nog los van de vraag of je minder communicatief vaardige medewerkers via social media los wil laten op de klant...

Maar dat gezegd hebbende. Er moet natuurlijk wel aan voorwaarden worden voldaan. En de AVG is hierop zeker van toepassing, aangezien er sprake is van het verwerken van persoonsgegevens.

Allereerst moet er tussen jouw werkgever en het bedrijf in kwestie een verwerkersovereenkomst te zijn gesloten. Die moet o.a. inzicht geven in wat het bedrijf wel en niet mag met de gegevens, welke gegevens er worden verwerkt en afspraken over de beveiliging van die gegevens. En datalekken natuurlijk.

Verder moet natuurlijk worden voldaan aan het transparantiebeginsel. Dat is een recht wat een natuurlijk persoon (dus ook personeel) heeft op grond van de AVG. Dus jullie werknemers dienen vooraf op de hoogte te worden gebracht over deze verwerking van persoonsgegevens (welke gegevens worden er verwerkt, wat is de grondslag, aan wie worden deze gegevens verstrekt, bewaartermijnen, enz.)

Daarbij speelt verder dat het gebruik van de social media accounts ook weer kan worden gemonitord door de werkgever op (on)acceptabel gedrag. In het ernstigste geval kan het een soort personeelvolgsysteem worden. Nu weet ik niet hoe dat in BE zit, maar in NL kan dat niet zonder instemming van de OR.

Verder moet ook worden gekeken naar mogelijke gevolgen voor de medewerker in de privésfeer. Want wat als uitingen via het werkaccount op social media op een of andere wijze gelinkt kunnen worden aan een eventueel privé account?

Mijn advies in deze zou zijn om een PIA / GEB uit te (laten) voeren.

Het is den ambtenaar verboden gedurende den werktijd alcoholhoudende dranken te gebruiken, bij zich te hebben of in de dienstlokalen te bewaren.


Acties:
  • 0 Henk 'm!

  • tc-t
  • Registratie: September 2015
  • Laatst online: 05-04-2021
F_J_K schreef op vrijdag 23 maart 2018 @ 22:01:
Natuurlijk mag een bedrijf derde partijen inhuren om bepaalde taken uit te voeren. Denk je dat iedere medewerker van een groot bedrijf weet welke partij de boekhouding doet, waar het SaaS HR-systeem draait, wie de mailserver host, etc.? Nee.
Nee, daar heb je natuurlijk gelijk. Alleen is het voor niemand een geheim DAT die zaken uitbesteed zijn, en wordt zeker niet gedaan alsof we het zelf doen. Van de meeste zaken is wel geweten welke partij dat voor ons doet: dat heeft ooit in een interne nieuwsmededeling gestaan, o.a. voor het Sociaal Secretariaat, het bedrijf dat de hard-en software voor de urenregistratie levert etc...

Op zich is daar dus inderdaad niks mee, maar IMO wel met deze poging om te doen alsof we het zelf beheren en elke openbaarheid daaromtrent te weigeren.
Killjoy schreef op vrijdag 23 maart 2018 @ 22:20:
Mijn advies in deze zou zijn om een PIA / GEB uit te (laten) voeren.
Dat lijkt me goed advies, maar gaat helaas niet gebeuren. De persoon die het GDPR-gebeuren 'managet' (de directrice) is net diegene die in dit geval de openheid/transaparantie weigert.
Aangezien zij vindt dat er geen probleem is, wordt er verder niks ondernomen.

Een OR hebben we (helaas) niet. Wel een personeelsvertegenwoordiging, maar dat heeft toch veel minder impact.

Acties:
  • +1 Henk 'm!

  • Killjoy
  • Registratie: November 2000
  • Laatst online: 18:09

Killjoy

Klingon lawn products

tc-t schreef op dinsdag 27 maart 2018 @ 12:52:

Dat lijkt me goed advies, maar gaat helaas niet gebeuren. De persoon die het GDPR-gebeuren 'managet' (de directrice) is net diegene die in dit geval de openheid/transaparantie weigert.
Aangezien zij vindt dat er geen probleem is, wordt er verder niks ondernomen.

Een OR hebben we (helaas) niet. Wel een personeelsvertegenwoordiging, maar dat heeft toch veel minder impact.
Tja, zonder DPO / Functionaris voor de Gegevensbescherming lijken jouw mogelijkheden als medewerker dan beperkt. Vraag wordt dan hoever je wil gaat om het goed te krijgen. Als SysAdmin zou het niet heel vreemd zijn om bij jullie Security Officer (niet de directrice hopelijk) eens na te vragen hoe het zit met de overeenkomst met de ingeschakelde partij (ISO 27001:2013. A.15.1 Informatiebeveiliging in leveranciersrelaties en A.15.2 Beheer van dienstverlening van leveranciers)

Probeer zo veel mogelijk een dossier op te bouwen, zodat de schuld iig niet op ICT wordt geschoven.

Het is den ambtenaar verboden gedurende den werktijd alcoholhoudende dranken te gebruiken, bij zich te hebben of in de dienstlokalen te bewaren.


Acties:
  • 0 Henk 'm!

  • BCC
  • Registratie: Juli 2000
  • Laatst online: 18:08

BCC

En als intern aan de kaak stellen niet werkt, zou ik gewoon melding doen bij het Belgische meldpunt.

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.


Acties:
  • 0 Henk 'm!

Anoniem: 1056755

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?

Acties:
  • 0 Henk 'm!

  • DiedX
  • Registratie: December 2000
  • Laatst online: 26-07 22:33
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

DiedX supports the Rolandâ„¢, Sound Blasterâ„¢ and Ad Libâ„¢ sound cards


Acties:
  • 0 Henk 'm!

  • pr0mo
  • Registratie: December 2009
  • Laatst online: 24-07 12:58
Anoniem: 1056755 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).

iracing profiel


Acties:
  • 0 Henk 'm!

  • Yucon
  • Registratie: December 2000
  • Nu online

Yucon

*broem*

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

Acties:
  • 0 Henk 'm!

  • Frogmen
  • Registratie: Januari 2004
  • Niet online
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.

Voor een Tweaker is de weg naar het resultaat net zo belangrijk als het resultaat.


Acties:
  • 0 Henk 'm!

  • F_J_K
  • Registratie: Juni 2001
  • Niet online

F_J_K

Moderator CSA/PB

Front verplichte underscores

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

'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind' (Terry Pratchett, Eric)


Acties:
  • 0 Henk 'm!

  • Killjoy
  • Registratie: November 2000
  • Laatst online: 18:09

Killjoy

Klingon lawn products

Anoniem: 1056755 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.

Het is den ambtenaar verboden gedurende den werktijd alcoholhoudende dranken te gebruiken, bij zich te hebben of in de dienstlokalen te bewaren.


Acties:
  • 0 Henk 'm!

  • Frogmen
  • Registratie: Januari 2004
  • Niet online
@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.

Voor een Tweaker is de weg naar het resultaat net zo belangrijk als het resultaat.


Acties:
  • 0 Henk 'm!

  • Killjoy
  • Registratie: November 2000
  • Laatst online: 18:09

Killjoy

Klingon lawn products

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.

Het is den ambtenaar verboden gedurende den werktijd alcoholhoudende dranken te gebruiken, bij zich te hebben of in de dienstlokalen te bewaren.

Pagina: 1 2 Laatste