Moodle HQ heeft een video van bijna 10 minuten ontwikkeld met uitleg hoe deze privacy API geïmplementeerd moet worden. Vooral Moodle developers zullen deze video erg waarderen. Ben je minder technisch aangelegd, dan geeft deze video een goed beeld hoe serieus Moodle de uitdaging om AVG-proof te worden heeft aangepakt.

Meer informatie kan je vinden op docs.moodle.org/dev/Privacy_API.

Het bericht Moodle Privacy (14): Implementatie privacy-API in Moodle plugins #video verscheen eerst op Avetica.

Wat mij opvalt is dat met enige regelmaat gevraagd wordt de volgende gegevens in te vullen voor de klant:

• doel van de verwerking
• het soort persoonsgegevens
• categorieën van betrokkenen

Maar Avetica moet als Verwerker deze gegevens niet invullen, dat moet de Gegevensverantwoordelijke doen! Onze klanten zijn verantwoordelijk voor de data in Moodle en daarom moeten zij ook bepalen wat het doel van de verwerking is, het soort persoonsgegevens en welke categorieën van betrokkenen er zijn. Het oude gezegde ‘Wie betaalt, bepaalt’ is hier ook van kracht.

Jij moet als eigenaar van een Moodle site een ‘duidelijk omschreven en gerechtvaardigd doel’ voor gegevensverwerking bepalen. Daarna kan je toetsen of de gegevens in Moodle wel of niet nodig zijn voor dit doel.

Stel, je hebt het doel van de verwerking als volgt omschreven:

Het aanbieden van online leermateriaal, het volgen van de deelnemers in hun leerproces en het online begeleiden van de deelnemers.

Het verzamelen van het woonadres van je deelnemers is niet noodzakelijk voor dit doel. Zonder dat de docent weet waar je woont, kan hij je online helpen. Het e-mailadres verzamelen van de deelnemers is wel nodig om het doel te bereiken, want communicatie met de docent, het opvragen bij een vergeten wachtwoord en het ontvangen van notificaties bij nagekeken opdrachten, past binnen het kader van dit doel.

Besteed voldoende aandacht aan het goed omschrijven van het doel en blijf denken aan dataminimalisatie.

Het bericht Moodle Privacy (13): Wie bepaalt het doel en het soort persoonsgegevens? verscheen eerst op Avetica.

Wie is verantwoordelijk voor de juiste (privacy) instellingen van Moodle?

Het standpunt van de klant is: Avetica is de Moodle expert en moet dus zorgen voor de juiste instellingen qua privacy en security in Moodle.
Ons standpunt is: de klant is verantwoordelijke voor de data, voldoende kennis bij medewerkers van Moodle en tevens het testen van Moodle op security en privacy gebied.

Onze klant had ondertussen ook gesproken met de AVG-experts van Duthler Associates en de klant is inderdaad verantwoordelijk voor de data en instellingen. Toch ligt er een verantwoordelijkheid bij de verwerker (Avetica dus) om voldoende informatie te geven en de klanten bewust te maken van de privacy-instellingen in Moodle. Met onder andere onze blogs over Moodle security en privacy en ons Avetica Dashboard voldoen wij al goed hieraan. Maar we zijn ook weer aan het denken gezet om dit verder te optimaliseren en verder te werken aan voldoende bewustwording.

Wilt u een privacy check in uw Moodle site laten uitvoeren, neem dan contact op.

Het bericht Moodle Privacy (12): Privacy instellingen van Moodle, wie is verantwoordelijk? verscheen eerst op Avetica.

Stel, u bent directeur van een opleidingsinstituut en uw organisatie gebruikt Moodle volop in de opleidingen. U heeft de hosting uitbesteed aan een Moodle dienstverlener die op haar beurt weer het beheer van de webservers heeft ondergebracht bij een hostingpartij met eigen servers in een datacenter.

U bent als opleidingsinstituut de opdrachtgever en dus gegevensverantwoordelijke. U bepaalt het doel van de verwerkingen, de soorten gegevens en wie de betrokkenen zijn (want dat heeft een checklist zo goed aangegeven…). Maar als gegevensverantwoordelijke bent u ook verantwoordelijk van de juiste verwerking door de Moodle dienstverlener (verwerker) en de hostingpartij (subverwerker). U kunt door de toezichthouder aansprakelijk worden gesteld bij een datalek, maar ook als deze plaatsvindt bij de verwerker of subverwerker. We hebben het hier over ketenaansprakelijkheid.

In een mailwisseling werd ik betrokken hoever deze ketenaansprakelijkheid gaat. Want kan een ontwikkelaar van een Moodle plugin aansprakelijk worden gesteld bij een datalek? Moodle is open source, maar ook de Moodle plugins worden uitgebracht onder de GPLv3 licentie. In deze licentie zijn in de artikelen 15 en 16 disclaimers van garantie en verantwoordelijkheid opgenomen. Maar artikel 17 uit de GPVv3 behandelt het feit dat lokale wetgeving dit anders mag regelen.

Nu ben ik geen jurist, maar mijn eerste reactie was: die ontwikkelaar verwerkt geen persoonsgegevens en zit dus niet in de keten. Daarnaast is het de verantwoordelijkheid van de opdrachtgever om te bepalen of een Moodle plugin ‘AVG-proof’ is. De enige vraag die ik heb is hoe het zit met een belangrijk principe van de AVG, namelijk ‘privacy by design’. Maar ik vermoed dat ook hier geldt dat de opdrachtgever verantwoording draagt.

Het is goed dat in de Moodle plugin database zichtbaar wordt welke plugins wel en niet de privacy API van Moodle hebben geïmplementeerd. Dan kan je als sitebeheerder betere keuzes maken welke plugins je gebruikt (of niet meer).

Het bericht Moodle Privacy (11): Ketenaansprakelijkheid en open source verscheen eerst op Avetica.

‘Privacy by design’ houdt in dat de voor verwerking gebruikte mechanismen zo zijn ontworpen en ontwikkeld dat zij zo veel mogelijk rekening houden met de privacy van de gebruikers. Een voorbeeld hiervan is als er een knop is ingebouwd waarmee een gebruiker inzage krijgt in alle persoonsgegeven van hemzelf. Een andere maatregel kan zijn het minimaleren van data.

Een organisatie moet passende technische en organisatorische maatregelen nemen om te waarborgen dat alle verwerkingen volgens de eisen van de AVG worden uitgevoerd. Deze waarborgen moet je ook kunnen aantonen! De AVG kent geen uitzondering voor software die een organisatie reeds in gebruik heeft. Je kan dus niet zeggen dat je volgend jaar pas jouw Moodle 3.1 site gaat upgraden omdat dan het support afloopt van deze Long-Term-Support versie.

In de context van Moodle is het probleem wel dat de 2e maandag van mei Moodle 3.5 uitkomt die AVG-proof is en anderhalve week later al de AVG van kracht wordt. Binnen die korte periode alle Moodle sites upgraden, is ondoenlijk. Zeker als hier maatwerk in zit waar ook de privacy API geïmplementeerd moet worden.

Organisaties die Moodle 3.3 en 3.4 draaien kunnen vanaf volgende week hun sites gaan updaten, omdat dan minor releases uitkomen die AVG-compliant zijn.

Na 25 mei 2018 zal het probleem van de legacy software niet gelijk opgelost zijn. Zorg in ieder geval dat je upgradeplannen zijn uitgewerkt en dat je kan aantonen welke andere maatregelen je hebt genomen. Uiteraard in alle redelijkheid met de omvang, het doel van de verwerking en het soort gegevens (bv bijzondere persoonsgegevens).

Lees onze hele serie blogs over Moodle en de AVG.

Het bericht Moodle Privacy (10): Upgrade je Moodle site vanwege privacy by design verscheen eerst op Avetica.

Middels een fictief voorbeeld uit Moodle wil ik dit duidelijk maken. Je hebt een Moodle site en alle updates van Moodle en de plugins zijn bijgewerkt. Je site draait op SSL en alle beveiliginginstellingen staan goed.  Je hebt netjes in de security en privacy boekhouding het doel van de verwerking, de betrokkenen en welke soorten gegevens verwerkt worden beschreven. Maar nu komt het; een docent uit je organisatie heeft in Moodle een cursus met docentrechten. Voor een praktijkopdracht heeft de docent het feedbackformulier aangemaakt. De docent wil inventariseren welke politieke voorkeur zijn studenten hebben en daarmee een debat organiseren. Klinkt als een leuke opdracht die goed past zo net voor de gemeenteraadsverkiezingen.

Het probleem is dat politieke voorkeur een bijzonder persoonsgegeven is en deze mag je alleen verwerken (gegevens inventariseren en opslaan is ook verwerken!) als er in de wet een uitzondering voor is. Dat wordt lastig in deze situatie.

De organisatie is de Gegevensverantwoordelijke, maar niet op de hoogte van het verwerken van bijzondere persoonsgegeven. Dat is een risico en erg lastig om met technische maatregelen dit te voorkomen.

Bewustwording van alle docenten en beheerders is noodzakelijk en dit is geen eenmalige actie. Periodiek zal je alle medewerkers moeten trainen en hierover voldoende moeten communiceren. En mocht je ooit in de situatie komen dat er een onderzoek wordt ingesteld naar aanleiding van een datalek, dan hoop ik voor je dat je ook kunt aantonen dat je voldoende aan bewustwording hebt gedaan.

Het bericht Moodle Privacy (9): Voorbeeld waarom bewustwording zo belangrijk is verscheen eerst op Avetica.

Eerst een stukje context. Onze klant maakt gebruikt van Global Search, een nieuwe functionaliteit sinds Moodle 3.1 om allerlei content te doorzoeken. Onze klant verkoopt online leermateriaal aan meerdere klanten en gebruikt hiervoor één Moodle site. Een docent is via het zoeken in Moodle op een profielpagina gekomen van een deelnemer van een andere klant.

Welke oplossingen hebben we samen met onze klant direct doorgevoerd?

1. Stel de zoekzones van Global Search goed in. Voor veel elementen uit Moodle kan je instellen of Global Search dit wel of niet mag doorzoeken. Nu staat het doorzoeken van gebruikers uitgeschakeld.

2. Verander het recht ‘gebruikersprofielen bekijken’ van de rol geauthenticeerde gebruiker. Verbied het recht dat een ingelogde gebruiker een ander profielpagina mag bekijken.

Hoe nu verder? Onze klant is de Gegevensverantwoordelijke en gaat in overleg met betrokkene. Naar aanleiding van die uitkomst zal wel of niet dit datalek gemeld worden bij de Autoriteit Persoonsgegevens.

Of je nu wel of niet Global Search gebruikt in Moodle, controleer de rechten van gebruikers zodat deze privacy-proof zijn en binnen de doeleinden van de verwerking van gegevens passen. En die doeleinden bepalen is ook een taak voor de Gegevensverantwoordelijke.

Het bericht Moodle Privacy (8): Stel Global Search en de rechten van de rollen goed in verscheen eerst op Avetica.

Voor de zekerheid; in de nieuwe privacywet die 25 mei 2018 van kracht wordt, krijgen gebruikers meer rechten. De drie belangrijkste nieuwe rechten zijn:

1. het recht om informatie op te vragen welke type persoonlijke gegevens worden verwerkt en hoe lang deze bewaard wordt;
2. het recht om een kopie te vragen van alle persoonlijke gegevens die verwerkt worden in een leesbaar digitaal format;
3. het recht om verwijderd te worden van alle persoonlijke gegevens die verwerkt wordt.

Van elke Moodle plugin moet het volgende duidelijk beschreven worden:

1. welke type gegevens worden verwerkt in de plugin;
2. op welke wijze worden deze gegevens geëxporteerd als de gebruiker hierom vraagt;
3. welke data moet verwijderd worden als de gebruiker hierom verzoekt.

Op moment van schrijven zijn er 1451 plugins geregistreerd in de database, maar wereldwijd gaat het om vele duizenden. En de ontwikkelaars van al deze community plugins zouden eigenlijk de privacy API van Moodle moeten implementeren in hun plugins. Gezien het feit dat nu al niet alle plugins worden bijgewerkt, is er een grote kans dat veel plugins niet gaan voldoen aan de eisen van de GDPR. En formeel gezien zouden zulke plugins gedeïnstalleerd moeten worden.

Ontwikkelaars die wel de privacy-API implementeren, krijgen een extra symbool in de Moodle-plugins-database. Een mooie kans om je als ontwikkelaar te profileren lijkt me zo. Meer informatie over de privacy-API kan je vinden in dit forum en in dit levende document GDPR plugin API.

Hoewel de impact van de AVG/GDPR groot is voor zowel Moodle als de vele plugins, ben ik wel blij dat Moodle dit zo goed oppakt.

Het bericht Moodle Privacy (7): GDPR behoorlijke impact voor alle plugins verscheen eerst op Avetica.

Om onze klanten te helpen, hebben wij in ons Avetica Dashboard een tool ontwikkeld die alle type persoonsgegevens ophaalt en dit in een overzicht toont. Deze tool houdt rekening met de profielgegevens, extra profielgegevens en overige persoonsgegevens zoals IP-adressen en cookies (zie ook ons eerdere blog). Ook het doel van de verwerking en de categorieën betrokkenen moeten ingevuld worden door de gegevensverantwoordelijke (onze klant dus).

Bij het opslaan wordt deze informatie per mail verstuurd naar de ingelogde gebruiker en (indien bekend bij ons) de Functionaris Gegevensbescherming. Ook wordt deze informatie opgeslagen bij Avetica zodat we niet bij elke Verwerkersovereenkomst een aparte bijlage moeten maken met welke gegevens wij verwerken in opdracht van de klant. Ook wijzigingen in de persoonsgegevens kunnen op deze manier heel makkelijk worden bijgewerkt.

Met de ontwikkeling van deze tool willen we onze klanten helpen om de privacy goed te regelen.

Het bericht Moodle Privacy (6): Tool voor Verwerkingsregister AVG verscheen eerst op Avetica.

Centrale vraag is: zijn leergegevens ook bijzondere persoonsgegevens?

Met leergegevens bedoel ik toetscijfers, reflectieopdrachten, forumdiscussies, feedback van de docent, aantal toetspogingen, etc.

De vraag of leergegevens ook bijzondere persoonsgegevens is lastig te beantwoorden. In ieder geval zijn leergegevens persoonsgegevens, want er wordt een waardering over iemand gegeven. Ook het intelligentiequotiënt (IQ) geeft een waardering over een persoon en is daarmee een persoonsgegeven. Maar of leergegevens ook bijzondere persoonsgegevens zijn, daar lopen de meningen uiteen. Bijzondere persoonsgegevens zijn meer gevoelige gegevens zoals iemands ras, godsdienst, seksuele leven, politieke opvatting, gezondheid, lidmaatschap van een vakvereniging en strafrechtelijk gedrag.

In de AVG  is het aantal categorieën bijzondere persoonsgegevens uitgebreid met genetische gegevens en biometrische gegevens. En volgens mij vallen leergegevens hier ook onder. Ik hoop dat de Autoriteit Persoonsgegevens hier snel uitsluitsel over gaat geven.

Bijzondere persoonsgegevens zijn door de wetgever extra beschermd. Dus als leergegevens inderdaad bijzondere persoonsgegevens zijn, dan hebben alle organisaties die (online) leren aanbieden en hun leerlingen/deelnemers volgen, nog een flinke uitdaging om dit goed juridische en organisatorisch geregeld te krijgen.

Het bericht Moodle Privacy (3): Leergegevens zijn bijzondere persoonsgegevens? verscheen eerst op Avetica.