Met zijn alle zijn we vast heel erg hard aan het werken om ons op de AVG voor te bereiden. Het is tenslotte al bijna zover. Niet alleen in mijn rol als sitebeheerder van diverse sites, maar ook als eigenaar van mijn bedrijf. Heb ik me de afgelopen periode voornamelijk afgevraagd:
1. Hoe ga ik het in hemelsnaam in Moodle mee om?
2. Wat heb ik nodig om het goed in te stellen?
3. En wat zien en merken mijn Moodle gebruikers hiervan?
Om antwoord te krijgen op deze vragen, moest ik uiteraard me eerst in de AVG gaan verdiepen. Daarna ben ik aan de slag gegaan met de nieuwe plug-ins, meegelezen op fora en webinars gevolgd.
Ik moet zeggen dat ik aangenaam verrast ben over de aanpak en visie van Moodle in deze. Maar vooral ook gesteund voelde door de tal van vragen die voorbij kwamen. Je bent niet alleen.
Omdat ik zeker nog niet alles weet, en nog steeds met tal van vragen zit. Heb ik lang getwijfeld of ik mijn bevindingen al wel zou delen. Maar aan de andere kant.. als ik het voor me hou dan ben ik wellicht nog langer aan het zoeken.
Dus…Â hier gaan we.Â
Moodle en de AVG
Doordat Moodle de AVG beschouwd als een bijdrage in hun visie op een veilige leeromgeving. Zullen de nieuwe functies je wellicht wat overweldigen. Aan de andere kant, moeten we dit ook als een pluspunt zien, want daarmee laten ze zien hoe belangrijk ze het vinden.
Echter maakt dit het nog belangrijker dat vóórdat je gaat priegelen met de instellingen, dat je niet alleen eerst goed laat inlichten / verdiepen in de AVG. Maar dat je ook bespreekt welke impact het heeft op je organisatie, en met name wat je moet regelen. Want … hoewel Moodle de functies biedt het is en blijft de verantwoordelijkheid van de gegevensverantwoordelijke om deze op de juiste wijze toe te passen.
Noodzakelijke Moodle versie:
Om het AVG functionaliteiten te krijgen in Moodle te heb je minimaal versie 3.3.5+ of 3.4.2+ en de bijbehorende GDPR (AVG) plug-ins nodig.
Vanaf Moodle 3.5 – wordt op 14 mei 2018 verwacht – zijn de plug-ins onderdeel van de standaard installatie.
Workflow: nieuwe gebruikers
Op basis van inrichtingskeuzes zal er bij nieuwe gebruikers een nieuwe workflow ontstaan. Het schema hieronder is vooral gericht op het zelfstandig aanmaken van accounts voor nieuwe gebruikers.
Hoe zit het met gebruikers die via koppelingen aangemaakt worden?Â
Dit is voor mij persoonlijk nog een vraag waar ik mee speel. Allereerst omdat ik denk dat wanneer je praat over koppelingen zoals SAML2 en LDAP dat dit vooral in organisatie liggen waar er met de gebruikers al een contract is aangegaan. Zoals bijvoorbeeld een arbeidscontract. In dit contract zou dan bijvoorbeeld afspraken kunnen staan over hoe de organisatie omgaat met hun data op bv een Moodle leeromgeving. Ik kan me wel voorstellen dat organisaties ervoor kiezen om dit nog eens een privacy policy toe te lichten en dat deze getoond wordt bij  de eerste inlog.
Moodle als LTI Provider of Consumer biedt is natuurlijk wel een andere discussie. Vanuit de Consumer kant is er zelfs een tracker aangemaakt LTI GDPR information waar men van mening is dat men speciaal hiervoor toestemming moet geven. Aan de andere kant zou je ook kunnen redeneren dat je dit al een stadium eerder hebt “afgedwongen”. Ben jij van mening dat er een speciale toestemming nodig is? Vergeet dan niet om op de tracker te stemmen!
Moodle als LTI Provider zou je kunnen stellen dat de partij die LTI Consumer is, dit moet regelen. En dat de partijen onderling een verwerkersovereenkomst hierover moeten afsluiten. Wat denk jij? Ik ben benieuwd!
Geldt dit ook voor gebruikers die via een webservices aangemaakt worden?Â
Als je gebruik maakt van een webservice (bv bij Coachview) om gebruikers aan te maken en je gaat voorwaarden instellen op de Moodle site. Zorg dan dat je FG óf sitebeheerder voor de webserver gebruiker handmatig de voorwaarden/beleid accepteren. Anders zal het proces voor aanmaken van gebruikers gestaakt worden.
Hoe zit dat met gebruikers die handmatig aangemaakt worden óf al bestaan?Â
Maak je géén zorgen. Voor deze gebruikers geldt dat als er voorwaarden zijn ingesteld op de site, dat ze bij dé eerste (volgende) keer dat ze inloggen de voorwaarden moeten accepteren vóórdat ze verder kunnen. Tip: upgrade je site en/of pas je voorwaarden toe, zorg dan dat je gebruikers informeert over deze wijziging.Â
Wat moet ik als sitebeheerder regelen om het bovenstaande proces toe te passen.
Let op het kan zijn dat sommige delen dus niet van toepassing zijn voor jouw organisatie!Â
1: Een nieuwe rol aan maken van de Functioneel Gegevensbeheerder indien dit iemand anders is dan de sitebeheerder. Klik hier voor de Engelstalige uitleg.
2: De nieuwe gebruikers die FG zijn koppelen aan de rol.
3. Privacy instelling ten aanzien van Minderjarige beleid & contact opnemen met de FG aan zetten (indien van toepassing)
Wat is een digitaal minderjarige? En hoe werkt dit?Â
In Nederland is bepaald dat iemand tot 16 jaar beschouwd moet worden als digitaal minderjarig. Dit houdt in dat een ouder en/of wettelijke verzorger toestemming dient te geven vóór de minderjarige. Moodle heeft dit vertaald naar het feit dat een digitaal minderjarige bijvoorbeeld niet zelf een account mag maken.
Wanneer dit ingeschakeld is krijg je voortaan een leeftijdscontrole wanneer een gebruiker zelf een account aanmaakt. Wanneer een gebruiker nog géén 16 is, zal hij/zij het bericht zien dat er contact opgenomen moet worden met de organisaties FG voor het aanmaken van een account. De FG kan dan met akkoord van de ouders, het account aanmaken en direct zorgen voor eventueel akkoord op de ingestelde beleid(en).
Indien gewenst aanvinken dat een gebruiker contact op kan nemen met de FG.Â
4: Overeenkomsten waar gebruikers akkoord voor dienen te geven toevoegen. Denk bijvoorbeeld aan Website -, Privacy -of Cookie beleid.
GebruikersverzoekenÂ
De (eind)gebruiker kan vanaf zijn profiel inzage krijgen in de beleid en overeenkomst die door hem/haar zijn akkoord gegeven.
Note op 08-05 is  helaas nog niet mogelijk dat een (eind)gebruiker een akkoord ook kan intrekken. Hier is wel een ticket voor aangemaakt. (hoe meer votes hoe hoger het op de lijst komt te staan!)
Vanaf het profiel kan een gebruiker ook een bericht sturen naar de Functionaris voor gegevensbescherming. En uiteraard gegevens verzoeken indien.
Een gegevensverzoek komt uit bij de FG – indien ingesteld anders bij de sitebeheerder. De FG kan vervolgens een verzoek inzien, akkoord geven of weigeren. De FG kan tevens ook namens een andere gebruiker een verzoek indienen.
 Wanneer een gegevensverzoek is goedgekeurd of geweigerd ontvangt de aanvrager altijd een e-mailbericht.
Exporteren van gegevens: in deze situatie ontvangt de aanvrager een bericht dat ze het bestand kunnen downloaden. In dit bericht staat een link naar de juiste pagina. Het te downloaden bestand is een ZIP file, met daarin de gegevens. In de meeste gevallen zal dit zijn in het format JSON. De aanvrager dient daar een apart programma voor te gebruiken om te lezen. Bijvoorbeeld: https://jsoneditoronline.org/
Verwijderen van gegevens:Â Wanneer een aanvraag om gegevens verwijderen is geaccepteerd kan de aanvrager niet meer inloggen met zijn/haar account.
Het gegevensregister van Moodle
De sitebeheerder én FG hebben de mogelijkheid om in Moodle een eigen gegevensregister in te richten. In het register is alvast voor je een indeling gemaakt. De indeling is van een hoog naar lager niveau: website > Gebruikersvoorkeuren > Cursuscategorieën > Cursussen > Activiteiten & Bronnen > Blokken
In het gegevensregister kan de FG categorieën maken en doelen vastleggen. Door de context te koppelen aan  categorieën, voldoe je aan de AVG verplichting t.b.v. audits. Doel staat voor de manier waarop je de data categoriseert.
Dit houdt dus in dat je als FG goed moet na denken over de juridische doelen van het bewaren van data.
Voorbeelden
Je hebt als doel “Sociaal en mededelingen” met een bewaartermijn van 6 maanden. En als doel “Academische examens” met een bewaartermijn van 5 jaar.
De doelen op zich zijn prima, maar de vraag is dan nog  of er een wettelijke basis ligt om deze data voor die periode te bewaren. Je kunt dit per doel invullen.
Voor het correct inrichten en toepassen van het gegevensregister is het belangrijk dat je goed op de hoogte bent van de AVG.
Wanneer wordt wat verwijderd?
De nieuwe Privacy API regelt op dit moment 2 “verwijder” functies in Moodle.
Delete_data_for_user() – deze wordt opgeroepen wanneer een gebruiker vraagt om “vergeten” te worden. Met andere worden verwijderd te worden. In een cursus context houdt dat in dat de gebruiker afgemeld wordt uit de cursus, en op systeem niveau kan de gebruiker dan niet meer inloggen.
Delete_data_for_all_users() – wordt opgeroepen wanneer bij de context in het gegevensregister bij doel het bewaartermijn is gehaald. Waarmee het “privacy by design” principe van de AVG uitgevoerd wordt. Wanneer de bewaartermijn is gehaald wordt alle data verwijderd, inclusief de aanmelding in de cursus.
Op dit moment kijkt de bewaartermijn naar de einddatum van de cursus. Het is nog wel de bedoeling dit nog verder uit te breiden, zie ook het forumbericht van Andrew Nicols.
Gegevensverwijdering
Over dit stukje functionaliteit zijn nog veel vragen. Echter als we kijken naar de tekst zou deze pagina dus alle contexten (cursussen, gebruikersgegevens etc) die hun bewaartermijn (als in gesteld bij doel) voorbij zijn getoond worden. De FG kan dan vervolgens zeggen dat deze gegevens wel of niet verwijderd moeten worden.
Plugin privacy-register compliance
Persoonlijk vind dit een mooie ontwikkeling binnen Moodle. Deze pagina – die de FG ook kan zien – toont namelijk welke modules binnen Moodle wel of geen persoonlijke gegevens bewaard.
De pagina toont zelfs plug-ins die je hebt geïnstalleerd, waardoor je dus als FG weet of deze plug-in wel of niet aan de Moodle privacy API gekoppeld staat.
Staat er namelijk een rode driehoek bij, dan is dit nog niet het geval. En is het dus zo dat als een gebruiker een verwijder en/of download verzoek indient, deze informatie niet meegegeven wordt.
Let op:Â het is en blijft de verantwoordelijkheid van de gegevensverantwoordelijke om plug-ins die om welke reden dan ook niet gekoppeld zijn aan de Privacy API te gebruiken. Ontwikkelaars zijn niet verplicht om de koppeling te maken vanuit Moodle HQ, maar worden wel geadviseerd dit te doen. Laat je maatwerk ontwikkelen? Zorg dan dat je deze keuze meeneem in de ontwikkeling.Â
Aan dit artikel kunnen géén rechten verleend worden en wordt slechts ter informatie aangeboden. Suggesties t.b.v. aanpassingen worden op prijs gesteld.
[cookie height=”100%” width=”200px”]