Someone has told you to make your Moodle “GDPR compliant”, and most of what you find online is legal theory. This guide skips that and gives the concrete list of things you, as the administrator, actually set up and operate inside Moodle. There are five, and Moodle has a dedicated tool for each. Everything below lives under Site administration > Users > Privacy and policies, powered by two core tools, tool_dataprivacy and tool_policy. Paths and behavior are for Moodle 4.5. None of this is legal advice; it is the operational checklist that sits underneath whatever your DPO decides.

1. Decide who is responsible: a Privacy Officer role

First, decide who handles data requests. Create a Privacy Officer role with the data-privacy capabilities (the tool/dataprivacy:* capabilities) and assign it to a real person. This is who Moodle notifies the moment someone requests their data. Skip it, and requests arrive with no owner and quietly pile up, which is itself a compliance failure. You can also nominate privacy officers explicitly under the data privacy settings so they receive the notifications.

2. Operate the data request queue (the part GDPR requires)

This is the heart of it. Under Data requests (/admin/tool/dataprivacy/datarequests.php) you will find the queue. A user clicks “Data request” in their profile to either export their personal data or have it deleted, and it lands here for your Privacy Officer to action.

  • Export request: approve it, and Moodle assembles a downloadable archive of everything it holds on that person. This is your right-of-access answer.
  • Erasure (delete) request: approve it, and Moodle removes the person’s personal data. This is your right-to-be-forgotten answer.

Both are built in; your job is to make sure someone owns the queue and works it within the legal time limit.

3. Declare why and how long: the data registry

The Data registry (/admin/tool/dataprivacy/dataregistry.php) is where you declare, inside Moodle, why you hold data and for how long: your retention periods, organized by category and purpose. Auditors and data protection officers ask for exactly this, and it is empty until you set it up. Once configured, it is also what lets Moodle flag data that has outlived its retention period so it can be expired.

4. The trap almost everyone misses: the plugin privacy registry

The Plugin privacy registry (/admin/tool/dataprivacy/pluginregistry.php) lists every plugin on your site and whether it properly implements Moodle’s Privacy API. Here is the catch: if a plugin is non-compliant, its data is not included when you export someone’s data, and it is not removed when you process an erasure request. Personal data can therefore survive quietly inside that plugin, and you would never know it from the request itself. Check this list, and be cautious with any third-party plugin that cannot be brought into line, because it undermines both of the rights in point 2.

Finally, under Policies (/admin/tool/policy/managedocs.php) you publish your site and privacy policies. Users must consent on login, and Moodle records that consent with a timestamp, which is your evidence that consent was actually given. You can version policies, so when a policy changes, users are asked to re-consent and the new acceptance is recorded separately.

Recap

An owner, the request queue, retention in the data registry, the plugin privacy check, and policies with tracked consent. Do those five and you have covered what the administrator is genuinely responsible for under GDPR inside Moodle. The legal interpretation is your DPO’s job; keeping these five operational is yours.

Solin helps organizations in regulated sectors operate Moodle and Totara in a GDPR-aligned way, including privacy API gaps in third-party plugins. Contact us for a review.

Need help with a Moodle or Totara project?

Contact us