Moodle for GDPR data subject requests and retention

Every access or erasure request should follow the same sequence: log the request, verify who is asking, gather the data, decide whether erasure applies, and close the request with a written record. Moodle's data privacy tools give the site a place to record and track these requests, typically under the privacy and policies settings, where a user can submit a request and a site administrator or a data protection role can review it. Confirm in your Moodle version which roles can view and act on requests, since the permissions your privacy lead needs are different from those a course teacher holds. The goal is one accountable owner for each request, with dates and decisions captured as they happen.

Identity verification comes before any data is gathered or released. Confirm that the requester is the account holder through a channel the site already trusts, such as the registered email address or a sign-in the user completes. Do not send an export to an address that has not been checked. If a representative or parent makes the request, record the authority relied on and the checks made. Next, gather the data by starting with the export the data privacy tool produces for the user, then checking what that export does not cover. Record the Moodle version and the plugin set in place when the export was produced, so the answer can be reproduced if it is challenged later.

The data registry is the starting point for the inventory, but it is not the whole inventory. Moodle core components describe the personal data they hold, and the registry shows the site what core stores across its categories. Plugins add their own data, and each plugin that stores personal data is expected to declare it through the same privacy mechanism. A plugin that stores personal data without a declaration will be missing from both the registry and the export. Build a list of every installed plugin from the site's plugin inventory, covering activity modules, blocks, authentication, enrolment, local, report and admin tool plugins, and check each one for a declaration. Any plugin that stores personal data without one needs a manual review of its database tables before the site can answer a request with confidence.

Erasure is a decision, not a single action. Assess each erasure request against the six grounds in Article 17(1) of the GDPR: the data is no longer necessary for its purpose, consent has been withdrawn, a valid objection exists, the processing was unlawful, erasure is required by a legal obligation, or the data was collected from a child for information society services. If none of the grounds applies, erasure is not required and the reason must be written down and given to the user. A legal obligation to keep data can justify refusing erasure for that specific data, such as financial or accreditation records a statute requires the organization to retain. Decide category by category, because a request may succeed for some data in the account and be refused for other data in the same account.

Closing the request means recording what was done, not only what was deleted. Keep the verification record, the list of data categories and plugins checked, the decision for each category with its basis, and the date the user was told. Deletion in Moodle may remove data from the user's account and some plugin tables, but it does not automatically reach backups, logs, external systems or copies held by integrations. The closing record should list those locations and the retention position for each. Confirm with your data protection lead and counsel how long these records should be kept, and set that period before the first request arrives so the team is not deciding it under pressure.

The GDPR does not require an audit, an attestation or a certificate. No article obliges a Moodle operator to obtain an external report before processing learner data, and no supervisory authority will accept a vendor badge as proof that a deployment is compliant. Article 42 provides for voluntary certification, issued for at most three years by accredited certification bodies or supervisory authorities. Holding such a certificate does not reduce the controller's responsibility for compliance, so a Moodle site that is certified would still need its own evidence for each erasure request, retention decision and consent record.

What supervisors actually test is accountability. Under the accountability principle, the controller must be able to demonstrate compliance, not merely assert it. For this Moodle topic, that means being able to show which data subject requests were received, how the data privacy tool handled each one, which retention periods were configured in the data registry, and when a learner consented to a site policy. Where processing rests on consent, Article 7(1) puts the burden on the controller to demonstrate that consent was given. Ask your team which records would answer those questions for a regulator six months after a request was closed, and where those records are kept.

The Article 83 fines are the reason that evidence matters. Infringements of the principles, lawful basis and data subject rights carry maximum fines of EUR 20 million or 4% of total worldwide annual turnover, whichever is higher. Failures of obligations such as those in Articles 25 to 39 carry a lower ceiling of EUR 10 million or 2%. Erasure and retention failures in a learning platform usually fall under the higher tier. The EDPB's 2025 coordinated enforcement action on the right to erasure found controllers struggling to set retention periods and to delete personal data held in backups, which are the same gaps a Moodle deployment must close and document.

DeployOpen prepares the system, the configuration and the evidence for these questions. That includes configuring the data privacy tool and data registry, documenting retention and erasure procedures, and setting up the logs and records a controller would show a supervisor. DeployOpen does not issue audit reports, attestations or certifications, and it does not decide whether your processing is lawful. Independent auditors and certification bodies carry that role. Before scoping the work, confirm with your data protection officer or legal counsel which evidence your supervisory authority expects, and which certification, if any, your organization wants to pursue on its own terms.

Where the Moodle site, its backups and its support access sit determines how much of GDPR Chapter V applies to your learner records. Each location is a separate question. The database, the moodledata directory where uploaded files are stored, the backups and the server logs all need to be mapped to a country and to an operator. Support access matters as much as storage. EDPB Guidelines 05/2021 (version 2.0) state that remote access from a third country is a transfer, even when the person only views data on a screen for support or administration, and that storage in a cloud outside the EEA is also a transfer. An engineer who signs in to a Moodle admin account from another country to fix a plugin can therefore create a transfer on a day when no data was copied anywhere.

When a provider holds the data, two further questions arise. Article 48 of the GDPR says a third-country court judgment or administrative decision requiring disclosure is recognized or enforced only if it rests on an international agreement in force with the Union or a Member State, such as a mutual legal assistance treaty. The EDPB's Recommendations 01/2020 state that where a cloud provider needs access to data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. The US CLOUD Act, codified at 18 U.S.C. 2713, requires providers to preserve or disclose data in their possession, custody or control wherever it is located. If a managed host or an upstream vendor is subject to that law, ask the provider whether it has received government requests and how it responds to them, and record the answer.

The choice of transfer mechanism depends on the same facts. Schrems II (Case C-311/18, judgment of 16 July 2020) invalidated the Privacy Shield adequacy decision but held that standard contractual clauses remained valid, subject to an assessment of the destination. For the United States, Commission Implementing Decision (EU) 2023/1795 finds adequate protection only for organizations on the Data Privacy Framework List. That decision is under challenge: an appeal against the General Court's September 2025 judgment upholding it is pending as Case C-703/25 P. A hosting contract that relies on DPF listing today therefore carries a legal dependency that could change. Standard contractual clauses under Commission Implementing Decision (EU) 2021/914, backed by a documented transfer impact assessment, are a common fallback, and the controller carries responsibility for completing that assessment.

Build a location register before choosing a host. For each component, record the country of storage, the countries from which administrators sign in, the legal entity that operates the service and any sub-processors. Ask a managed Moodle host, including MoodleCloud or a Moodle Partner, to confirm the same details for its support tooling, remote access and backup vendor. Ask any implementation partner which engineers access production, from where, and through which named and logged accounts. Check where the identity source sits if single sign-on uses SAML 2.0 through the auth_saml2 plugin, because it holds the identifiers that link learners to the site. Take legal advice on your own position, including which Article 6 lawful basis applies, whether a transfer mechanism is required and how your records of processing should describe it.