Open source LMS for financial services: why regulated training is a records problem
A bank or insurer that must prove who was trained on which policy, and when, is running a records problem before it is running a course catalog. For most regulated training programs, Moodle is the most practical self-hosted fit, because it runs on infrastructure you control, ships core authentication plugins for LDAP, SAML-based single sign-on through a plugin, and has a mature completion and reporting model. Open edX and Canvas are conditional alternatives: Open edX fits when the content model or large external learner population drives the decision, and Canvas fits when an institution already runs it and its license terms and hosting model have been reviewed. Choose the platform after you have tested how it produces evidence, not before.
Completion records, recertification and retention matter more than the catalog because examiners and auditors ask narrow questions: which employee completed which module, against which policy version, on which date, and who assigned it. Course content is easy to replace; a record that cannot show the policy version, the assignment rule and the completion timestamp is not usable evidence. Recertification adds a second clock, since annual cycles must trigger reassignment automatically and leave a history of earlier passes. Confirm with your compliance function how long training evidence must be kept and whether it must survive employee exit, then test that a completed course, a re-issued version and a departed employee each still produce a complete record.
Before you commit to a platform, run a short proof with your own data. Map each regulated course to a role and to the policy it supports, assign it through a rule rather than by hand, and export a completion report that a second person can read without help from the implementer. Check that the Moodle version you select is still in its support window for the life of the program, using the Moodle release schedule, and confirm which HR identity attributes will drive enrollment through SSO. These checks show whether the platform can carry your evidence obligations, which is the decision that matters most in financial services.
Which financial rules shape the LMS build
This table maps the main financial-sector rules to what each one means for a self-hosted LMS: where it runs, who can change it, how changes are controlled, how an exit would work, and which training records must be kept. Read it by first confirming which rules bind your entity type and jurisdiction, then checking the LMS column against your own controls.
| Rule or framework | What it asks of the LMS | Evidence to keep |
|---|---|---|
| DORA (EU) register and ICT contracts | Name the LMS hosting and support providers in the register of ICT contractual arrangements; confirm where training data is stored and processed. | Register entries, provider contract clauses on location, and notice of sub-processor changes. |
| DORA exit and data return | Document and test an exit plan for the LMS if it supports a critical or important function, including export of completion records. | Tested exit plan, export samples of training records, and transition runbook. |
| FTC Safeguards Rule (US non-bank institutions) | Require multi-factor authentication for every individual accessing the LMS, including administrators and support staff, unless the Qualified Individual approves an equivalent control in writing. | MFA configuration for staff and admin accounts, and any written equivalent-control approval. |
| SEC ICFR guidance (SOX 404) | Where training supports financial reporting controls, apply IT general control discipline: access to course and record data, program changes and computer operations. | Access review logs, change tickets for plugins and themes, and backup and restore records. |
| Swift CSCF attestation | Where the LMS is in scope of the Swift environment, confirm it does not weaken controls on connected systems; annual independent assessment is the bank's obligation. | Scope statement showing whether the LMS is in or out, and control mapping agreed with the assessor. |
| PCI DSS v4.0.1 security awareness | If the LMS trains staff in a cardholder data environment, run the security awareness program, policy acknowledgment and yearly review through the LMS. | Completion reports by role, policy acknowledgment records, and the annual program review. |
| Entity type and jurisdiction | These rules do not apply equally. Confirm with counsel or your regulator which bind a bank, insurer, payment firm or service provider in each market. | A written applicability assessment that the compliance team signs off. |
What training data a financial institution must keep and where it flows
Every training record starts with who the learner is and what job they hold at the time the course was assigned. For a bank or insurer, the authoritative source is usually the HR system, which holds employment status, job family, legal entity, branch or business unit and manager. The identity provider supplies the login identity and group memberships, and the LMS should receive role attributes from these systems rather than maintain its own copy that drifts over time. Role at assignment time matters because a completion record is only meaningful if it can be tied to the duties the person held when the training was required.
- Authoritative source: HR holds the employment record, and the identity provider holds the login and group membership. Confirm which system wins when they disagree.
- Role snapshots: Store the role and legal entity in effect on each assignment date so historical records do not change when a person moves teams.
- Access: Learners see their own records, line managers see their direct reports, and compliance staff see the population they oversee. Restrict bulk exports to a named group.
- Retention: Keep identity attributes for as long as the related training records must be retained, then remove or pseudonymize them under the institution's schedule.
- Personal data: Under GDPR, where it applies, this data is personal data and should be classified and documented as such in the record of processing.
Confirm with HR and the identity team which attributes are authoritative, how often they sync, and how leavers are handled.
A completion only proves something if the institution can show which version of the policy or course the learner completed. Policies are typically owned in a policy management system or document repository, and courses are built and versioned in the LMS. Linking the two means each course carries a reference to the policy version it covers, and each version has an effective date, an owner and an approval record. Without this link, a regulator asking whether staff were trained on the current conduct policy in a given month cannot be answered from the records alone.
- Source systems: The policy management system or controlled document repository owns the approved text. The LMS holds the course build and its reference to the policy identifier and version.
- Version pinning: Record the course version and the policy version attached to each assignment, so a later edit does not rewrite history.
- Access: Policy owners and compliance staff can view and edit course mappings. Learners can view the current course. Change rights should be limited and logged.
- Retention: Keep superseded course and policy versions for the period the training records must be produced, not only the current version.
Ask how course versions are archived when content is updated, and whether the policy system can publish an identifier the LMS can reference.
Completion records show who finished which course, when, and with what result. In an LMS these come from course activity logs, quiz or assessment attempts, and grade items. A defensible record includes the learner, course and version, start and finish timestamps, the score and pass threshold, the number of attempts, and any waiver or exemption with its approver. Recertification adds a due date and a status for each cycle, so the institution can show what was overdue and when it was closed.
- Source system: The LMS generates the record, and it should be exported on a schedule to a compliance store that the LMS administrators cannot alter.
- Required fields: Learner, course version, timestamps, score, attempts, due date and cycle identifier should appear together in one export.
- Access: Compliance and internal audit can read the full population. Managers see their team. Learners see their own history.
- Retention: Keep completion and assessment records for the period set by the institution's record retention schedule and the regulations that apply to its business lines.
- Exemptions: Store waivers as records with a reason, an approver and a date, not as informal notes.
Confirm which retention period applies to each record type with the compliance function and legal team, and test that a full historical export can be produced from the LMS.
Many conduct and policy programs require the learner to acknowledge a policy, not only complete a course. An attestation event records that the person read or accepted a specific policy version at a specific time, usually with a click-through or electronic signature. This evidence is often the most scrutinized item in a file, because it links a person to a document version. The event should capture the exact policy version shown, the time and the method of acceptance, and it should not be editable after the fact.
- Source system: The LMS or a connected policy portal captures the acknowledgment, and the event should be written to the same compliance store as completions.
- Evidence content: Include the policy identifier, version, timestamp, learner identifier and acceptance method.
- Access: Compliance and legal may read these events. Learners may view their own acknowledgments. No routine user should be able to edit them.
- Retention: Keep acknowledgments for at least as long as the policy it covers is in force and for the regulatory retention period that follows.
- Electronic signatures: Confirm with legal whether the acceptance method meets the institution's own standard for electronic records and signatures.
Ask the vendor or partner exactly what is stored at the moment of acceptance and whether the stored text can be reproduced later.
Audit logs record who changed training data and what they did, including course edits, role changes, grade overrides, deleted enrollments and administrator logins. They support internal audit and the IT general control work that examiners and external auditors perform on systems that feed financial reporting. The SEC's guidance on management's report on internal control names program changes and access to programs and data as relevant control areas, so logs of administrative actions on the LMS are part of that evidence when training records support controls.
- Source systems: The LMS application log, the database audit facility, the identity provider sign-in log and the export job log together show the full picture.
- Scope: Capture administrator actions, grade and completion changes, enrollment changes, and privileged access.
- Access: Restrict audit logs to internal audit, the security team and designated compliance staff. Administrators should not be able to delete them.
- Retention: Keep logs for the period the institution sets for IT audit evidence, and protect them against tampering by forwarding them to a separate store.
- Integrity: Time sources should be synchronized so log events can be ordered reliably.
Confirm with the security and audit teams which log events the LMS produces natively, which need a plugin or database configuration, and how long logs are retained before they roll off.
Which open source LMS fits a regulated bank or insurer
Moodle, Open edX and Canvas LMS can each deliver regulatory and conduct training, but they differ in release cadence, identity options and upgrade effort. The cards below set out where each fits a bank or insurer and what your team must confirm before choosing.
Moodle as the default choice
Moodle is licensed under GPL-3.0 and maintained by Moodle HQ, and it can be self-hosted or run through MoodleCloud or Moodle Partners. Moodle 5.3 is the next long-term support release, with security fixes until 1 October 2029. Its core ships LDAP, LTI, OAuth 2 and Shibboleth authentication, and SAML2 single sign-on is available as a plugin. Confirm that your plugin audit covers SAML2 and that your PHP and database versions meet the 5.3 requirements.
Moodle 5.3 platform prerequisites
Moodle 5.3 requires 64-bit PHP 8.3 or later (8.4 supported), PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Sites must already run Moodle 4.4 or later to upgrade. Your infrastructure team should confirm that the database version your bank already supports is on this list, because older database standards may force a separate upgrade project before the LMS can move.
Open edX with the latest release only
Open edX is licensed under AGPL-3.0, and only the latest named release receives support. Verawood is the current release, with Willow planned for December 2026 and Xylon for June 2027. This cadence suits teams that can plan a regular upgrade cycle, but it means every upgrade is a required project rather than an optional one. Confirm the upgrade budget, test effort and who owns the custom code before selecting it for long-term regulatory training.
Canvas LMS under AGPL-3.0
Canvas LMS by Instructure is licensed under AGPL-3.0, so self-hosting is possible under open-source terms. Its strength is a mature course and assessment model, but financial institutions should confirm which features they need that are included in the open-source code and which depend on Instructure services. Ask how security patches reach a self-hosted instance, how role-based assignment maps to HR data, and what evidence export exists for auditors.
Which platform fits best
For most banks and insurers, Moodle is the strongest fit because its LTS model, broad authentication options and large plugin ecosystem match the long audit cycles and identity controls these firms run. Open edX suits organizations that plan frequent upgrades and have engineering depth. Canvas suits teams that already work in its course model. Choose based on your upgrade capacity, identity architecture and the completion reporting your auditors expect.
What to confirm before selecting
Confirm the SSO path to your HR system, whether completion records can be exported in a form your compliance team accepts, how long records are retained, and where the data is hosted. Ask each vendor or partner for a written statement on support windows, plugin compatibility with your chosen release and the upgrade path from your current version. Treat these answers as selection criteria, not as assumptions.
Integration points and deployment pattern for a regulated LMS
A regulated LMS is only as credible as the systems around it. The cards below cover the identity, HR, content, logging and recovery connections that turn a course platform into a training record a bank or insurer can defend, and the hosting pattern that keeps those records inside the institution's own control.
SSO with HR and identity provider
Moodle core ships LDAP, OAuth 2, LTI and Shibboleth authentication, and the SAML2 plugin is a common route to a corporate identity provider. Confirm which protocol your identity provider supports, how just-in-time accounts are created, and how a leaver is disabled in the LMS on the same day as in the directory. A delayed deprovisioning step is a finding in its own right, so test it with a real offboarding case before go-live.
Automated enrollment from HR role changes
Assignments tied to job role, branch, or licensed activity should follow HR data rather than manual lists. Define the HR fields that drive enrollment, the schedule for syncing them, and who approves exceptions. Ask the implementation partner how a role change removes obsolete required courses, since retained assignments are a common source of inaccurate completion reports.
Policy and course version linking
Each required course should reference a specific policy version and a content version, so a completion can be shown against the text the employee actually acknowledged. When a policy changes, the record should show which learners must retake the course and which are current. Confirm whether your LMS can store version identifiers on courses and completions, or whether this needs a custom plugin and a documented procedure.
Certificate and completion export
Examiners and internal audit usually ask for completion evidence in a form they can sample independently. Agree on export fields such as learner identifier, course and version, completion timestamp, score and assessor, and on the file format and export schedule. Test the export against a sample request from your audit team before relying on it, and confirm whether certificates are generated with a verifiable identifier.
Log forwarding to monitoring
Authentication events, administrative changes, course edits, grade overrides and export downloads should reach the institution's monitoring platform, not sit only in the LMS database. Decide which events are forwarded, the transport and retention in the central store, and who reviews alerts. Confirm that log entries cannot be edited by LMS administrators without leaving a trace.
Backup, restore and deployment in your account
Backups need to be restored, not just taken, on a schedule that matches your records retention rule. Agree on restore tests that include the database, the moodledata directory and plugin code, and record the results. From Moodle 5.1, the web server document root must point to the new /public directory rather than the main Moodle folder, or the site may show directory listings or errors. Set this in the reverse proxy and hardening baseline from the start, and deploy into your own cloud account or data center so records stay under your control.
How a financial services LMS rollout moves from scope to examiner-ready records
The sequence turns a set of regulatory training obligations into a self-hosted Moodle environment where completion, versioned content and retained evidence can be produced on request. Each phase closes with a written output that the bank or insurer can review before the next phase starts.
Map obligations to written requirements
Compliance, HR, information security and the business owners agree which training obligations apply, such as conduct, anti-money laundering, information security or data protection programs, and which roles, policies and recertification cycles each one covers. DeployOpen turns this into a written requirements register that links each course family to a role, a policy version and an evidence need. The step is done when compliance signs the register and the list of open questions is assigned to named owners.
Decide hosting and write data location into the contract
The team chooses where the Moodle environment runs, whether in the institution's own cloud account, a data center it controls or a provider it has assessed, and records the decision with the regions where learner data is stored and processed. Where ICT services support critical or important functions, the contract should also cover data return and exit, which the DORA contract and register requirements address. The output is a signed hosting decision, a data location statement and a contract clause list reviewed by legal and the third-party risk team.
Build identity and HR integration
Engineers connect the LMS to the corporate identity provider using SAML 2.0 single sign-on, and to the HR system so that hires, transfers and terminations drive enrollment and removal from role-based courses. Moodle core includes several authentication methods, and the team confirms which one meets the bank's identity policy before building on it. Testing covers joiners, movers and leavers with sample accounts. The step closes when HR-driven enrollment changes produce matching records in a test environment and the identity team has signed off on access.
Migrate course and policy versions with reconciliation
Existing course content, policy acknowledgments and completion history are moved from the current system or spreadsheets into Moodle, with each course tied to the policy version it teaches. Record reconciliation compares source and target counts, completion dates and version identifiers for a sample and for all records in scope, and exceptions are logged with a decision from the business owner. Historical records that cannot be reproduced are retained in their original form and referenced. The output is a reconciliation report that compliance accepts as the basis for the new system of record.
Harden the platform and review access
Security engineers apply the hardening baseline to the web server, database, Moodle configuration and plugins, and confirm that every plugin in use is maintained and tested against the chosen Moodle release. Administrative and reporting access is granted by role, and an access review is run against the approved list before go-live. Logging for administrative actions and report exports is verified. The step is complete when the security team signs a hardening record, the access review has zero unapproved administrators, and the plugin inventory is documented.
Run a controlled pilot with one business unit
A single business unit runs live courses, assessments and recertification reminders for a defined period, while compliance checks that completion records appear in the reports examiners would ask for. Feedback from learners, managers and administrators is logged and fixes are tested before they reach production. Any mismatch between HR data and LMS enrollment is traced to its source. The pilot closes with a written pilot report listing defects, residual risks and a go or no-go recommendation from the business owner and compliance.
Roll out with recertification schedules
The remaining business units are onboarded in waves, each with its role mapping, policy versions and recertification calendar. Reminder schedules, escalation paths for overdue learners and manager reports are switched on and tested against the calendar. Completion reporting is checked against the reconciliation baseline at each wave. The step is done when every in-scope population is enrolled, the recertification calendar is live and the first full reporting cycle has been reviewed by compliance.
Hand over runbooks and retention procedures
DeployOpen documents the operating procedures, including backup and restore tests, Moodle upgrade planning against the long-term support calendar, incident handling and the retention schedule for training evidence. The bank or insurer's internal team, or a retained support provider, takes ownership of each runbook, and the retention schedule is checked against the institution's record policies. The handover closes when the team has run a restore test from backup, an upgrade rehearsal is documented and the owners have accepted each runbook in writing.
What examiners and auditors will ask to see from the LMS
Who completed which course and when?
The LMS completion log answers this, but only if each completion is stored as a discrete, timestamped record tied to a named user account and course version. Moodle's course completion and activity completion reports can produce this per learner, and the export should carry the user ID, course ID, completion timestamp and the pass score. Ask your implementation partner to show an examiner-style export from a test course before go-live, and confirm with the auditor which fields they expect to see in the file.
Which policy version did the learner complete against?
The LMS shows that a course was completed, but it does not prove which policy text the learner read unless the course version is linked to the policy version. Keep a register that maps each course build to the policy document, its version number and its approval date, and store that mapping alongside the completion records. When a policy changes, a new course version should be published so that older completions remain tied to the text in force at the time. Confirm with compliance whether acknowledgment of the policy must be captured as a separate step.
Was annual recertification overdue for any employee?
A recertification report should list each learner, the last completion date, the due date for the next cycle and the days overdue, filtered by role and business unit. Moodle can drive this with activity completion conditions, availability rules and scheduled reports, but the due-date logic and the escalation steps are configuration choices your team must define and test. Confirm the recertification cycle with your compliance function and have the report run on a fixed schedule with a saved copy each time.
Who holds administrator rights in the LMS, and when did those rights change?
Assessors will look for a current list of users with site administrator and course creator roles, the approver for each grant, and a history of role changes. Moodle records role assignments and configuration changes in its logs, but the approval step sits in your access request process, not in the platform itself. Connect admin role grants to your identity governance workflow, export the role assignment list at each review, and retain those exports. Confirm with your security team how privileged access reviews are scheduled and evidenced.
Are the audit logs complete, and can anyone change them?
Auditors will want to know whether the log captures the events that matter (logins, completions, grade changes, role changes and course edits) and whether administrators can delete or alter entries. Moodle keeps logs in its database, and the default retention and purge settings can remove entries before your retention period ends. Confirm the log retention configuration, restrict database access to a small group, and forward logs to a separate store that your platform administrators cannot edit. Test that a deliberate change is visible in the trail.
How long are training records kept, and how are they retrieved?
Retention periods come from your regulatory obligations and internal record schedules, not from the LMS. Define the period for each record type, then configure the platform, backups and archive to match it, and document who can request a retrieval. Records must remain readable after upgrades, so test restores from backup at a fixed interval. Ask your legal and compliance teams to confirm the retention rules that apply to your jurisdiction and product lines before the platform stores any live data.
Can an auditor be shown evidence without a full system login?
Yes, provided that exports are generated on a controlled schedule and handed over as signed or hash-checked files, with a record of who produced them. Direct access for an external assessor should be time-limited, read-only and logged, and it should not expose other learners' personal data. Agree the evidence format and the access method with the assessor early in the cycle, because they decide what is adequate. DeployOpen prepares the controls and the evidence set, while independent auditors and assessors determine whether it meets their requirements.
Which parts of this evidence can an implementation partner set up, and which stay with us?
A partner can configure completion rules, reports, role structures, log forwarding, backup jobs and export procedures, and can document how each is produced. Your organization keeps ownership of the policy register, the recertification cycle, the retention schedule, the approval of privileged access and the decision on what counts as adequate evidence. Written scope should name each item, the owner and the test that proves it works. Ask the partner to show which artifacts they will hand over at the end of the engagement.
What drives the cost and effort of a self-hosted financial LMS
The license fee is zero for Moodle, Canvas and Open edX, so the budget for a self-hosted financial LMS sits in the work and infrastructure around the platform. Ask a partner to price each of these as its own line: hosting sized for peak load (year-end attestation drives, new-hire waves and regulatory deadlines are the usual spikes), identity and HR integration, migration of existing training records, validation of the evidence process, upgrades, and ongoing support. Moodle core already ships LDAP, LTI, OAuth 2 and Shibboleth authentication, and a SAML2 plugin is available on the Moodle marketplace, so confirm which of these your identity provider and HR system need before the quote. Integration cost rises with each system that must be matched to learner identity, role and manager.
Costs fall into two groups. One-time costs include discovery, architecture, identity and HR connectors, content and record migration, theme and plugin setup, and the first evidence design. Recurring costs include hosting, backups, monitoring, security patching, plugin maintenance, upgrade projects and support retainers. Upgrade effort is the recurring cost most often underestimated. Moodle 5.3 is the current long-term support release with security support until 1 October 2029 (per Moodle's releases page), and its requirements include PHP 8.3 or later and PostgreSQL 17, while sites must run Moodle 4.4 or later to upgrade. Plan the upgrade path against that window, and ask the partner whether the quote covers the database and PHP moves, not only the core upgrade.
Before accepting a quote, request a written scope that states the systems in scope, the number of learners and peak concurrency used for sizing, the course and record volumes to migrate, the evidence and validation work included, the support hours and response commitments, and the upgrade policy. Ask who owns each item: DeployOpen, your internal team or your hosting provider. Confirm in writing what happens to records and backups at contract end. Under DORA, the contract for an ICT service must state where data is processed and cover data return on termination, so the exit terms belong in the same quote as the build and support fees.
How long, how much effort and what the bank or insurer must supply
Can our in-house team run an open source LMS for compliance training?
Many regulated firms have the engineering skills to run Moodle, but the question is capacity and continuity. Running the platform means patching for each release line, keeping PHP and database versions current, managing backups, monitoring, and handling identity and HR connectors. Moodle 5.3 requires 64-bit PHP 8.3 or later and PostgreSQL 17, and sites must run Moodle 4.4 or later to upgrade, so the team needs people who can plan those moves. Ask your team to map who owns each task on a named rota, including out-of-hours incidents, before deciding between in-house, partner-supported or hybrid operation.
What does compliance and HR need to contribute to an LMS project?
Compliance and HR own the content and the rules, while the platform team owns the build. Compliance should approve the required course list, the role-to-course mapping, the recertification cycle and the wording of policy acknowledgments. HR should supply the authoritative employee and role data, joiner and leaver events, and a named owner for the HR system connection. Agree these inputs in writing at the start, because late changes to role mappings or policy versions are a common reason effort grows during testing.
What makes effort go up or down on an LMS build for a bank or insurer?
The main drivers are the number of identity and HR integrations, the volume of existing content to migrate, and the evidence the regulator or auditor expects. Effort rises with SAML or LDAP connections to several directories, SCORM or xAPI packages that need testing, custom completion reports, and multi-entity or multi-jurisdiction role structures. It falls when role models are simple, existing content is already standards-compliant, and the evidence requirements are documented before build starts. Ask for a written breakdown of each driver so you can see which choices move the estimate.
Is a fixed-scope engagement typical for an LMS implementation?
Yes, most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For an LMS, a typical written scope lists the Moodle version and hosting model, the authentication and HR connections, the course and content migration, the completion report definitions, the test and acceptance steps and the handover documents. Changes after sign-off, such as adding a new regulatory course family or a further identity source, should go through a written change request. Ask any partner to show how scope changes are priced and approved.
How do upgrades and retainers work after go-live?
Ongoing support, upgrades and continuous testing are available as retainers, so upgrades can be planned rather than handled as emergencies. Moodle publishes major releases every six months and minor releases every two months, and Moodle 4.5 is LTS with security support until 4 October 2027, while Moodle 5.3 has security support until 1 October 2029. Upgrades can require new PHP and database versions and plugin compatibility checks, so the retainer should cover test environments, regression testing of completion reports and a rollback plan. Confirm with any partner exactly which upgrades, testing and response times the retainer includes.
Does an open source LMS satisfy PCI DSS or DORA training requirements?
The platform does not satisfy any regulation by itself, and DeployOpen does not issue audit reports, attestations or certifications. An LMS can support evidence for requirements such as PCI DSS security awareness, where the standard expects training and policy acknowledgment to be recorded, and it can help with DORA's ICT risk management training expectations. Whether the evidence is sufficient is for your assessor, Qualified Security Assessor or regulator to decide. Ask your compliance team to map each requirement to the records the LMS will hold before the build starts.
What should a bank or insurer ask a partner to put in writing?
Ask for a written scope that names the platform version, hosting location, integrations, data flows and acceptance criteria. The contract should state where learner data is processed and stored, the handover of configuration and documentation, and the exit or data return terms. For DORA-regulated entities, the register of ICT contractual arrangements and the exit strategy requirements expect those terms to be clear. A partner that cannot state these items in writing before work begins is a risk to your timeline and your evidence trail.
How DeployOpen scopes, builds and supports a regulated LMS
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source learning platforms inside your own cloud accounts, data centers or networks. For financial services, we start from the training obligations, records and identity links your compliance and HR teams must evidence, then build and hand over a platform that produces them.
How we scope
- Map which regulatory and conduct courses must be completed, by role, policy and jurisdiction, before any platform choice is made
- Agree in writing which completion records, recertification cycles and retention periods the LMS must hold
- Define the HR system integration, SSO path and data location that the written scope will cover and exclude
How we build
- Configure Moodle, Canvas or Open edX with role-linked course assignments and policy acknowledgment tracking
- Implement SSO with your identity provider and the HR feed, then test provisioning and deprovisioning end to end
- Harden the hosting, backups and audit logging, and run security testing against the platform and its plugins
How we hand over
- Document configuration, integrations, backup and restore steps, and the evidence each report produces
- Deliver runbooks for administrators covering recertification campaigns, report exports and retention settings
- Provide a written handover of the upgrade plan, so your team knows how each release will be assessed and applied
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, sized to the written scope
- Plan major and security upgrades around the vendor's published support windows and your change calendar
- Prepare systems, controls and evidence for your independent auditors, who issue any audit reports or attestations
