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.

Prefer to watch? Here is a short walkthrough of the Moodle GDPR compliance setup:

1. Decide who is responsible: a Privacy Officer role

First, decide who handles data requests, because GDPR gives you a fixed deadline to respond and someone has to own that clock. Create a Privacy Officer role (base it on the Manager archetype) and grant it the data privacy capabilities your process needs, in particular tool/dataprivacy:managedatarequests and tool/dataprivacy:managedataregistry, plus the download and make-requests-for-children capabilities if you use them. Then assign it to a real person at site level. The step that is easy to miss: tick that role under Data privacy settings > Privacy officer so the holders are actually emailed when a request arrives, and turn on Contact the privacy officer. That second toggle does more than add a contact link: it is what makes the Export all of my personal data and Delete my account options appear on each user’s profile, under Privacy and policies. Leave it off (which is the default) and your users have no way to file their own request; only an admin or privacy officer can raise one on their behalf from the Data requests page. Sensible default: enable it, and name one privacy officer plus one backup so requests do not stall when someone is on leave. Skip all of this and a site admin can still process requests (Moodle does not lock you out), but with no named owner they are more likely to be missed or handled late, which is itself a compliance risk.

2. Declare why and how long: the data registry

The Data registry (/admin/tool/dataprivacy/dataregistry.php) is where you record, in Moodle’s own terms, what personal data you hold, why you are allowed to hold it, and how long you keep it. This is the documentation auditors and data protection officers ask for, and it also drives Moodle’s retention handling. It is built from two pieces: categories, which label a type of data, and purposes, which state the reason you process it and its retention period. You set a default category and purpose for the whole site and can override them lower down, per course category, course, activity, or block.

The real decisions live in the purpose. When you create one, you fill in:

  • Lawful basis (GDPR Art. 6): why you are legally allowed to process the data. For workplace training this is usually Legal obligation (you must be able to evidence mandatory training) or Contract (training forms part of employment). A public body might use Public task; genuinely optional data, such as a marketing preference, uses Consent.
  • Retention period: how long you keep the data. When it expires, Moodle flags the data and lists it for deletion for an administrator to confirm, so nothing is destroyed silently. For a user, the period is counted from the last time they accessed the site.
  • Protected: tick this for data you are legally required to keep, so a right-to-be-forgotten request cannot remove it before the retention period ends.
  • Sensitive data reasons (GDPR Art. 9): only needed if you hold special-category data such as health information.

If you are not sure where to start, a sensible default for a typical workplace-training site is one category, Learner records, and one site-wide purpose, Training records, with lawful basis Legal obligation and a retention period that matches how long you must be able to prove compliance (for example, three years since the learner’s last access). Mark certification or mandatory-training evidence as Protected so it survives an erasure request until that period is up. Then make that category and purpose the site-wide default: on the Data registry page the tree’s top node, Site, is selected for you, so choose your category and purpose there and click Save changes, making sure both selectors show an actual value and not Not set before you save. Do this on the Site node itself, not via the separate Set defaults button: that button only covers course categories, courses, activities, and blocks, so it never sets the site-level default. This matters before you handle any requests. Until a site default purpose is set, the Data requests page shows a red “A site purpose and category have not been defined” warning, and an erasure request would remove all of a user’s data instead of expiring only what is past its retention period. Retention itself is enforced on the separate Data deletion page (/admin/tool/dataprivacy/datadeletion.php), which lists contexts that are past their retention period and waits for your confirmation before the “Delete expired contexts” scheduled task removes the data.

3. 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 the personal data it can reach through its privacy system. How complete that archive is depends on plugin privacy support, which is point 4. This is your right-of-access answer.
  • Erasure (delete) request: approve it, and Moodle runs its deletion workflow for that user’s personal data, within the limits of core and plugin privacy support. The right to erasure is not absolute, so your DPO still decides whether a given request should be granted. 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, which under GDPR is one month. Sensible defaults: leave automatic approval off, at least for deletions, so a human reviews each erasure before any data is destroyed, and set a Data request expiry so completed export downloads do not stay available indefinitely.

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 non-compliant plugin stores personal data, that 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. There is nothing to fill in here; it is a review, and one you should repeat after every plugin install or upgrade. Sensible default: treat “does not implement the Privacy API” as a blocker for any plugin that stores personal data, and prefer an alternative that does, because a non-compliant plugin quietly undermines both of the rights in point 3.

Finally, publish your policies and capture consent. One setting makes or breaks this: under Policy settings, set the Site policy handler to Policies (tool_policy). Until you do, the tool stores nothing and no consent is enforced, which is the usual reason “I created a policy but nobody is asked to accept it.” Then, under Policies (/admin/tool/policy/managedocs.php), create each document with a name, a type (Site policy, Privacy policy, Third parties, or Other), a short summary, the full text, and an audience (usually All users). Set the status to Active and users must consent at their next login, with each acceptance recorded against a policy version and timestamp as your evidence. Sensible default: publish at least a Privacy policy and a Site policy aimed at All users; later, when you edit one, mark trivial wording fixes as a Minor change so you do not force everyone to re-consent unnecessarily. One caution: Moodle’s recorded policy acceptance is not the same thing as GDPR consent as a lawful basis. Plenty of processing relies on contract, legal obligation, or legitimate interests instead, so your DPO still decides the lawful basis for each purpose (point 2).

Recap

An owner, retention defined in the data registry, the request queue, the plugin privacy check, and policies with tracked consent. Keep these five operational and you have covered the main Moodle-side admin workflows that support GDPR compliance. The lawful basis for each purpose, your retention policy, processor agreements, external systems, backups, and the final decision on each request remain your DPO’s responsibility.

What this does not cover

This checklist covers Moodle’s built-in operational tools only. It does not replace a GDPR review of your lawful bases, your privacy notice, processor agreements, your hosting setup and backups, or any external plugins, LTI tools, analytics, video platforms, or custom integrations that handle personal data outside these screens. Setting up these five areas is the Moodle-side groundwork; it is not, on its own, a statement that your site is GDPR compliant.

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