HIPAA and your LMS: what compliance actually requires

Almost everyone who lands here arrives worried about the same thing: that their training platform is a HIPAA liability waiting to be discovered. Usually, it's less than you fear. The single most useful fact in this whole area is that HIPAA doesn't regulate software — it regulates a particular kind of data. So the first question isn't "is my LMS compliant." It's "is there any protected health information in it at all?" For most training platforms, the honest answer is no.

This guide walks the real requirements in plain language, every regulatory point tied to its source, so you can tell where you actually stand. We build and host regulated Moodle™ deployments for a living, and the most valuable thing we do on a first call is often tell a worried client they're out of scope.

First question: is there PHI in your LMS at all?

Protected health information (PHI) is defined at 45 CFR § 160.103: individually identifiable health information relating to a person's health, care, or payment for care — information that identifies the individual, or that could reasonably be used to. The trigger is the presence of that data. A platform doesn't become a HIPAA concern because it's a health-sector tool; it becomes one when it holds this specific kind of information.

Generally out of scope: a training and completion LMS that holds only workforce enrollments, course titles, quiz scores, and certificates. That's workforce and employment data, not patient data — and the same regulation explicitly excludes from PHI the employment records a covered entity holds in its role as employer, as well as FERPA education records. De-identified data (45 CFR § 164.514) is out of scope too.

In scope: when the LMS actually stores or transmits PHI. That happens more often through the side door than the front: patient-specific case data embedded in a course, real patient records used as training material, a clinical simulation tied to real people, or an integration, an upload field, or a free-text box that quietly pulls PHI in. So the reassurance above holds only if your LMS in fact stores no PHI. It's worth confirming that deliberately rather than assuming it.

Get a free scope check
Tell us what your LMS stores and we'll tell you plainly whether HIPAA is even in play. We reply within one business day.

Privacy Rule vs. Security Rule: which one is your LMS problem?

HIPAA is not one rule. Two matter here, and they cover different ground.

The Privacy Rule (45 CFR Part 160 and Part 164, Subparts A and E) governs PHI in any medium — oral, paper, or electronic — and controls how it may be used and disclosed, the "minimum necessary" principle, and individuals' rights over their records.

The Security Rule (45 CFR Part 164, Subpart C, §§ 164.302–164.318) governs only electronic PHI (ePHI) and requires reasonable and appropriate administrative, physical, and technical safeguards. It does not cover oral or paper PHI. HIPAA's obligations fall on covered entities — health plans, healthcare clearinghouses, and providers who transmit health information electronically — and on their business associates.

The takeaway for an LMS is simple: if your platform holds ePHI, the Security Rule's safeguards are your operative checklist. That's an engineering and hosting problem — which is exactly where we work.

The Security Rule is a risk analysis, not a feature checklist

Here's the misconception that trips up buyers: the belief that a product can simply tick the HIPAA boxes. The Security Rule is deliberately risk-based, technology-neutral, and scalable — it tells you what to protect against, not which product to buy. Two organizations can meet it with very different implementations.

Each implementation specification in the rule is labeled either Required or Addressable. This is the detail people misread. Addressable does not mean optional. Per 45 CFR § 164.306, for an addressable spec you must implement it, or document why it isn't reasonable and appropriate for you and implement an equivalent alternative that is. The foundational Required step is the risk analysis at § 164.308(a)(1)(ii)(A): it's what determines "reasonable and appropriate" for your specific deployment.

Encryption is the clarifying example. It's technically Addressable both at rest and in transit — yet a genuine risk analysis will almost always conclude it's reasonable, and unencrypted ePHI counts as "unsecured" the moment there's a breach. So while the letter of the rule calls it addressable, in practice it's expected. Treat "Addressable" as "justify in writing," not "skip."

The three safeguard groups, and how a self-hosted Moodle supports each

If your LMS is in scope, the Security Rule sorts its safeguards into three groups. Below is each group with the specifications that matter for a learning platform, and how a self-hosted Moodle deployment can be configured and hosted to support them. One honest caveat first: the mappings below are our engineering interpretation of how to support each safeguard — they are not prescribed by HHS — and specific Moodle features are version-dependent, so they should be verified against your target Moodle release before anyone relies on them.

Administrative safeguards (§ 164.308). The required pieces include the risk analysis, a named security official, and a contingency plan whose data-backup and disaster-recovery specs are themselves required. In a self-hosted Moodle, role and capability permissions in each context implement least-privilege access management; the logging subsystem and the config-changes report give you the information-system-activity review; and scheduled automated backups are the technical half of your data-backup plan. The policies and the risk analysis around them are yours to own.

Physical safeguards (§ 164.310). Facility access controls, workstation security, and device and media controls — including media disposal and re-use, referencing the NIST SP 800-88 sanitization standard. For a self-hosted deployment these are largely inherited from your hosting provider's data center. That inheritance is precisely why the hosting provider must sign a business associate agreement — more on that next.

Technical safeguards (§ 164.312). Unique user IDs (no shared logins), audit controls, person-or-entity authentication, and transmission security. Moodle supports these with individual accounts, a configurable session timeout, single sign-on and multi-factor authentication (MFA landed in Moodle core in version 4.3; on earlier releases it comes from the tool_mfa plugin or your identity provider), and its logging subsystem as the audit trail. Enforced HTTPS with HSTS covers encryption in transit; encryption at rest is handled at the operating-system or database layer of the hosting stack, since Moodle does not encrypt its own database by default.

The BAA nobody can skip — including your host

This is the part that decides whether self-hosting is done correctly, and it's where a vendor becomes directly liable. A business associate is anyone who creates, receives, maintains, or transmits PHI on your behalf, and they must sign a business associate agreement (BAA) before touching ePHI.

Per HHS guidance, a software company that hosts patient information on its servers, or that accesses patient information while troubleshooting, is a business associate. Merely selling software with no access to PHI is not. So a firm doing custom development, migration, SCORM repair, or managed hosting that touches your ePHI must sign a BAA and is directly liable under HIPAA for the safeguards it covers. If the work only ever touches training and completion records with no PHI, a BAA usually isn't required — but that scope should be confirmed explicitly, in writing.

The point teams miss most: your cloud or infrastructure host must also sign a BAA. HHS's cloud-computing guidance is explicit that a cloud service provider maintaining ePHI is a business associate — even a "no-view" provider that stores only encrypted data and doesn't hold the decryption key. Encryption does not exempt it, and it doesn't qualify for the narrow conduit exception, which covers only transient transmission (think of an internet service provider or the postal service), not persistent storage. Using such a provider without a BAA is itself a violation. The major infrastructure providers — AWS, Google Cloud, Azure — and HIPAA-eligible managed hosts all offer BAAs for exactly this reason.

Why “HIPAA-compliant software” is a red flag

If a vendor sells you a "HIPAA-compliant LMS," be careful. HHS and its Office for Civil Rights do not endorse, certify, or recognize any product, vendor, or private "HIPAA compliant" certification. In HHS's own words, such certifications "do not absolve covered entities of their legal obligations under the Security Rule," and obtaining one does not prevent OCR from later finding a violation.

Compliance is a property of your organization — its policies, its documented risk analysis, its workforce behavior, its safeguards, and its contracts. It is never a checkbox on a piece of software. OCR has gone as far as warning that overstating compliance is itself a marketing red flag. So here's our position, plainly: we engineer and host Moodle so that it supports your HIPAA Security Rule obligations. We will never sell you a "HIPAA-compliant platform," because no such thing exists. Saying that out loud is, we've found, what sophisticated compliance buyers actually want to hear.

Breach notification, and why encryption is the business case

The Breach Notification Rule (45 CFR §§ 164.400–414) sets what happens when unsecured PHI is breached: notify affected individuals without unreasonable delay and no later than 60 days after discovery. A breach touching 500 or more residents of a state also requires notice to prominent media and to the HHS Secretary within 60 days; smaller breaches are logged and reported to HHS annually. A business associate that discovers a breach must notify the covered entity.

The word doing the work is unsecured. PHI rendered unusable, unreadable, or indecipherable to unauthorized people — using the methods HHS specifies (NIST SP 800-111 for data at rest; FIPS 140-2-validated encryption and NIST SP 800-52 for data in transit; SP 800-88 for destruction) — is "secured," and its breach doesn't trigger the individual-notification duty. This is not a blanket "any encryption is a safe harbor" rule: encryption that's misconfigured or doesn't meet the specified methodology doesn't count, and a breach that includes access to the keys can still be reportable.

Read as a business case, that's decisive. Encryption that meets the HHS/NIST standard can turn a lost server or a stolen backup from a reportable, reputation-damaging incident into a documented non-event. It's the clearest reason to encrypt an ePHI-holding Moodle at both layers — and to do it to the right standard, not just "on."

The reassuring flip: your LMS is how you prove the training happened

Here's the turn most healthcare teams don't expect. HIPAA doesn't just constrain your LMS — it usually gives your LMS a job. The Security Rule at § 164.308(a)(5) and the Privacy Rule at § 164.530(b) both require a workforce security-awareness and training program. No fixed frequency or curriculum is mandated; the training must be reasonable and, crucially, documented — and that documentation has to be retained for six years (§ 164.316; § 164.530(j)).

Documentation is exactly what a learning platform is built to produce: enrollments, completion tracking, quiz scores, dated certificates, and audit logs are the evidence that the required training actually occurred. And because that training-delivery LMS generally holds only workforce completion data — no PHI — it typically stays out of HIPAA scope itself while doing the compliance job for you. The tool that satisfies the training mandate is usually the one you didn't have to lock down.

We are engineers, not lawyers

If you're weighing where you stand, the most useful next step is usually the smallest: a short call to work out whether your LMS is even in scope. Often it isn't, and you'll leave the call with less to worry about than you came in with. If it is, we'll walk the safeguards against your actual deployment and tell you what supporting them would take.

Book a 20-minute scoping call
We'll help you figure out whether your LMS is in HIPAA scope, and what the Security Rule would mean for it. We reply within one business day — or call (615) 396-7139.

HIPAA and your LMS: questions we actually get