[Projectleiding] AVG holadiejee

Tue Jul 23 22:35:31 CEST 2019

Hoi Julius,

Niets moet. Het was slechts een geste om jullie te helpen dingen te kanaliseren. De FG is slechts voor advies, ondersteuning en het contact met de autoriteiten. 

Dat ik geen onderdeel van de projectleiding ben is juist het doel van een FG en wettelijk ook verboden. Een FG mag geen bestuurlijke taken hebben. En ik heb geen enkele behoefte om PL te zijn. 

Wat de regels zijn, is mij bekend. Anders zou ik geen FG kunnen zijn bij meerdere instellingen, waaronder gemeenten. 

De zeven vragen die je stelt zijn maatregelen, maar maken je niet compliant. Bovendien staan er fouten in. Om je een voorbeeld te geven: je bent zelfs verplicht bijzondere persoonsgegevens te verwerken. Denk maar aan de eisen van de GGD en de EHBO vorige keer. 

Kies wat je wilt. Ik heb geen gebrek aan tijdsbesteding. Maar mocht je alles alleen en zelf willen doen: ga nog eventjes wat bijleren.

Brenno de Winter
06-53536508
Beveiliging is geen voodoo. Lees de Survivalgids voor de Digitale Jungle: https://dewinter.com/2019/01/17/survivalgids-voor-de-digitale-jungle-beschikbaar/

> Op 23 jul. 2019, om 22:01 heeft Julius <julius at ifcat.org> het volgende geschreven:
> 
> Hallo Elger,
> 
> Dank voor het meedenken. Wij hoeven geen FG aan te stellen, om de volgende redenen:
> 1. Wij zijn geen organisatie met een publiekelijke taak.
> 2. Wij volgen geen personen of groepen. Hierbij moet tevens duidelijk zijn als IFCAT zijnde, onze kernactiviteit het organiseren van evenementen is en niet het volgen van personen.
> 3. Wij slaan geen bijzondere persoonsgegevens op. Dit wil ook zeggen dat het badge team goed moet opletten dat als ze een bloeddrukmeter op een wearable willen zetten, deze devices opeens een "bijzonder persoonsgegeven" bevatten en daarom aan zwaardere voorwaarden moeten gaan voldoen.
> 
> Daarnaast weet ik niet of het zo verstandig is om een FG aan te stellen: De FG moet namelijk publiekelijk kenbaar worden gemaakt met NAW gegevens, zodat authoriteiten makkelijk en zonder problemen bij deze persoon kunnen aanbellen. De FG moet aan allerlei keurmerken voldoen, om aan te tonen dat wij als "stichting" voldoende kennis in huis hebben om aan te kunnen tonen dat wij aan bovenstaande regels voldoen. Aangezien wij een stichting zijn met 3 personen, geen commerciële doelstelling nastreven, en al helemaal geen nut hebben bij een FG, lijkt het me dit een hoop overkill voor iets waar ik klaarblijkelijk wat meer op moet gaan hameren. Daarnaast is Brenno geen onderdeel van de stichting, wat hem dus een "extern persoon" maakt, en daar zit weer een hoop papierwerk aan vast (waaronder dus contractuele verplichtingen).
> 
> TL;DR: Het aanstellen van een FG kost meer tijd en moeite dan hetgeen het ons oplevert.
> 
> ---
> 
> Wat betreft de "opslag" van gegevens: Ik denk dat we ons meer zorgen moeten maken over de vereisten van de belastingdienst vs. de AVG: Zij vereisen dat wij namelijk voor 7 jaar onze boekhouding bijhouden. Dat betreft dus ook ALLE relevante post die van/naar de stichting worden gestuurd, een kopie van onze website, aanvragen, etc. Gegevens die niet relevant zijn voor de bedrijfsvoering (kopie ID, inloggegevens, etc) moeten direct na gebruik vernietigd worden. Dit is ook de reden waarom ik vraag dat aanvragen zoveel mogelijk via het bestuur lopen: Zo voorkomen we dat informatie overal verspreid wordt opgeslagen en ik het overzicht verlies. En dat wil ook zeggen dat ik soms eisen stel aan bepaalde verzoeken (disclaimer invullen, beperken van het aantal personen dat in een golfwagen mag rondrijden, etc.) en in de gaten moet houden of de informatie nog relevant is voor het doel.
> 
> Wat de overige gevallen betreft: Heb even gecontroleerd, MediaWiki is niet compliant met de AVG. Veel van onze open-source software is niet compliant met de AVG. Van onze websites zijn alleen de frontpages compliant met de AVG. Heck, zelfs de CCC is volgens mij niet compliant met de AVG. Dus als we dit goed willen doen, moet er even goed nagedacht worden en programmeurs geschopt moeten worden met de volgende vragen die we bij elk stuk programmatuur dat we willen gebruiken moeten stellen:
> 1. Welke gegevens moet de gebruiker invoeren, en waarom?
> 2. Heeft de gebruiker expliciet toestemming gegeven dat wij deze informatie mogen verwerken?
> 3. Hoe lang worden deze gegevens opgeslagen? Kan ik de gegevens verwijderen als ze niet meer nodig zijn?
> 4. Is er een exportfunctie voor de gebruiker?
> 5. Kan de gebruiker zijn account verwijderen? Zo niet, kan een admin dit voor hem doen?
> 6. Kan de gebruiker instellen welke gegevens van hem zichtbaar zijn?
> 7. Hoe kan ik de database anonimizeren (archiefwaardig maken)?
> 
> TL;DR: Websites aanpassen zodat deze compliant zijn met de AVG, elke vrijwilliger voorzien van een eigen account, voldoende toegang hebben om eventuele aanvragen/verwijderverzoeken mogelijk te maken, en zorgen dat alles netjes wordt gelogd.
> 
> Met vriendelijke groet,
> 
> Julius
> PS: Kip & ei verhaal: Om te kunnen anonimizeren moet ik weten welke gegevens er allemaal bij ons bekend zijn, en waar deze gegevens staan. In het geval van Finance is dat makkelijk (gegevens op de factuur) maar in alle overige gevallen zal dit enkel IP adres, naam/nickname en emailadres mogen zijn. Voor telefoonnummers moet je toestemming verlenen. Als je bij een mailinglijst wil komen, MOET je eerst toestemming geven dat je gegevens worden gedeeld met anderen, alvorens zijn emails worden doorgestuurd naar de lijst. Mocht je besluiten om je account te verwijderen, kan het zijn dat we alleen je account kunnen verwijderen en niet de mails die je hebt gestuurd naar de mailinglijst (zie archiefwaardig maken).
> 
> On 23-7-2019 16:23, Elger Jonker wrote:
>> Hi Team,
>> 
>> Brenno vroeg of we de AVG scherp hebben. Julius heeft daartoe al wat stappen gemaakt begreep ik. Het lijkt me voor erg handig (ook verplicht) om het helder te hebben welke data wordt verzameld en hoe lang we dat moeten doen / hoe snel we er vanaf kunnen. Als ik er zo over nadenk is het een behoorlijke lijst, en ik weet dat er veel gegevens zijn geanonimiseerd en/of verwijderd van SHA2017.
>> 
>> Twee dingen die ik wil voorleggen:
>> 
>> 1: Brenno geeft aan interesse te hebben in de rol van FG naast de haven (twee dingen bij 1 persoon?). Volgens het AP zijn we niet verplicht een FG te hebben[1], echter iemand die deze rol op zich neemt schept wel duidelijkheid en plaatst het onderwerp.
>> 
>> 2: Julius heeft al wat stappen gezet, @Julius, lijkt het jou wat om in kaart te brengen welke privacygevoelige gegevens we hebben en wat het bereik hiervan is?
>> 
>> Ik heb onderaan de mail een inhoudelijk stukje gezet, dat zette me aan om deze mail te schrijven: het is stiekem best veel.
>> 
>> Groeten,
>> Elger / Stitch
>> 
>> 
>> [1]: https://www.autoriteitpersoonsgegevens.nl/nl/onderwerpen/algemene-informatie-avg/functionaris-gegevensbescherming-fg
>> 
>> 
>> 
>> 
>> ---
>> Inhoudelijk stukje / braindump:
>> 
>> Het is misschien mogelijk een scheiding aan te brengen in verzamelen van verschillende doelgroepen, bijvoorbeeld vrijwilligers en bezoekers.
>> 
>> Plaatsen waar mogelijk persoonsgegevens worden verwerkt:
>> 
>> - Finance: betalingen (rekeninghouder, rekeningnummer, order, adresgegevens in order, nickname evt). Deels zit hier een wettelijke verplichting aan om dit te bewaren. Wordt deels verwerkt door de accountant en de belastingdienst. (wat precies?)
>> - Contactgegevens van vrijwilligers in het angel system. Denk aan telefoonnummer, etc.
>> - ID kaarten van vrijwilligers voor de vergunningsaanvraag, contracten e.d.
>> - Informatie op de publieke wiki's
>> - Informatie van sprekers (wie, contactgegevens etc)
>> - Adresgegevens van vrijwilligers (PL o.a.)
>> - Vallen chatgesprekken hier onder? Dingen die automatisch in IRC logs komen omdat iemand ze in het kanaal zet?
>> - Email berichten, IP adressen die daar in zitten.
>> - IP adressen in de shop, wiki en andere plaatsen (wat mogelijk wisselend beleid heeft ivm risico's)
>> 
>> Verder zijn er natuurlijk teams die veel met mensen moeten werken zoals cohesion, volunteering, safety, security e.d. Ik had begrepen dat deze gegevens zijn geanonimiseerd of vernietigd: dit werd door teams als vanzelfsprekend gezien wat helpt :).
>> _______________________________________________
>> Projectleiding mailing list
>> Projectleiding at lists.ifcat.org
>> https://lists.ifcat.org/mailman/listinfo/projectleiding

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ifcat.org/pipermail/projectleiding/attachments/20190723/c2c80b57/attachment.html>