SOC 2 and Your LMS: A Security Due-Diligence Checklist

"Are you SOC 2 compliant?" is the question almost every US security team asks an LMS vendor, and "yes" is almost always the answer. The problem is that the question and the answer are both too blunt to be useful. A LMS SOC 2 report can be exactly what you need, or it can be a year-old Type I snapshot that excludes the part of the platform holding your data.

If you are responsible for employee training records across multiple sites, your LMS holds PII at scale. Knowing how to read a SOC 2 report — and what to ask for beyond it — is the difference between real due diligence and a checkbox. This is the working checklist.

What SOC 2 actually is

A SOC 2 report is an independent attestation, performed by a licensed CPA firm under the AICPA's Trust Services Criteria, that an organization's controls meet defined standards. The criteria cover security (always) plus, optionally, availability, confidentiality, processing integrity, and privacy.

Two distinctions matter most:

• Type I vs Type II. Type I assesses whether controls are designed properly at a point in time. Type II assesses whether they operated effectively over a period — typically 6 to 12 months. Type II is the one that tells you the controls actually work in practice, not just on paper.
• Scope. SOC 2 covers a defined system boundary. A vendor can hold a clean SOC 2 for its core platform while your specific deployment, region, or add-on service sits outside the audited scope.

So "we're SOC 2 compliant" is the start of the conversation, not the end of it. If your organization operates internationally, you may hear ISO 27001 raised alongside SOC 2 — the two overlap but aren't interchangeable, and it helps to know what ISO 27001 certification of an LMS actually means before treating either as a checkbox.

The due-diligence checklist

Run every LMS option — and any hosting partner for an owned build — through these.

1. Get the actual report, under NDA

A vendor that is genuinely SOC 2 Type II will share the report under NDA. A "letter of attestation" or a logo on a webpage is not the report. If they won't share it, treat that as a finding.

2. Confirm it's Type II, and current

Check the report type and the coverage period. A Type II covering a window that ended 14 months ago is stale — ask for the current one or a bridge letter covering the gap.

3. Read the scope — is your deployment in it?

This is the step most buyers skip. Confirm that the audited system boundary includes the product edition, region, and hosting environment you will actually use. Multi-region or single-tenant deployments are sometimes outside the standard scope.

4. Read the exceptions

SOC 2 reports list control exceptions and the auditor's findings. A report with zero exceptions is rare and not automatically reassuring. What matters is whether the exceptions are material to data you care about, and whether the vendor has documented remediation.

5. Get the subprocessor list

Your data rarely stays inside one vendor. CDNs, analytics, email, and AI services are subprocessors, each with its own security posture and often its own region. Ask for the current subprocessor list and confirm each is covered by appropriate controls. This connects directly to data residency — see LMS data residency for US and EU operations.

6. Pin down the breach-notification SLA

SOC 2 does not, by itself, commit the vendor to telling you about a breach within a defined timeline. That belongs in your contract. Require a written breach-notification SLA — how fast, through what channel, with what information.

7. Confirm a documented erasure process

When you need to delete an employee's data — for a privacy request or at contract end — can the vendor erase it across all tiers, including backups, and confirm it? Ask for the documented process, not a verbal assurance.

8. Check SSO and access controls

How users authenticate is a core security control. SAML/OIDC single sign-on lets you centralize access and offboarding rather than managing separate LMS credentials. We cover the details in the LMS single sign-on guide, and the capability itself in SSO and SAML.

What SOC 2 doesn't cover

It is worth being clear about the limits, because a clean SOC 2 can create false comfort.

• It doesn't grant you data ownership. SOC 2 is about controls, not contractual rights. Ownership, export, and exit are separate — covered in who owns your training data.
• It doesn't guarantee residency. A SOC 2 vendor can still host your data wherever its infrastructure runs unless residency is in the contract.
• It isn't a privacy compliance certificate. GDPR and CCPA obligations are yours regardless of the vendor's SOC 2 status.
• It doesn't cover your configuration. SOC 2 covers the vendor's controls. How you configure roles, permissions, and integrations is your responsibility — the shared-responsibility model applies.

The owned-platform angle

When you own the platform, security due diligence shifts but doesn't disappear. You assess your hosting partner's SOC 2 rather than a SaaS vendor's, and you gain something a SaaS contract can't give you: full visibility into the system boundary, the data location, and the access controls, because you control them. The shared-responsibility line is clearer when the platform is yours.

That clarity is the real point of due diligence — not collecting attestations, but knowing exactly who is responsible for what, and being able to prove it when an auditor or your own insurer asks.

The bottom line

SOC 2 is a useful baseline, not a finish line. Get the actual Type II report, read the scope and exceptions, confirm your deployment is in it, and get the things SOC 2 doesn't cover — breach SLA, erasure, subprocessors, residency — into the contract. A vendor that handles these questions cleanly is showing you how they'll handle your data. One that deflects is showing you that too.