Open edX for GDPR account deletion and data sharing

The erasure workflow decides whether a request is actually closed, so build it as one sequence with a named privacy owner, and run the platform's user retirement tooling inside that sequence rather than as an ad hoc action by whoever holds administrator access. Article 17(1) of the GDPR requires erasure without undue delay when one of six grounds applies, including data no longer necessary, consent withdrawn, a successful objection and unlawful processing. Intake should record which ground applies before anyone touches an account. Next, confirm in the documentation for the named Open edX release in use exactly which LMS account fields retirement clears, anonymizes or leaves in place, because that behavior is the foundation of every later check.

Assign each step a trigger and an owner. A learner request, a regulator's order under Article 58(2)(g) or an internal retention decision can start the workflow, and the privacy team verifies identity and assesses the legal basis first. Article 19 requires that erasure be communicated to each recipient of the data unless that is impossible or disproportionate, so the second step notifies LTI tools and any external credential or badge service that received learner data, and records the reason for any exception. The platform operator then runs LMS retirement. Forum content follows as a separate step, where the team decides with moderators whether posts are deleted, removed or detached from the retired account, and confirms the method for the release in use. Issued credentials come last, since other parties may rely on them. Decide whether each credential is revoked, unlinked from the learner's identity or retained on a documented legal basis.

Every request needs a single record that survives the ticket system. Capture the ticket identifier, the date received, the identity check method, the Article 17(1) ground, the systems in scope, the operator and timestamp for each step, the recipient notices sent and the outcome per system. Verification should be a repeatable checklist rather than a judgment call. For the LMS, the operator searches admin tooling and a staging database copy for the former username, email address and profile identifiers. For forums, the team searches for the retired username and checks that remaining posts no longer resolve to a person. For credentials, the team checks the issuing record and any public verification page. The EDPB's 2025 coordinated enforcement action on erasure, announced on 18 February 2026, listed ineffective anonymisation used in place of deletion among its recurring findings, so a check should confirm that data is removed or truly unlinked, not merely hidden.

The gaps sit outside the retirement tooling. Backups keep personal data after the live systems are clean, and the same EDPB action named deletion of personal data in backups as a recurring challenge. Set a backup retention period, document how restored backups re-apply completed erasure requests and test that restore path. Custom XBlocks, plugins and integrations may write learner data to stores that retirement does not touch, so inventory them before go-live and add their stores to the verification checklist. Confirm with the vendor and the release documentation which components are covered by default and which need custom handling. Finally, name who approves any retention exception, and make sure that decision is written into the request record with its legal basis.

The EDPB's coordinated enforcement action on the right to erasure, announced on 18 February 2026 and covering 764 controllers across 32 data protection authorities, named seven recurring challenges. Two of them matter most for an Open edX operator: using anonymisation in place of deletion, and leaving personal data in backups. An erasure request is not complete because a learner's name was replaced in one table. The team must show that the data is deleted from the systems in scope, or that what remains cannot reasonably be linked back to the person, and must be able to explain which of those applies to each store.

Deletion or anonymisation? Open edX user retirement is built to remove or overwrite personal fields across the LMS, forums and credentials, so the default position should be deletion. Anonymisation is a separate claim that requires an assessment of whether the remaining data, combined with other data the controller or a recipient holds, can still identify the learner. Event logs, enrollment history and forum posts are the usual difficult cases. Write down the decision for each data category, the reasoning, and who approved it. Confirm with your privacy team whether retained aggregate course statistics meet your anonymisation standard before relying on them.

Backups and restores. Backups are the second failure point. A deleted account can reappear after a restore if the restore source predates the erasure and nobody reapplies the deletion. Confirm how your backup tooling handles individual records, since most backup tools restore whole databases or volumes and do not erase single learners on their own. Do not assume that any backup product performs erasure automatically. Your procedure should say that erasure requests are recorded in a log that restores check against, that the restore runbook includes a step to reapply deletions, and that restored data is not returned to production before that step completes.

Backup rotation. Document the retention period for each backup set, the date on which the oldest copy containing a deleted learner will expire, and who owns that date. Article 17 requires erasure without undue delay, so an unexplained gap between the request and the backup expiry will be hard to defend. Where a backup cannot be shortened, record the justification, restrict access to the backup, and confirm with your legal team how the data subject is informed. Test the rotation and restore steps at least once before go-live, and keep the results as evidence.

The first thing to settle is that a learner's deletion request does not end at the LMS database. In an Open edX deployment that uses Open edX Aspects, tracking logs are captured through the event-routing-backends plugin as xAPI statements, stored in a ClickHouse database through Ralph or Vector, and presented in Superset dashboards. Each of those stages can hold a copy of learner-linked data, and each copy can outlive the retirement that the LMS performs. Before you promise a learner that their data is gone, list every copy, the identifier that connects it to a person, and the process that removes or transforms it.

The copies fall into three groups. The first is the raw event stream: xAPI statements that carry actor identifiers, course and unit references, timestamps and event context. The second is the analytical store in ClickHouse, which may hold the same statements in tables built for queries, often with derived fields. The third is the presentation layer, where Superset datasets, saved charts, cached query results and exported CSV files can keep learner-level rows or aggregates that are small enough to re-identify people. Ask your team to inventory each store, its retention setting and whether it holds the LMS user identifier, the email address, or a hashed or pseudonymous value that the LMS can reverse. Also check Vector and Ralph buffers, dead-letter queues and any object storage used for archives.

Finding the linking identifiers is the hard part. The LMS user ID is the obvious join key, but the actor in an xAPI statement may be an account identifier, an email address, or a UUID generated by the event pipeline. Review the event-routing-backends configuration and sample real statements from each source, then trace the field mapping into ClickHouse and into any Superset dataset that joins on it. Record how the mapping was built, and test whether a lookup on the LMS identifier returns every row you expect. Do this on a staging copy, and document the query you used so an auditor or a later engineer can repeat it.

For each copy, decide among three outcomes. Deletion removes rows keyed to the learner and is the default when no further purpose exists. Pseudonymization replaces the identifier with a value that cannot be linked back without a key you can destroy, which may suit course-level trends, but regulators have criticized anonymization used as a substitute for deletion, so the reasoning must hold up. Retaining aggregate data is defensible only when the aggregates cannot single out a learner, which means checking small cohorts and rare combinations. Confirm with your data protection lead which purpose each copy serves and record the decision.

Your team must confirm the retention and deletion behavior of each component in its own deployment. Do not rely on defaults in a tutorial or on the behavior of a sibling project. Confirm, with the vendor documentation for your versions and by testing, whether ClickHouse TTL rules, Ralph storage settings, Vector sinks, Superset caches and exported files delete or merely hide data, and whether backups retain rows after a live deletion. Ask for written confirmation of each result before you tell learners that their data has been erased.