A student says she was removed from a course the day before her midterm. A teacher reports a student in his section who isn't on his SIS class list. A former student files an access request for every record the institution holds about him. Each time, the question is the same: who changed this enrollment, when, and why?
The end of term raises a companion question. Once final grades are in the SIS, hundreds of Moodle courses still hold submissions, grades, forum posts and feedback, all of it personal information. What happens to those courses, who can still open them, and for how long?
Why is "who changed this enrollment?" so hard to answer?
Moodle logs a lot. Its standard log records events such as user enrolled in course, user unenrolled from course, user enrolment updated and role assigned, with the time, the account that acted, the affected user, the origin (web, web services or command line) and the IP address. Admins find it under Reports > Logs at course or site level.
The limits show up when the question is "why":
- The actor is often a machine. Changes made by a sync appear under the web service account or the admin account a scheduled task runs as. The log tells you the sync did it, not which SIS transaction or which person's change caused it.
- The cause lives elsewhere. The reason sits in the SIS (a drop, a section change, a status update), the effect in Moodle, and in between there's a script log on a server, if the script keeps one. That's three systems, three retention periods and often three teams.
- The evidence may be gone. Moodle's "Keep logs for" setting controls how long the standard log is kept. Sites that trim logs for performance may have deleted the evidence before anyone asks.
- Manual and synced changes mix. A teacher's manual enrollment and the sync's suspension can both apply to the same student, and only a careful reading shows which one won.
What should happen to Moodle courses at the end of term?
Moodle has no single archive button. Institutions combine several options, each with its own trade-off.
| Option | What it does | Trade-off |
|---|---|---|
| Hide the course | Students lose access; teachers keep it | Fast and reversible, but the data stays in production |
| Move to an archive category | Separates past terms; permissions set once for the category | Category-level role overrides must be maintained |
| Read-only access for students | Students can consult but not submit or post | Requires capability overrides that should be tested |
| Back up, then delete | Lightens the production site | Restores are slow, and backup files are personal information too |
| Course reset | Removes user data, keeps content for reuse | Irreversible for the data removed |
Whatever you choose, treat a meta-course as a unit and close the parent and its section courses together. Set the course end date as well, so dashboards file the course under past courses instead of current ones.
Access is the other half of the decision. After the term, a few groups usually have a legitimate need, and each can be handled with a role or a time limit:
- Instructors, to handle grade reviews and appeals and to reuse their material the next term.
- Students, sometimes, to read feedback during a short, announced period before the course closes to them.
- Program coordinators or advisors, occasionally, for program reviews, through a category-level role rather than individual enrollments.
Everyone else, including teaching assistants whose contract has ended and students who dropped, should lose access when the course closes. Writing this down once and applying it every term is what turns archiving from a cleanup chore into a policy you can explain.
What do Law 25 and the GDPR expect?
This section explains the laws in general terms. It isn't legal advice: how they apply to your institution, and to your Moodle in particular, is a question for your privacy officer.
Quebec's Law 25 modernized the province's privacy rules for both public bodies and private organizations, with obligations phased in between 2022 and 2024 and overseen by the Commission d'accès à l'information. The GDPR applies to institutions in the European Union. Both rest on similar principles, and so do many local data-protection regulations elsewhere.
| General principle | What it means for Moodle enrollments and courses |
|---|---|
| Accountability | Someone is responsible for personal information, and you can show how it is processed, including who changed what |
| Security measures | Access is limited to people who need it, changes are traceable and logs are protected |
| Limited retention | Course data is kept only as long as its purpose and your retention rules require, then destroyed or anonymized |
| Access and correction | You can find what you hold about a student, across Moodle and connected systems, within the legal deadlines |
| Incidents | Confidentiality incidents are recorded and, when the risk is serious, reported to the regulator and the people affected |
| Impact assessment | New or overhauled information systems handling personal information call for a privacy impact assessment under Law 25; the GDPR requires one for high-risk processing |
In Quebec, public bodies such as cégeps also maintain a retention schedule under the Archives Act, so your records manager belongs in the conversation as well.
Which practices hold up when someone asks?
- Name the source of truth for each kind of data. The SIS holds registration and final grades; Moodle holds course activity. Enrollment changes should start in the SIS, not in Moodle.
- Log every sync action with its cause. Record the timestamp, the actor (a person or a system), the SIS change that triggered it, the affected student, the course and the state before and after.
- Keep manual exceptions separate. Limit manual enrollments to documented cases, and record who added each one and why.
- Set log retention on purpose. Choose a "Keep logs for" value that matches your retention rules, and keep the sync's own log at least as long.
- Use Moodle's privacy tools. Since Moodle 3.5, the data privacy tool handles data requests, such as exports and deletions, and provides a data registry where you assign purposes and retention periods to categories and courses.
- Run the same end-of-term routine every time. Close submissions, hide or move courses, keep instructor access for grade reviews, then back up and delete on schedule.
- Rehearse an access request. Pick a former student and time how long it takes to list their courses, their enrollment changes and the work you still store. If it takes days, fix the process before a real request arrives.
How Classeo handles it
Every provisioning, enrollment and archive action Classeo performs is timestamped and tagged with its actor. When a registrar asks who removed a student from a course, the answer becomes a lookup: which SIS change triggered it, when it reached Moodle and what exactly changed.
At the end of term, Classeo hides or archives completed courses according to your institution's policy, meta-course parents and their section courses together, so no course is left half-closed. Your team still decides the policy; Classeo applies it the same way every term.
Classeo is a synchronization relay: student data stays in your SIS and your Moodle, and Classeo doesn't keep long-term copies. It runs on Quebec-resident infrastructure. The Moodle administration page describes the audit log, the FAQ answers common security and privacy questions, and the about page has more on LS2 Innovation. For the add/drop side of the same trail, read why students lose access during late adds and drops, and for the cost of keeping scripts, custom scripts vs. a maintained integration.
Key takeaways
- Moodle's standard log shows what changed and which account did it, but sync changes usually appear under a service or admin account while the real cause sits in the SIS.
- A useful audit trail links each Moodle change to the SIS change behind it, with a timestamp, an actor and the affected student.
- Moodle has no single archive button: end-of-term archiving combines hiding courses, an archive category, read-only access, backups and scheduled deletion.
- Law 25 and the GDPR expect accountability, security measures, limited retention and timely answers to access requests; confirm the specifics with your privacy officer.
- Set Moodle's log retention deliberately, in line with your retention rules, rather than keeping the default or trimming logs for performance.
See every enrollment change with its source
A 30-minute demo of Classeo's audit log and end-of-term archiving: who changed what, when, from which SIS change, and how courses close at term end.
Book a demoFrequently asked questions
How can I see who changed a student's enrollment in Moodle?
Open the course logs, filter by the student and look for user enrolled, user unenrolled and user enrolment updated events. Each entry shows the time, the account that made the change and its origin, such as the web interface, web services or a command-line task. If a sync made the change, the account is usually a service or admin account, so the actual cause has to be traced in the SIS or in the sync's own log.
What does Quebec's Law 25 require for Moodle data?
In general terms, Law 25 asks organizations to be accountable for the personal information they hold: a person in charge of its protection, governance policies, security measures suited to the data, retention limited to what the purpose requires, privacy impact assessments for new information systems, and proper handling of access requests and confidentiality incidents. How it applies to your Moodle depends on your institution, so confirm the specifics with your privacy officer.
How long should we keep Moodle courses after the end of term?
There is no single answer. Keep courses available to instructors long enough for grade reviews and appeals, then follow your institution's retention rules for course content and student work. Final grades are normally kept in the SIS, which holds the official record. Agree on the periods with your registrar, records manager and privacy officer, and apply them the same way every term.
Does Classeo keep a copy of student data?
Not long term. Classeo acts as a synchronization relay between the SIS and Moodle and doesn't store student data long term: the data stays in your SIS and your Moodle. What Classeo adds is an audit log of every provisioning, enrollment and archive action, each one timestamped and tagged with its actor. Classeo runs on Quebec-resident infrastructure.