Your LMS processes employee PII, proprietary training content, xAPI statements, SCORM completion records, and – in regulated industries – data tied directly to compliance certifications and workforce credentialing. That makes it a Tier 1 data processor under most enterprise vendor risk frameworks. Yet when procurement teams evaluate LMS platforms, SOC 2 Type II is still frequently treated as a checkbox: does the vendor have one? Yes. Move on. That approach accepts risk that a closer read of the report would immediately surface.

This guide addresses the specific, practical gaps between what a SOC 2 Type II report covers and what LMS buyers actually need to verify – including how LMS-specific data flows (xAPI 1.0.3, SCORM 2004 4th Edition, LTI 1.3) interact with audit scope, what subservice organization carve-outs mean for your data, and how to read exceptions before signing a contract.

The SOC 2 Type II Framework: What It Actually Tests

SOC 2 is governed by the AICPA’s Trust Services Criteria (TSC), last updated in 2022 (TSC 2022). A Type II report differs from Type I in one critical dimension: it attests to operating effectiveness over a defined period, typically 6–12 months, not merely control design at a point in time. An auditor issues one of two opinions: unqualified (clean) or qualified (exceptions noted).

The five TSC categories, with their direct relevance to LMS environments

Security is the only mandatory category. An LMS vendor can hold a SOC 2 Type II report covering Security only – and that report says nothing verifiable about how long they retain learner PII, whether completion records are processed with integrity, or what their uptime SLA is backed by. Always confirm which TSC categories are in scope before treating the report as meaningful.

The Structural Problem: Subservice Organizations and Scope Exclusions

This is the single most overlooked issue in LMS procurement reviews, and the gap that existing coverage almost entirely misses.

Enterprise LMS platforms are rarely monolithic. A typical deployment architecture looks like this:

[Learner Browser / Mobile App]

|

[LMS Application Layer] ← Vendor’s SOC 2 scope

|

[Cloud Infrastructure (AWS/GCP/Azure)] ← Subservice org – may be carved out

|

[Video CDN (e.g., Cloudflare Stream, Vimeo)] ← Often out of scope

|

[Third-Party Content Providers (LinkedIn Learning, Coursera)] ← Almost always out of scope

|

[HRIS/ATS Integrations (Workday, SAP SuccessFactors)] ← Out of scope

SOC 2 audits use one of two approaches to handle subservice organizations:

• Inclusive method: The subservice org’s controls are included within the LMS vendor’s audit scope. The LMS vendor tests and attests to controls at the infrastructure layer.
• Carve-out method: The subservice org is explicitly excluded. The report will state something like: “The examination does not include controls at [Cloud Provider], which the user entity may elect to evaluate separately.”

The carve-out method is by far the more common approach. What this means in practice: if your LMS vendor hosts on AWS and uses the carve-out method, their SOC 2 report does not cover the physical security, logical isolation, or availability controls of the underlying infrastructure. You are expected to obtain AWS’s own SOC 2 report separately – which is accessible via the AWS Artifact portal, but the mapping to your specific LMS deployment requires additional analysis.

How to check: Section 1 of any SOC 2 Type II report (the System Description) will list subservice organizations and specify whether inclusive or carve-out methods were applied. Request this section specifically before accepting a report summary.

LMS-Specific Data Flows and Their SOC 2 Mapping

Most generic SOC 2 content ignores the specific data protocols that LMS platforms use. Each has distinct security and integrity implications that map to different TSC criteria.

xAPI (Tin Can API) 1.0.3

xAPI statements are structured JSON objects transmitted from content to an LRS (Learning Record Store), which may be internal to the LMS or a third-party endpoint. A statement’s basic structure:

{

“actor”: {

“mbox”: “mailto:learner@company.com”,

“name”: “Jane Smith”,

“objectType”: “Agent”

},

“verb”: {

“id”: “http://adlnet.gov/expapi/verbs/completed”,

“display”: { “en-US”: “completed” }

},

“object”: {

“id”: “https://lms.company.com/courses/security-101”,

“objectType”: “Activity”

},

“result”: {

“score”: { “scaled”: 0.92 },

“completion”: true,

“success”: true

},

“timestamp”: “2026-04-08T09:15:00Z”

}

The actor.mbox field contains learner email – PII under GDPR, CCPA, and similar frameworks. If your LMS vendor’s SOC 2 report does not include the Privacy TSC, there is no audited assurance over how this email address is collected, stored, or deleted. The xAPI 1.0.3 specification (ADL Initiative, 2015, still current) also defines an actor.account property as a privacy-preserving alternative – vendors who use this instead of mbox reduce PII exposure in statement logs, but this requires explicit configuration.

When an LRS is a separate subservice organization (e.g., a standalone LRS like WATERSHED or Watershed), verify whether it falls within or outside the LMS vendor’s audit scope.

SCORM 2004 4th Edition

SCORM tracking data is stored in the LMS’s SCORM RTE (Run-Time Environment) via the SetValue() API calls against a defined CMI data model. Completion status, learner score, suspend data, and session time are all written to the LMS database. The SCORM 2004 4th Edition specification (ADL, 2009) defines cmi.learner_id and cmi.learner_name as required data elements – again, direct PII.

From an audit perspective, SCORM data persistence maps to Processing Integrity: was the cmi.completion_status = “completed” value written correctly, completely, and in a timely manner? A vendor with PI in scope has been audited on this; one without has not.

LTI 1.3 (Learning Tools Interoperability)

LTI 1.3 (IMS Global, 2019) uses OAuth 2.0 with JSON Web Tokens (JWT) for launch and grade passback. The security model requires:

• Platform (LMS) and tool (external content) to exchange public keys via a JWKS endpoint
• Launch messages signed with RS256 or ES256
• Grade Services (AGS) sending signed score submissions back to the LMS

A misconfigured LTI 1.3 integration – for example, accepting launches without validating the nonce claim or iss parameter – creates an authentication bypass risk. This maps directly to the Security CC6 Common Criteria around logical access controls. An LMS vendor with a clean SOC 2 Type II covering Security has had their authentication and access controls tested, which provides some assurance here – but the scope of testing may not explicitly include third-party LTI tool authentication flows. Verify this in the test procedures section (Section 4) of the report.

How to Read an LMS Vendor’s SOC 2 Type II Report: A Buyer’s Workflow

When you receive a report (typically under NDA), the review should follow this sequence:

Step 1 – Verify the Audit Window and Report Currency

The report will state a period such as “January 1, 2025 through December 31, 2025.” Industry practice treats a report as current for approximately 12 months after the audit period ends. If the period ended more than 6 months ago, request a bridge letter – a management attestation covering the gap between the report’s end date and today. Bridge letters are self-issued and not auditor-verified, but they confirm no material control changes occurred during the uncovered period.

Step 2 – Check the TSC Scope

Confirm Security plus any additional criteria. For regulated industries (healthcare, financial services, government contractors), an LMS without Privacy in scope leaves learner PII controls unaudited by an independent party. If Privacy is absent and you process PHI or financial data, consider requiring the vendor to add it to their next audit cycle as a contractual obligation.

Step 3 – Map Subservice Organizations to Your Architecture

Cross-reference Section 1’s subservice list against your actual deployment. If your LMS instance runs on a cloud region that differs from the one tested (e.g., the audit covered us-east-1 but your data resides in eu-west-1 for GDPR compliance), the audit results may not cover your environment.

Step 4 – Audit Section 4: Tests of Controls and Results

This is where exceptions live. Each control is listed with the test procedure and result. Exception language typically reads: “For [N] of [X] items tested, [specific control] was not [operating as described].” Key questions:

• Is the exception in a control category relevant to your data type? (An exception in physical access controls for a data center you don’t use is lower risk than one in logical access or encryption key management.)
• Does the vendor’s response to the exception (the “Management’s Response” subsection) describe root cause and remediation with a timeline?
• Is the same exception repeated from the prior year’s report? Repeat exceptions signal systemic failure, not an isolated incident.

Step 5 – Request Complementary User Entity Controls (CUECs)

Section 3 of the report will list CUECs – controls that you, the buyer, must implement for the vendor’s controls to be effective. Common CUECs in LMS reports include:

• Maintaining accurate user provisioning and timely deprovisioning when employees leave
• Configuring SSO/SAML with MFA enforcement on your identity provider
• Not granting admin-level LMS roles without approval workflows
• Reviewing and responding to security incident notifications from the vendor within defined SLAs

If your organization cannot fulfill the listed CUECs, the controls the vendor tested may not actually protect your data, regardless of what the report says.

Encryption and Access Control Requirements: Technical Specifications

For LMS environments, the minimum technical baseline a SOC 2 Type II Security audit should validate includes:

Encryption:

• Data in transit: TLS 1.2 minimum, TLS 1.3 preferred. Auditors flag TLS 1.0/1.1 as non-compliant per NIST SP 800-52 Rev. 2 guidelines. Verify cipher suite support; weak ciphers like RC4 or 3DES should be explicitly disabled.
• Data at rest: AES-256 for database and object storage. For multi-tenant LMS environments, confirm whether encryption key management is per-tenant (stronger isolation) or shared-key (lower cost, higher blast radius on key compromise).
• Key management: HSM-backed (e.g., AWS KMS with CloudHSM, Azure Key Vault with HSM tier) is the current enterprise standard. Software-only key management is acceptable but warrants additional scrutiny.

Identity and Access:

• MFA requirement for administrative console access (CC6.1)
• Role-based access control (RBAC) with documented least-privilege provisioning
• Quarterly or semi-annual access reviews (CC6.2/CC6.3) – verify the review cadence in the test procedures
• Session timeout and concurrent session controls for admin accounts

Logging and Monitoring:

• Immutable audit logs covering admin actions, user data exports, and configuration changes
• Log retention period (typically 12–24 months for enterprise compliance programs)
• Anomaly detection and alerting (CC7.2)

Common Issues and Fixes: LMS SOC 2 Procurement Errors

Issue 1: Accepting a SOC 3 report as equivalent to SOC 2 Type II

SOC 3 is a public-facing summary intended for general audiences. It provides no test procedures, no exception details, and no CUEC listing. Several LMS vendors publish a SOC 3 seal on their website while keeping the actual Type II report under NDA. A SOC 3 has zero value for procurement risk assessment.

Fix: Require the full SOC 2 Type II report explicitly in your RFP. Specify in your security questionnaire: “We require the complete SOC 2 Type II report inclusive of Section 4 (tests of controls and results), not a SOC 3 summary.”

Issue 2: Not requesting the System Description for scope verification

LMS vendors sometimes summarize their compliance as “SOC 2 Type II certified across all five trust principles.” This is frequently inaccurate. The actual scope may be Security only.

Fix: Ask specifically: “Please provide the System Description section (Section 1) of your most recent SOC 2 Type II report, or confirm in writing which of the five TSC categories are in scope.”

Issue 3: Ignoring complementary user entity controls

Buyers treat the vendor’s clean report as an unconditional guarantee. CUECs place affirmative obligations on the buyer. An organization that does not enforce MFA on their identity provider, for example, may have voided the practical protection of the vendor’s access control testing.

Fix: Extract all CUECs from Section 3, assign each to an internal owner, and document compliance with them as part of your vendor onboarding process.

Issue 4: Not accounting for out-of-scope integrations

An LMS integrated with a third-party video platform, content marketplace, or external LRS creates data flows that the LMS vendor’s SOC 2 cannot cover. A learner’s completion event may traverse three separate systems – none of which the LMS vendor’s auditor reviewed.

Fix: Map every system that receives or stores learner data and obtain SOC 2 reports (or equivalent attestations) from each. For vendors that cannot provide one, assess whether the data exchange can be limited via tokenization or anonymization.

Issue 5: Relying on a report with a long-expired audit window without requesting a bridge letter

Vendor security programs can change significantly within a year. A report from 18 months ago may not reflect current infrastructure, personnel, or controls.

Fix: Require that the audit period end date be within 12 months of your contract start date. If it is between 6–12 months old, require a bridge letter. Make this a contractual renewal condition: vendors must provide a current report within 30 days of renewal.

Issue 6: Treating “SOC 2 compliant” self-attestation as equivalent to an audited report

Some smaller LMS vendors claim SOC 2 compliance based on completing a readiness assessment or using a compliance tool, without completing a formal audit with a licensed CPA firm. Self-attestation has no independent verification.

Fix: Always ask: “Who was the auditing CPA firm, and what was the audit period?” A legitimate SOC 2 Type II report will name a CPA firm (e.g., Deloitte, KPMG, or a regional firm specializing in technology audits). If a vendor cannot name one, they have not completed an audit.