Research Library ← Library index
Independent product readiness

LCMS Legal and Security Review

A GDPR-first, light-SOC-2 review of what must be true before the LCMS is sold as an independent B2B SaaS beta.

Release decision

Do not open the independent beta until ten launch gates are closed.

The LCMS has a credible application-security foundation, but it is not yet a self-contained commercial service. Its identity path still depends on SolidProfessor systems, its privacy obligations are not operationalized, and its analytics and error-monitoring configuration sends identifiable context without a documented beta policy. A small, contract-controlled beta can launch after the blockers in this report are closed. A SOC 2 report is not a beta prerequisite.

01 / Scope

What this review assumes

This is a product-readiness review, not a certification opinion. It applies to a narrow B2B beta and deliberately excludes higher-risk use until a separate assessment is complete.

In scope

  • Business administrators, editors, and reviewers.
  • EU and UK organizations may participate.
  • Customer-authored course content and media.
  • Hosted multi-tenant SaaS with named beta customers.

Excluded from beta

  • Children, students, or learner records.
  • Health, biometric, or other special-category data.
  • Payment-card storage or processing inside LCMS.
  • Anonymous public authoring or consumer accounts.
Scope rule: if the beta expands to K-12 users, learner analytics, high-scale monitoring, or special-category content, pause and perform a new legal assessment and DPIA before enabling that use.
02 / Product evidence

What the current LCMS already does well - and where independence breaks

The findings below are based on the LCMS code at commit fef65e848e19. Deployment configuration, vendor contracts, production access, and operational practice were not available in the repository and therefore remain evidence gaps.

AreaObserved evidenceBeta implication
StrengthTenant-aware routing, queries, storage prefixes, and Admin/Editor/Viewer roles.Good foundation; prove isolation with negative tests and deployment evidence.
StrengthEncrypted, expiring preview credentials; token hashes rather than raw source tokens in sessions.Keep; shorten preview lifetime and document bearer-token handling.
StrengthDirect multipart uploads use tenant prefixes, server validation, lifecycle states, and stale-upload cleanup.Keep; verify bucket encryption, private access, malware strategy, and retention.
BlockerWeb and API authentication trust SolidProfessor platform-backend/VAR entry points; no independent identity lifecycle exists.Implement standalone OIDC/SAML or define the upstream service as a contracted dependency. Otherwise the product is not independent.
Blockerresources/js/app.ts enables Sentry sendDefaultPii: true.Disable by default for beta; allow only after minimization, contract, region, notice, and documented purpose are approved.
BlockerSegment events include IP address, internal user ID, external user UUID, tenant ID, environment, and request ID.Disable non-essential analytics until consent/configuration and vendor transfer controls are ready; minimize identifiers.
GapLaunchDarkly contexts include user and tenant identifiers and names.Mark private attributes, minimize context, and include the vendor in the data map/subprocessor assessment.
GapLegacy reverse-sync and direct legacy database configuration remain in the application.Remove or isolate these paths and credentials from the independent beta boundary.
GapRetention is not defined for accounts, logs, sessions, activity history, soft-deleted content, uploads, analytics, or backups.Approve periods and implement deletion/expiry before onboarding real customer data.
Evidence boundary: code controls are not proof that TLS, encryption at rest, MFA, backups, logging, regional hosting, or incident response operate in production. Those require configuration exports, test records, and named owners.
03 / GDPR operating model

Personal data, roles, purposes, and lawful bases

The company will be both a controller and a processor. The role changes by processing purpose; it should not be described with one blanket label.

Data / purposeLikely roleProposed basisBeta control
Customer admin name, email, account identity, organization membershipController for its own account relationship; processor where customer directs account administrationContract, GDPR Art. 6(1)(b), where necessary; otherwise documented legitimate interests, Art. 6(1)(f)Notice, minimization, access controls, retention
Customer-authored content, uploaded media, captions, transcripts, filenames and metadataProcessor; customer is normally controllerCustomer instructions under an Art. 28 DPAProhibit unlawful/sensitive content; private storage; return/delete process
Audit trail, sign-in records, IP/device and security eventsController for platform securityLegitimate interests, Art. 6(1)(f), supported by a short LIALimit fields/access, set retention, explain in notice
Product analytics and feature usageControllerConsent where storage/access rules require it; otherwise a separately documented lawful basisOff by default for beta unless consent, minimization, notice, and vendors are ready
Error monitoring and support diagnosticsController and sometimes processorLegitimate interests for necessary reliability/security; customer instructions for content fragmentsRedaction, sampling, no default PII, short retention, restricted access
Vendor and customer business contactsControllerContract or legitimate interestsBusiness-only fields and documented retention

Minimum GDPR artifacts

  • Data inventory and record of processing: systems, fields, purposes, recipients, locations, transfers, retention, and safeguards (Arts. 5 and 30).
  • Privacy notice: controller identity, purposes, lawful bases, recipients, transfers, retention, rights, complaints, and contact routes (Arts. 12-14).
  • Processor DPA: subject matter, duration, data, people, instructions, confidentiality, security, subprocessors, rights assistance, breach support, deletion/return, and audit rights (Art. 28).
  • Privacy by design: default minimization, private content, restricted permissions, short retention, and review of every new vendor/data field (Art. 25).
  • Transfer assessment: document where every subprocessor stores/supports data and use an adequacy decision, SCCs, or applicable UK mechanism as required (Arts. 44-49).
DPIA / DPO / representative: under the stated admin-only beta, a DPIA and formal DPO are unlikely to be automatically required, but the threshold decision must be written down. Counsel should separately decide whether an EU or UK representative is required if the vendor has no local establishment and deliberately offers the service there.
04 / Release gate

Ten items required before the first independent beta customer

These are the go/no-go conditions. Manual, well-documented processes are acceptable for a small beta; missing processes are not.

  1. Blocker 01
    Independent identity and tenant lifecycleReplace platform/VAR bearer-cookie dependency with standalone OIDC/SAML or a clearly contracted shared identity service. Require MFA for privileged access, safe provisioning, role assignment, revocation, and offboarding.
  2. Blocker 02
    Signed beta terms and DPAEvery beta customer accepts the service terms, acceptable-use rules, privacy allocation, security responsibilities, subprocessor terms, liability framework, and beta limitations before receiving access.
  3. Blocker 03
    Privacy notice and contact routesPublish a product-specific notice and monitored privacy/security contact addresses. Do not rely on a generic company notice unless it accurately covers the LCMS.
  4. Blocker 04
    Data map, RoPA, lawful bases, and DPIA screenApprove the data inventory and purposes. Record controller/processor roles, the legitimate-interests assessment, special-data exclusions, and DPIA/DPO/representative decisions.
  5. Blocker 05
    Subprocessors and international transfersConfirm the real deployment list, locations, DPAs, transfer mechanisms, security posture, and customer notification/change process.
  6. Blocker 06
    Retention, export, deletion, and rights runbookSet enforceable periods for every data class. Demonstrate account/content export and deletion, explain backup expiry, and establish a 30-day request workflow.
  7. Blocker 07
    Telemetry privacy correctionTurn off Sentry default PII; redact secrets/content; disable non-essential Segment collection until consent and vendor controls are ready; minimize LaunchDarkly identifiers.
  8. Blocker 08
    Production security baselineProve TLS, encryption at rest, secret management, least privilege, MFA, private storage, rate limiting, dependency scanning, patch ownership, backups, and a successful restore test.
  9. Blocker 09
    Tenant-isolation and authorization release testsTest cross-tenant reads/writes/uploads/search/preview/API access and all three roles. Resolve the incomplete visibility-rule enforcement before offering affected sharing modes.
  10. Blocker 10
    Incident and breach responseName an incident lead and alternates, keep an incident log, define containment/forensics/customer notice steps, and contractually support controller notification without undue delay. Controllers need a process capable of meeting the GDPR 72-hour authority deadline where applicable.
Acceptable beta compromise: data-subject requests, export, deletion, subprocessor notices, and incident coordination may be manual for a limited named-customer beta if they are tested, owned, logged, and capable of meeting required timelines.
05 / Legal package

Documents the independent product needs

DocumentNeeded for beta?What it must cover
Beta service terms / order formYesAuthorized users, beta status, support, change/termination, confidentiality, warranties, liability, governing law, suspension, and shared responsibilities.
Data Processing AddendumYesArt. 28 terms, processing details, TOMs, subprocessors, transfers, rights assistance, breach support, return/delete, and audit information.
Privacy noticeYesLCMS-specific controller processing, account/security/analytics purposes, vendors, transfers, retention, rights, and contacts.
Acceptable Use PolicyYesNo unlawful content, malware, credential sharing, abusive testing, children/sensitive data, infringement, or cross-tenant access attempts.
Subprocessor listYesName, service, processing purpose, country/region, transfer safeguard, and change-notification method.
Cookie / storage notice and controlsIf usedStrictly necessary storage separated from non-essential analytics; prior consent where required. Simplest beta path: no non-essential client tracking.
Security overview / TOM scheduleYesAccurate description of access, encryption, tenancy, SDLC, vendors, monitoring, backups, incident handling, and customer duties.
Vulnerability disclosure pageRecommendedMonitored reporting channel, safe-harbor language approved by counsel, expected report contents, and response expectations.

Additional commercial protections

  • Customer retains ownership of its content and grants only the license necessary to host, process, back up, and deliver it.
  • Customer warrants it has the rights and notices required for uploaded materials; provide an infringement/takedown channel.
  • Do not store payment-card data in LCMS. Use a payment provider and document that boundary.
  • Complete an open-source license inventory/SBOM and remediate incompatible or missing notices before general availability.
  • Screen export-control, sanctions, sector-specific education rules, and local contracting rules as the market expands.
06 / Security baseline

Minimum technical controls for beta

Identity and access

  • MFA for staff and customer admins.
  • Least-privilege roles and separate production access.
  • Documented joiner/mover/leaver steps.
  • Quarterly staff access review; beta-customer review on request.

Data protection

  • TLS everywhere and managed certificates.
  • Encryption at rest for database, object storage, logs, and backups.
  • Private-by-default buckets and expiring URLs.
  • Secret vault; no production secrets in code, logs, or tickets.

Application security

  • Cross-tenant and RBAC negative tests in CI.
  • Dependency and secret scanning with severity deadlines.
  • Upload allowlists, decompression defenses, and malware decision.
  • Rate limits and abuse protection for auth, API, upload, and preview paths.

Resilience and response

  • Central security logs with restricted access and retention.
  • Alert ownership and on-call escalation.
  • Automated backups and documented recovery targets.
  • Restore test and incident tabletop before external beta.

Specific engineering fixes

  • Set Sentry sendDefaultPii to false and implement explicit event scrubbing.
  • Remove IP, external user UUID, and raw tenant identifiers from Segment unless approved for a necessary purpose; prefer aggregated beta metrics.
  • Mark LaunchDarkly name/tenant attributes private or use pseudonymous keys.
  • Remove legacy database credentials and reverse-sync workers from the independent deployment.
  • Reduce preview credential duration from one hour where practical and bind authorization checks to current user/tenant as well as course/version.
  • Decide whether search indexes customer content; apply tenant isolation, deletion propagation, minimization, and subprocessor controls.
07 / Privacy operations

How the beta handles rights, deletion, and incidents

Data-subject and customer requests

  1. Log the request, date, requester, customer, data scope, and legal role.
  2. Verify identity proportionately; never collect more identity evidence than necessary.
  3. If LCMS is a processor, promptly route the request to the customer/controller and act only on documented instructions unless law requires otherwise.
  4. Search accounts, memberships, content metadata, logs, support, analytics, error monitoring, feature flags, search indexes, and relevant vendors.
  5. Export, correct, restrict, object, or delete as directed; record exceptions and backup expiry.
  6. Respond within one month under GDPR unless a lawful extension applies; keep the completion evidence.

Retention schedule to approve

Use the periods below as product decisions, not automatic legal defaults: active account data for contract life; content until customer deletion/termination plus a short recovery window; authentication/session data for days; security logs for months based on investigative need; support records for a defined business/legal period; stale multipart uploads for hours or days; backups on a fixed rolling expiry; telemetry shorter than primary product data. Legal should approve the final table and engineering must prove enforcement.

Breach workflow

The incident lead records discovery time, affected tenants/data, containment, evidence preservation, risk assessment, vendors, decisions, and communications. As processor, LCMS must notify the affected controller without undue delay after becoming aware. As controller, the company must be capable of notifying the supervisory authority within 72 hours where the breach is likely to risk people, and affected people where the risk is high.

08 / Light SOC 2

Build evidence habits now; do not buy an audit for beta

SOC 2 is independent assurance over controls, not a product license and not a substitute for GDPR compliance. Do not say “SOC 2 compliant” or “certified.” A CPA firm issues the examination report.

Control familyLight beta practiceEvidence to retain
CC1-CC2 Governance and communicationName the security owner, approve short policies, define responsibilities, provide annual security/privacy training.Policies, approvals, org responsibilities, training completion.
CC3 Risk assessmentMaintain a product risk register and revisit it at each release or material vendor/architecture change.Risk entries, owners, due dates, treatment decisions, review minutes.
CC6 Access controlsMFA, least privilege, access approval, timely offboarding, quarterly review.Identity settings, approvals, termination tickets, review exports.
CC7 System operationsMonitor alerts and vulnerabilities, own patch deadlines, run incident tabletop.Scan results, remediations, alerts, incident/tabletop records.
CC8 Change managementPeer-reviewed pull requests, automated tests, controlled deployments, rollback notes.PR reviews, CI results, deployment logs, emergency-change records.
CC9 Vendor riskInventory and tier vendors; review security, privacy, contracts, regions, and exit options.Vendor register, reviews, DPAs, SOC reports, renewal decisions.
Later assurance path: consider a Type 1 report when the control design and system description are stable. Pursue Type 2 only after controls have operated long enough to produce consistent evidence, commonly at least several months. Security is the required Trust Services Category; add availability, confidentiality, processing integrity, or privacy only when customer commitments justify the scope.
09 / Delivery plan

30/60/90-day path from conditional no-go to controlled beta

WindowOutcomeWork
Days 0-30Define and shrink the beta boundaryName legal/security/product owners; finalize data map and role analysis; choose independent identity; disable PII telemetry; inventory vendors; draft terms, DPA, privacy notice, AUP, TOMs, retention, rights, and incident runbooks; create risk register.
Days 31-60Implement and prove launch controlsDeliver identity/tenant lifecycle; remove legacy dependency; configure encryption/MFA/secrets/backups; implement deletion/export; add tenant/RBAC negative tests; complete vendor DPAs/transfers; run vulnerability scan and restore test; close critical/high issues.
Days 61-90Run a named-customer beta with evidenceSign customer documents; complete readiness review; run incident tabletop and request rehearsal; monitor support/security metrics; review access and vendors; collect change/CI/deployment evidence; reassess DPIA and beta exclusions before expanding.

Go decision

The accountable product and security owners should sign a one-page release record that lists each gate, evidence link, residual risk, accepting owner, and customer restrictions. Any open blocker keeps the decision at no-go. Medium residual risks may be accepted only in writing with a deadline and a beta-specific containment.

10 / Evidence

What the launch reviewer should be able to open

EvidenceOwnerPass condition
Data inventory, RoPA, lawful-basis/LIA, DPIA screenPrivacy / ProductApproved, dated, matches production fields/vendors.
Terms, DPA, privacy notice, AUP, TOMs, subprocessorsLegal / PrivacyApproved versions and signed customer acceptance.
Identity, MFA, access and tenant-isolation evidenceEngineering / SecurityConfiguration plus passing negative tests and access review.
Telemetry field list and redaction proofEngineering / PrivacyNo default PII; only approved fields reach approved vendors.
Encryption, secrets, backups and restore resultPlatformProduction configuration and successful dated restore test.
Vulnerability and dependency resultsSecurity / EngineeringNo open critical/high issues; lower findings owned and dated.
DSAR/delete/export rehearsalSupport / PrivacyCompleted within target time across primary systems/vendors.
Incident tabletop and breach decision logSecurity / LegalParticipants, scenario, gaps, owners, and closure dates recorded.
Beta release sign-offProduct / Security / LegalAll gates closed or explicitly contained and accepted.
11 / Sources

Primary legal and assurance references

Repository evidence reviewed

resources/js/app.ts, app/Services/Segment/SegmentTracker.php, app/Services/LaunchDarkly/LaunchDarklyContext.php, app/Auth/EntryPointAuthenticator.php, app/Http/Middleware/SyncPlatformSession.php, app/Services/Preview/PreviewToken.php, multipart-upload services and tests, tenancy/permission configuration, routes, CI configuration, database migrations, and dependency manifests.

Important: This report is product and engineering guidance, not legal advice, a penetration test, or an audit opinion. Applicability depends on the company entity, customer locations, contracting model, deployment, actual data, and operational practice. Qualified privacy and commercial counsel should approve the legal documents and jurisdiction decisions before launch; a security professional should validate the production controls.