Which regulations require LMS audit logs, what fields to capture, how long to keep them, and how to configure audit logging in Moodle — plus SIEM and alerting.
Got an LMS decision on your plate?
45-minute call. Plain-English audit. Fixed-price quote if there's a fit, or a "no" if there isn't. No deck. No pitch.
Designing LMS role-based access control for a multi-site org — least-privilege roles, scoped visibility, separation of duties, and why over-broad admin is an audit finding.
What LMS data ownership actually means in your contract, and how to keep control of training records you are legally required to produce.
A practical SOC 2 due-diligence checklist for LMS buyers — what to ask for, what to read, and what SOC 2 doesn't cover.
When something goes wrong in a system that holds your workforce's personal data, the first question is always the same: who did what, and when? LMS audit logs are how you answer it. They are the record of every meaningful action taken in the platform — who logged in, who changed a role, who exported a report, who deleted a record. Without them, you are guessing. With them, you can reconstruct exactly what happened, prove it to an auditor, and catch a problem while it is still small.
This guide covers what to log and the fields each entry needs, which regulations actually require audit logging and how long they expect you to keep it, how to keep logs trustworthy, how to turn passive logging into active access monitoring — and, concretely, how to configure all of it in Moodle. It is written for the IT and security leaders and the HR and L&D owners who share responsibility for the training platform. This is general guidance, not legal or security advice; confirm your own obligations with counsel and your security team.
Not every event is worth recording, but a defensible LMS audit log captures the actions that change access, move data, or touch the security of the platform. At minimum:
A log that says "a record was changed" without saying who changed it is not much of a log. Each entry should answer, on its own, the who, what, when, and where — plus what was touched and whether it worked. That maps to a consistent set of fields, and it is worth agreeing them up front so every event source records the same shape.
The acting user — a unique ID, not just a display name.
user=a.miller (id 4821)The action, as a specific event type.
role.assignedA precise timestamp, ideally in UTC.
2026-08-24T14:32:07ZSource IP and session, so you can place the action.
ip=10.2.4.19 · session=a1f9…The affected object, and the old and new value for a change.
target=user(5567) role: Learner → ManagerWhether the action succeeded or failed.
result=successThis is the standard "who, what, when, where, outcome" model that logging guidance such as the OWASP logging cheat sheet and NIST's guide to log management (SP 800-92) describe. The detail that separates a real audit trail from a basic activity feed is the before/after on a change and the outcome on an attempt — a role change from Learner to Manager, or a login that failed, is exactly the kind of event a reviewer wants to see spelled out.
Audit logging is not just good practice — it is a named expectation across the frameworks a corporate LMS is measured against. If your training platform holds employee PII, touches regulated records, or comes up in a customer security review, one or more of these applies to you.
A few of these deserve a sentence more, because they are the ones that come up most for training platforms:
The practical takeaway: you rarely get to decide whether to log. The framework decides that. What you decide is whether your platform can actually produce logs that satisfy it.
Audit logs are one of the most requested pieces of evidence in any security review, and for good reason. A control you cannot observe is a control you cannot prove.
When a customer's security team, a SOC 2 assessment, or an internal auditor evaluates your LMS, they are not satisfied by a claim that access is restricted. They want to see that access is logged and monitored — that if an administrator escalated a privilege or exported the whole user table, there is a record of it and someone would notice. Audit logging is a named expectation across the frameworks above precisely because it is what makes accountability real.
Logs also serve you directly when something goes wrong. For incident response, a breach investigation, or a dispute over who changed a training record, the audit log is the primary source of truth. It turns "we think" into "we know, here is the entry."
A log an insider can quietly edit is worse than no log, because it creates false confidence. For audit logs to carry weight, they have to be tamper-evident — it must be difficult to alter or delete entries without leaving a trace.
The core techniques are straightforward:
The single most effective step is getting logs off the LMS and into a dedicated logging or SIEM system quickly, so the authoritative copy lives somewhere the platform's own admins cannot rewrite.
Audit logs are only useful if they still exist when you need them, and breaches are frequently discovered months after they happen. A log retention window measured in days will not cover an investigation into an incident that started last quarter.
Unlike "log the right events," retention often comes with a specific number attached. Set your window to the longest requirement you answer to, and store the logs somewhere durable and access-controlled for that whole period rather than rotating them away to save space.
Log retention is its own decision, separate from how long you keep training records themselves — which we cover in the training record retention and deletion guide. A rough floor for most organizations is one year; regulated employers should expect to keep audit logs considerably longer.
Recording events is necessary but passive. A log nobody reads until after an incident is a forensic tool, not a defense. Active access monitoring turns the same data into early warning.
Sign-ins (including failures), role and permission changes, data exports, and admin configuration changes.
Entries are written and never edited in place. In Moodle this is the standard log store — the mdl_logstore_standard_log table.
The authoritative copy leaves the LMS for a SIEM the platform's own admins cannot rewrite, and sits alongside the rest of your security telemetry.
Rare, high-impact actions trigger a response in hours, not a discovery in months.
The mechanism is a SIEM — Security Information and Event Management — a system that ingests logs from the LMS and your other systems, correlates them, and raises alerts on patterns that indicate trouble. Integrating your LMS logs into a SIEM means training-platform events sit alongside the rest of your security telemetry rather than in an isolated silo.
The events most worth alerting on are the ones that combine high impact with rarity in normal use:
Alerting on these means a suspicious action prompts a response in hours, not a discovery in months.
Because so much of the LMS market runs on Moodle, it is worth getting concrete. Moodle logs a great deal out of the box; the work is in turning the right stores on, setting retention deliberately, and getting the stream somewhere your security team can watch it. The admin navigation below is stable across current Moodle 4.x and 5.x. (This is general configuration guidance — test changes in a staging site first.)
Go to Site administration → Plugins → Logging → Manage log stores. Current Moodle ships two stores: the Standard log (logstore_standard) and the External database log (logstore_database). The standard log is the one to keep enabled; it writes structured events to the mdl_logstore_standard_log table, which is your primary audit trail.
On the Standard log's settings page you will find a handful of choices that matter for auditing:
logguests) — on by default; keep it on so anonymous access is recorded.On that same Standard log settings page, the "Keep logs for" setting (loglifetime) controls retention. Its default is "Never delete logs" — which is safe for evidence but grows the table indefinitely. Set it deliberately to match the longest retention window you identified above, and let Moodle's daily cleanup task (\logstore_standard\task\cleanup_task, which runs via cron around 04:00) prune anything older. Do not shorten this below your compliance floor to save disk.
Day to day, logs live under Site administration → Reports → Logs for the whole site, with Reports → Live logs giving you a real-time view. Every course also has its own Course administration → Reports → Logs, so a site admin can drill into one course without wading through everything. Logs can be filtered and downloaded for an auditor.
Separately from the event log, Moodle records every change to site configuration in Site administration → Reports → Config changes (the core report_configlog). This is always on — Moodle writes to the mdl_config_log table whenever a setting changes — and it is exactly what you want when the question is "who turned this security setting off, and when?"
Moodle's built-in answer to active monitoring is event monitoring. Go to Site administration → Reports → Event monitoring rules and enable it there (the setting is tool_monitor / enablemonitor; it is off by default for performance, and it is not under Advanced features). You can then define rules — for example, notify an administrator whenever a role is assigned, or when a report is exported — and Moodle sends a message when the rule's threshold is met. Teachers with the right capability can set course-level rules too, under Course → Reports → Event monitoring rules.
For real security monitoring you want the stream off the box. The External database log store (logstore_database) writes events to a separate database — set its dbdriver, dbhost, and dbname — that a SIEM can then read, keeping the authoritative copy out of reach of the LMS's own admins. For deeper or custom integrations, Moodle's Events API lets you register observers (via a plugin's db/events.php) that forward specific events wherever you need them.
Moodle Workplace — the commercial distribution available through certified partners — layers extra reporting and automation on top: a drag-and-drop report builder with scheduled delivery, dynamic rules that act on events automatically, recurring certifications, and delegated per-tenant administration and audit. Note that current core Moodle now also ships a custom report builder, so treat Workplace as an enhancement of these capabilities rather than the only route to them.
Audit logs and access control are two halves of the same job. Logging tells you what people did; least-privilege access control limits what they are able to do in the first place. Together they enforce accountability: fewer people hold sensitive permissions, and every use of those permissions is recorded.
If your role model is loose — broad admin rights handed out widely — your logs will be full of high-privilege actions that are hard to distinguish from misuse. Tightening roles first, as covered in role-based access control, makes the audit log sharper, because a privileged action becomes a notable event rather than background noise.
How much of this you can actually do depends on whether you own the platform. On a rented SaaS LMS, you get the logs the vendor decides to expose — often a limited admin activity view, sometimes an export, rarely the raw, complete stream you would want to feed into your own SIEM. If the vendor does not log an event, or does not surface it, that visibility simply does not exist for you. You also cannot set your own retention or point the external log store at your own database.
When you own the platform — a bespoke build or Moodle on your own infrastructure — you have full, direct access to everything above. You can capture every event you care about, enable the external database log store, ship the raw stream to your SIEM, set your own retention with loglifetime, and enforce your own tamper-evidence. The audit trail becomes genuinely yours, which is the practical core of owning your training data and platform. Being able to answer "who did what, and when" without asking a vendor is a meaningful security advantage.
LMS audit logs are the record that makes accountability real — log admin actions, permission changes, data exports, and authentication, capture who and what and when and from where, and keep the entries tamper-evident and retained long enough to cover an investigation. They are not optional: ISO 27001, SOC 2, HIPAA, PCI DSS, and 21 CFR Part 11 all name logging and monitoring as controls, and several attach a specific retention period. Go past passive logging: feed the stream to a SIEM and alert on the high-risk events, bulk exports and privilege changes especially, so you catch problems early. In Moodle, the standard log store, the "Keep logs for" setting, the config-changes report, event-monitoring rules, and the external-database log store give you every piece — provided you own the platform and can actually reach them.