How secure is your LMS? A buyer's guide to LMS security

In December 2024, an attacker used stolen credentials to walk into PowerSchool's customer support portal. The portal did not support multi-factor authentication at the time, as PowerSchool later confirmed to TechCrunch. CrowdStrike's investigation dates the first unauthorized access to 19 December. The attacker claimed to have taken records on roughly 62 million students and 9.5 million teachers, as reported by BleepingComputer. Those figures are the attacker's own and have not been confirmed. Not a sophisticated exploit. One login that should never have been enough.

That breach happened to an education platform holding exactly the kind of personal data your LMS holds. And it's exactly why LMS security deserves more than a single line in your requirements document that says "GDPR-compliant." If you're evaluating a learning platform right now, this guide walks you through what actually matters: the features worth checking, what GDPR compliance does and doesn't tell you, why the location of a server isn't the whole story, and the exact questions to ask a vendor before you sign.

What does LMS security actually mean?

LMS security is the protection of the learning platform itself: the personal data it stores, the people and systems that can access it, and the legal framework that decides who can reach that data. It covers three layers: the technical layer (encryption, access control, authentication), the organizational layer (how the vendor tests, monitors and responds to incidents), and the legal layer (contracts, jurisdiction and regulation).

One important distinction before we go further. This guide is about the security of the platform, not about using a platform to teach security. If you're looking for ways to deliver security awareness training or other compliance courses to your team, that's a different question, and we've covered it in our guide to compliance training. Here, we focus on whether the LMS itself can be trusted with your data.

Why is LMS data more sensitive than it looks?

Because an LMS doesn't just store courses. It stores employment-linked personal data: names, email addresses, roles, departments, manager relationships, onboarding status, assessment results and compliance certificates. In practice, your LMS is an HR system wearing a training badge. If that data leaks, you're not explaining a lost course catalog. You're explaining which employees failed their certification, who is in a performance program, and personal details for your entire workforce.

The threat picture backs this up. According to the 2026 Verizon Data Breach Investigations Report, the education sector recorded 1,302 security incidents, 1,252 of them with confirmed data disclosure. And according to Check Point Research's Q2 2025 threat report, the education sector faced an average of 4,388 cyberattacks per organization per week, more than double the global average and a 31% increase year over year. Learning platforms sit in an actively targeted category.

The financial consequences are just as concrete. IBM's 2026 Cost of a Data Breach Report put the global average cost of a breach at USD 4.99 million, a record high and a 12% rise in a single year. Numbers like that are worth keeping in mind the next time LMS data security feels like a box-ticking exercise in procurement.

Which core security features should you evaluate?

A secure LMS gets the fundamentals right before anything else. These are the features to verify, not just ask about:

• Encryption in transit and at rest. All traffic over TLS, stored data encrypted. This should be a given, but confirm it anyway.
• Multi-factor authentication (MFA). The PowerSchool breach started with one credential and no MFA. Make sure MFA is available and can be enforced, especially for administrators.
• Single sign-on (SSO). SAML or OpenID Connect (OIDC) support means your existing identity provider controls access, offboarded employees lose access the moment they leave your directory, and there are no separate LMS passwords to lose in a breach.
• Granular roles and permissions. Administrators, course managers and participants should each see only what they need. Broad default permissions are a quiet risk.
• Audit logs you can actually use. Not just "logging exists," but logs you can search, export and feed into your own monitoring when something looks wrong.
• Backups and recovery. Ask about backup frequency, where backups are stored, and how quickly data can be restored.
• Regular penetration testing. A vendor who pays independent experts to attack their own platform takes security seriously. Ask when the last test was done and whether you can see a summary.

Most established vendors will check these boxes. That's the point: this list is the baseline, not the finish line. The harder questions come next.

What does "GDPR-compliant" cover, and what doesn't it?

GDPR compliance means the vendor processes personal data according to EU rules: a lawful basis for processing, support for data subject rights, breach notification routines, and a Data Processing Agreement (DPA) under Article 28 of the regulation. When you're shopping for a GDPR-compliant LMS, the DPA is the document that matters most. It defines what the vendor may do with your data, which sub-processors they use, and what happens when the contract ends.

But "GDPR-compliant" is a legal baseline, not a security audit. Nearly every vendor selling into Europe claims it. What the claim doesn't tell you:

• Whether their practices match their paperwork. Certifications like ISO 27001 and SOC 2 show that processes have been independently audited. Ask for the scope: which systems and locations the certificate actually covers.
• How they handle incidents in practice. Ask about their incident response plan and how quickly they notify customers of a personal data breach. "Within 24 hours" and "without undue delay" are very different commitments.
• Who their sub-processors are. Your data is only as protected as the weakest link in the vendor's own supply chain.

The enforcement pressure behind these questions is real and growing. DLA Piper's January 2026 GDPR Fines and Data Breach Survey found that personal data breach notifications in Europe averaged 443 per day, a 22% increase year over year, and that regulators have issued EUR 7.1 billion in aggregate GDPR fines since May 2018. Compliance on paper won't protect you from either statistic. Practice will.

The EU server trap: why hosting location is not the same as data sovereignty

Here's the question almost nobody asks during an LMS demo: not where is my data stored, but which laws can reach it. The two are not the same, and the difference is the most overlooked part of LMS security.

Many US-owned vendors host European customer data in EU data centers and present this as the answer to GDPR concerns. The server is in Frankfurt or Dublin, so the data is European. Except legally, it isn't that simple. The US CLOUD Act (2018) allows US federal law enforcement to compel US-based technology companies, via warrant or subpoena, to produce stored data regardless of where that data is physically located. This is not automatic or instant access; it requires due legal process. But the key point stands: the reach follows the company's jurisdiction, not the server's postal code. An EU data center owned by a US company is still within reach of US legal process.

The mechanism that's supposed to reconcile this tension, the EU-US Data Privacy Framework (DPF), is itself in legal motion. In September 2025, the EU General Court upheld the framework, dismissing the Latombe challenge. An appeal before the Court of Justice of the EU (Case C-703/25 P) was filed in October 2025 and remains pending. So the DPF is valid today, and it may stay valid. But its two predecessors, Safe Harbor and Privacy Shield, were both struck down by the same court system, and anyone who built their data strategy on those frameworks remembers the scramble that followed. The honest summary is uncertainty: not a crisis, but not a foundation you'd want your entire data setup to depend on either.

Regulation is also pushing this question onto your desk whether you ask it or not. NIS2 (Directive (EU) 2022/2555, Article 21) requires essential and important entities to implement supply chain security measures, including the cybersecurity aspects of their relationships with direct suppliers and service providers such as cloud providers. Member States were required to transpose it by 17 October 2024. If your organization falls under NIS2, your LMS vendor is part of your supply chain, and assessing their security posture is no longer optional diligence. It's a requirement.

This is why data sovereignty has moved from a niche legal topic to a standing item on European IT agendas. And it's why the structure of a vendor matters, not just their contracts. A European-owned vendor hosting data in the EU sits outside the CLOUD Act's reach structurally: there is no US parent company for a US court to compel. No DPA clause or framework ruling can give a US-owned vendor that same position. Ownership settles who can be compelled to hand over your data. It doesn't settle everything, so ask for the sub-processor list too and see what sits underneath. When you evaluate a secure learning management system, ask about ownership and jurisdiction with the same seriousness you ask about encryption.

How do you keep data secure during an LMS migration?

Migration is the moment your data is most exposed: it leaves one controlled environment, travels, and lands in another. A few practices keep that window safe.

1. Migrate less than you have. Start with a data inventory and apply GDPR's minimization principle. Participant records from eight years ago probably shouldn't make the trip. Migration is the best data cleanup opportunity you'll ever get.
2. Use encrypted, controlled transfer routes. API-based migration or encrypted exports, never unencrypted CSV files sitting in inboxes or shared drives.
3. Control access during the project. Migrations often involve temporary admin accounts for consultants and vendor staff. Track every one of them, and revoke them the day the project ends.
4. Decommission the old platform properly. Request written confirmation that the previous vendor has deleted your data, in line with your DPA's termination terms. Data forgotten on a retired platform is a breach waiting for a discovery date.
5. Verify after landing. Spot-check migrated records, confirm permissions came through correctly, and make sure audit logging is active in the new environment from day one.

Ask your new vendor how they support each of these steps. Their answer tells you a lot about how they'll treat your data after the migration too.

The vendor due-diligence checklist: what to ask before you sign

Bring these questions to the RFP or the demo. A strong vendor will have ready answers; hesitation is also an answer.

Ownership and jurisdiction

• Who owns the company, and in which country is the corporate parent registered?
• Where is our data physically stored, and under which legal jurisdiction does the company operate?

Data processing

• Can we see your standard DPA before contract negotiations?
• Which sub-processors do you use, and where are they located?
• What happens to our data when the contract ends, and how is deletion confirmed?

Security practices

• Which certifications or frameworks do you hold or follow (ISO 27001, SOC 2), and what is their scope?
• When was your last independent penetration test?
• How do you encrypt data in transit and at rest?

Access and authentication

• Do you support SSO (SAML/OIDC) and enforced MFA, including for admin accounts?
• How granular are roles and permissions?
• Can we export and search audit logs ourselves?

Incidents and continuity

• What is your incident response process, and how quickly do you notify customers of a personal data breach?
• What are your backup routines, and what recovery times do you commit to?

If a vendor answers all of these clearly, in writing, you've done more due diligence than most procurement processes ever manage.

How does Learnifier approach security?

We figured you'd ask, since we just told you to. Learnifier is a Swedish company, European-owned, and no US parent company sits above us for a US court to compel. You can also choose to have your data hosted in Sweden, with a provider that runs no sub-processors of its own and employs only Swedish citizens.

Like every cloud platform, we work with infrastructure and service providers. We publish the full list rather than summarizing it, and our support environment is self-hosted rather than running on a third-party platform. We work in accordance with ISO 27001, and we treat GDPR as the baseline it should be, not as a selling point. More detail, from encryption to data processing terms, is on our security page.

But honestly, the best next step isn't reading about us. It's taking the checklist above into your next vendor conversation, whoever it's with. Including ours.