Moving Cornerstone training into an agency-authorized Moodle environment
An agency that relies on Cornerstone's FedRAMP Moderate authorization for compliance training needs to know whether that authorization can be kept when training moves inside its own environment. Moodle can run in the agency's own authorized environment, but the agency then owns the controls the cloud provider held, so the move is a planning and evidence exercise, not a feature swap. Cornerstone describes its learning platform as holding ISO/IEC 27001, SOC 2 Type II and FedRAMP Moderate authorization (Cornerstone's learning platform page), and none of those attestations transfer automatically to a self-hosted system. Under FISMA, the agency's own system security assessment and authorization process is what must cover the new platform, and FedRAMP's scope rules apply only to cloud offerings that handle federal information on behalf of an agency, so confirm with your authorizing official which path applies to a Moodle instance you operate.
Start by mapping each control family that Cornerstone's cloud environment covered today to a named owner in the agency: hosting and physical security, operating system and database patching, backup and encryption, identity integration, logging and vulnerability scanning. Moodle is GPL-3.0 software maintained by Moodle HQ, and its core ships authentication plugins for LDAP, Shibboleth, LTI and OAuth 2, so federated sign-in can be designed in the agency's identity stack (Moodle GitHub repository). Confirm the current Moodle release, its support window and the required PHP and database versions before selecting a build, because a specific version must be checked against the supported platforms for your environment. Where training content contains criminal justice or controlled unclassified information, the content and records may also fall under CJIS or NIST SP 800-171 requirements, which the agency must confirm before any data is loaded.
For the short answer on options, Moodle is the primary fit for an agency that needs to run a learning platform inside its own authorized boundary, because it is open source, self-hostable and widely deployed for compliance-style training. Canvas LMS, whose code is AGPLv3 and which offers self-hosted installs through its repository guides, and Open edX, which is AGPL-licensed and stewarded by Axim Collaborative, are narrower alternatives: they fit specific course or academy needs better than workforce compliance tracking. In every case, no authorization transfers automatically to a self-hosted platform. Ask the authorizing official what evidence they will accept, and treat the migration as a documented authorization decision, with control inheritance, records retention and the audit trail defined before any learner data moves.
Which federal requirements shape a self-hosted training system
Six federal requirements determine what an agency must control once training runs in its own authorized environment on Moodle. Each one lands on a different owner, so the training team should agree on who holds each control and record before the platform goes live.
NIST SP 800-53 Rev. 5 moderate baseline
The moderate baseline in SP 800-53B selects 287 controls and enhancements, and it is the catalog your authorizing official will test the Moodle deployment against. Moodle itself inherits few of these controls, so the agency must map access control, audit logging, configuration management and backup to its own hosting and operations. Ask the security team to build a control matrix that names the owner of each row before the system is assessed.
FISMA and Inspector General review
FISMA makes agency leadership responsible for system security, and Inspectors General independently assess that security and report to OMB. A self-hosted training system becomes one more agency information system that an IG can sample, so the records of patching, access reviews and incident handling must be complete. The agency's information security office owns the authorization package and the evidence that supports it.
FedRAMP scope under M-24-15
FedRAMP covers cloud products that handle federal information on behalf of an agency, but a system used only for one agency's operations on cloud infrastructure and not offered as a shared service is outside that scope. Deciding which side your deployment falls on determines whether you can reuse Cornerstone's FedRAMP Moderate authorization or must rely on the agency's own authorization. Confirm the classification with the agency's FedRAMP or cloud authorization lead.
CJIS Security Policy v6.1
If training records or course content touch criminal justice information, CJIS Security Policy v6.1 sets the rules for encryption, vulnerability scanning and personnel access. It requires FIPS 140-3 certified modules or AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations. Confirm with the CJIS Systems Officer whether any training data falls under CJI before you scope the Moodle deployment.
32 CFR 2002.14(h)(2) for CUI
Agencies that share controlled unclassified information with non-federal systems must set protection requirements based on NIST SP 800-171, unless the CUI category prescribes other safeguards. Training that includes CUI, such as security procedures or contract content, may therefore run on Moodle only if the hosting and access controls meet those requirements. The agency's CUI program office sets the requirement, and the platform team implements it.
ADA Title II WCAG 2.1 AA
State and local government web content and mobile apps, including those provided through contracts or licenses, must meet WCAG 2.1 Level A and AA. Entities serving 50,000 or more people must comply from 26 April 2027, and smaller entities and special districts from 26 April 2028. Course content authored in Moodle and any custom theme or plugin fall under this rule, so the accessibility office should test them before launch.
Where Cornerstone's FedRAMP Moderate authorization stops and the agency's starts
Cornerstone describes its learning platform as a cloud application holding FedRAMP Moderate authorization, and that authorization covers Cornerstone's service, not the agency's decision to move training elsewhere. FedRAMP's scope is cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. Under the scope set by OMB memo M-24-15, a system used only for one agency's own operations on cloud infrastructure, and not offered as a shared service, is out of scope. A self-hosted Moodle instance running in the agency's own authorized environment may fall into that exception, or it may not, depending on how it is deployed and who else uses it. Confirm this with the authorizing official and FedRAMP program staff before cutover, and record their answer in the decision file.
Whichever path applies, the authorization package no longer travels with the training system. The agency writes and owns the system security plan for the Moodle deployment, mapping each control in its chosen NIST SP 800-53 Rev. 5 baseline to a named implementation, owner and evidence source. The agency also runs continuous monitoring: vulnerability scanning, patch cadence for Moodle point releases, configuration baselines, log review and access recertification. Plan for the Moodle 5.1 change where the web server document root must point to the public directory, since a misconfigured root is a finding an assessor will read. Under FISMA, the agency's Inspector General independently assesses the system's security and reports to OMB, so the evidence must hold up to an outside reader who did not build it.
Ask the Cornerstone account team for the current authorization documentation and the control responsibilities it assigns to the customer, then compare that list line by line with what the agency will own. Gaps usually sit in identity federation, audit log retention, backup restoration tests and incident reporting timelines, which Cornerstone previously handled inside its boundary. Document each gap with a named owner and a date. If training records feed other regulated data, such as Controlled Unclassified Information or Criminal Justice Information, confirm which additional requirements apply before the migration plan is approved, because those regimes set their own encryption and scanning rules.
Which open-source LMS fits an agency-run authorization boundary
This table compares Moodle, Canvas LMS and Open edX on the factors an agency weighs when training must run inside its own authorized boundary. Read it as a starting shortlist: none of the three is FedRAMP authorized by this page, so each option needs confirmation against your own assessor's requirements before you commit.
| Factor | Moodle | Canvas LMS | Open edX |
|---|---|---|---|
| License | GNU GPL version 3 | AGPLv3 (source code released under the license) | Platform code under AGPLv3; no licensing fees |
| Who maintains the code | Moodle HQ (Moodle Pty Ltd) | Instructure | Axim Collaborative, a nonprofit founded by Harvard and MIT |
| How it is self-hosted | Download and run it, or use MoodleCloud or Moodle Partners for managed hosting | Quick Start and Production Start guides in the repository wiki | Self-host, or use a managed Open edX provider |
| Identity options | Core auth plugins include LDAP, Shibboleth, OAuth 2, LTI and web services | Confirm SSO and directory options with Instructure documentation for your version | Confirm identity integrations and SSO setup against current Open edX documentation |
| Authoring and course content | Imports SCORM and other packages; course building within Moodle | Course Import Tool reads Common Cartridge and IMSCC files | Studio authoring tool included; SCORM content must be confirmed per deployment |
| Trade-offs for compliance training | Broad plugin ecosystem and common in government and education; assessment and certification plugins must be checked and maintained | Strong fit where Canvas is already in use; confirm the compliance reporting and record features you need | Strongest where the audience is customer and partner academies; internal compliance tracking needs more configuration |
| FedRAMP authorization | Not FedRAMP authorized by this page; confirm fit with your assessor | Not FedRAMP authorized by this page; confirm fit with your assessor | Not FedRAMP authorized by this page; confirm fit with your assessor |
Keeping training records and completion history for the retention period
Completion history and learner records do not move with the course packages. SCORM, AICC and xAPI packages carry the course content and the runtime calls that report progress, but the transcript, certification dates and recertification history live in Cornerstone's own data model. The agency has to export those records separately, map them to Moodle user and course completion fields, and load them as an archive or as imported history. Before cutover, the agency's records officer should confirm which records are official: the completion transcript, the signed attestation that a mandatory course was taken, or the certification expiry date that drives a recertification. Each of these may have a different retention period and a different system of record. Ask who signs off on the export, who checks a sample of migrated records against the source, and whether the export is accepted as a complete copy of the official record or only as a supplementary one.
Plan the archive so it stays readable after Cornerstone access ends. Once the subscription stops, the agency cannot rely on Cornerstone to answer a records request or an audit question. The archive should be in a documented, open format that does not depend on Moodle being online, such as a flat export with a data dictionary, and it should be stored in the agency's own authorized environment with access controls and a tested restore. Confirm with the records officer how long each record class must be kept, how deletion is recorded, and whether any records fall under a legal hold. Retention rules are set by the agency's records officer and applicable law, not by Moodle or any other software. The software can store and report records, but it cannot decide how long they are kept.
Moodle's data model and backups become the agency's responsibility once it runs the system. When a government agency self-hosts Moodle, it owns the database, the file store for uploaded content, the backup schedule and the restore testing. Moodle's documented upgrade paths, such as the 5.1 requirement to point the web server at the /public directory and the minimum database versions for each release, are steps the agency's operations team must plan and record. Confirm which backup tool and retention schedule will cover the Moodle database, the moodledata directory and the archive export, and test a restore of a learner record from each. Assign the owner of each item in the written operating plan so that retention, backup and deletion decisions have a named person behind them.
How to deploy Moodle inside the authorized environment in sequence
This sequence takes a Moodle deployment from an agreed authorization scope to a restore-tested production system inside the agency's authorized environment, with a documented check closing each step. It is written so the authorizing official, the platform team and the training owner can each see when their part is done.
Confirm authorization path and scope
Before any build work, the agency's authorizing official and the system owner agree in writing which environment, data types and users the Moodle deployment falls under. Confirm which controls are inherited from the hosting environment, which the agency must implement itself, and whether any stored data is criminal justice information or controlled unclassified information, since that changes encryption and scanning requirements. The output is a signed scope statement that lists the data categories and the control owner for each area.
Select the Moodle release line
Choose between the 4.5 long-term support release, which has security support until 4 October 2027, and the 5.3 long-term support release, which has security support until 1 October 2029. Read the release notes for the chosen line and record the required PHP version, database engine and version, and the upgrade path. Note that Moodle 5.1 upgrades require sites on 4.2.3 or later, and Moodle 5.3 upgrades require sites on 4.4 or later. The output is a documented release decision that the authorizing official has reviewed.
Build the application and database stack
Provision the application servers with 64-bit PHP at the version the release notes require, and provision one supported database: PostgreSQL, MySQL, MariaDB or Microsoft SQL Server, at a version listed for that release. Keep the database on the agency's authorized network segment and restrict access to the Moodle servers only. The output is a stack inventory with exact software versions, reviewed against the release notes and recorded in the system security plan.
Set the web root to the public directory
From Moodle 5.1 onward, point the web server document root at the new public directory rather than the main Moodle folder. Confirm that the main application code is not served directly, because a misconfigured root can expose directory listings or errors. Test by requesting the site and a few internal paths from an unauthenticated client. The output is a web server configuration file under change control and a test log showing no directory listings.
Configure FIPS-validated cryptography
Where CJI or CUI is stored or transmitted outside physically secure locations, confirm with the authorizing official which cryptographic modules meet the requirement, then configure TLS, database encryption and backup encryption to use FIPS 140-3 validated modules and AES with 256-bit keys. Verify module certificate status on the validation list for each component, including the operating system and database. The output is a cryptography register that maps each data path to its validated module.
Wire identity, HRIS and scan schedules
Connect the agency's enterprise identity provider using the authentication plugins the release supports, and set up the HRIS user feed so enrollments and deprovisioning follow the authoritative source. Schedule vulnerability scans of the Moodle servers and the database at least monthly, and route findings into the agency's tracking process. Reload SCORM 1.2 or 2004, AICC and xAPI packages into a staging course and confirm they launch and report completion. The output is a test report showing login, provisioning, deprovisioning, a scan result and successful package launches.
Rehearse restore before cutover
Take a full backup of the database and the moodledata directory, then restore both into a separate environment and confirm the site runs with the same courses, users and attachments. Record the restore time and any manual steps, and repeat until the process is repeatable by someone other than the builder. Only after a successful restore rehearsal should cutover of live training records begin. The output is a signed restore rehearsal record that the system owner accepts before go-live.
What assessors and inspectors general ask to see for the training system
An assessor or inspector general will not take a training platform on trust. They will ask for documents that show how the system is defined, monitored, restored and reconciled over time. DeployOpen prepares this evidence, but independent assessors and the agency's authorizing official decide what is accepted.
System security plan at moderate baseline
The system security plan describes the Moodle deployment, its boundary, data flows, and which controls from the NIST SP 800-53 moderate baseline are implemented, partially implemented or inherited from the hosting environment. Check that every control points to a named owner, an implementation statement and the component that enforces it. Confirm the boundary includes the database, file storage, SSO connector and any HRIS feed, since assessors will test those paths too.
Plan of action and milestones
A plan of action and milestones lists each open weakness, its planned fix, the responsible owner and the date by which the fix should close. For a self-hosted training system, typical entries include unpatched plugins, missing log forwarding and gaps in session timeouts. Assessors read it to judge whether known gaps are tracked honestly and closed on schedule, so keep it current rather than rewriting it before each review.
Monthly vulnerability scan results
The FBI CJIS Security Policy, where it applies, requires vulnerability scanning at least monthly. Keep dated scan reports for the Moodle application, the PHP runtime, the database and the operating system, with each finding linked to a remediation ticket or a documented risk acceptance. Confirm who triages results and how long critical findings stay open before escalation.
Configuration baselines and FIPS module evidence
Assessors will ask for the hardened configuration of the web server, PHP, database and Moodle itself, along with the version under which it was approved. They will also ask which cryptographic modules protect data in transit and at rest, and whether those modules are FIPS 140-3 validated. Record the module certificate numbers and the exact key lengths in use, because CJIS requirements for CJI moved to 256-bit AES.
Identity and access review records
Access reviews show who holds administrator, course manager and learner roles, when each account was last recertified, and how deprovisioning from the agency directory reached Moodle. Export role assignments and authentication logs from the identity provider and from Moodle's own logs, then compare them. Confirm that shared administrator accounts are not used and that privileged actions are attributable to a named person.
Backup and restore test logs
A backup is only evidence once a restore has been tested. Keep logs of scheduled database and data directory backups, and dated records of restore exercises that rebuild a Moodle site in a separate environment and check course content, grades and completion records. Confirm the restore test includes the external file store, since missing attachments are a common gap in training records.
Records retention and export reconciliation
Training completion, certification and transcript records must be kept for the period the agency's schedule requires, and moved out of Cornerstone without loss. Reconcile record counts and completion dates between the Cornerstone export and the Moodle import, and keep the reconciliation report with the retention schedule. Ask the records officer which retention periods apply before the first import, because they set how long Moodle must keep both data and audit logs.
What agencies ask before replacing Cornerstone with self-hosted Moodle
What drives the cost of an agency-run Moodle compared with a Cornerstone subscription?
The main difference is who pays for what. A Cornerstone subscription bundles hosting, the authorized platform, and vendor-held attestations into a recurring fee. A self-hosted Moodle moves those costs to the agency: infrastructure inside an authorized environment, staff or a services partner to operate it, patching against the Moodle release schedule, backups, and the assessment work to show the environment meets the agency's control baseline. Moodle itself is GPL-3.0 software with no license fee. One-time costs include migration, integration with the HRIS and identity provider, and content conversion. Recurring costs include hosting, operations, upgrades, and support. Ask any quote to split these lines separately, and to state which recurring fees the agency keeps paying for content libraries it already licenses.
How long does a boundary change and migration take for a Moodle deployment?
No duration is fixed by the researched facts, so treat any number from a vendor as a claim to verify. The length depends on the size of the training catalog, how many SCORM, AICC and xAPI packages must be tested, how many records must be exported from Cornerstone, how many integrations must be rebuilt, and how long the agency's authorization and assessment process takes for the new environment. Moodle's release cadence also matters: major releases arrive each April and October, and the 5.1 release notes require sites to be on Moodle 4.2.3 or later to upgrade. Ask for a written scope listing each phase, the acceptance tests, the assessor's review window, and the milestones that depend on agency decisions.
What must the agency's own team provide for a self-hosted Moodle?
The agency keeps several responsibilities that Cornerstone currently holds. Expect to provide:
- An identity source, such as a directory or SSO service, that Moodle can authenticate against. Core Moodle ships LDAP, OAuth 2, Shibboleth and external database authentication, and a SAML2 plugin is available from the Moodle marketplace.
- An HRIS feed that supplies users, org units and assignments, and a named owner for it.
- A records owner who defines retention periods, approves exports and signs off on the training record schema.
- Assessor access to the environment, logs and configuration evidence during the authorization review.
Ask the provider to list which of these items it will build, which the agency must supply, and the dates by which each input is needed.
Can our internal team deploy and run Moodle without an outside partner?
A capable internal team can run Moodle, but the agency should judge this against the parts of the work it has not done before. Moodle is installable from source and is maintained by Moodle HQ, and it can also be run through MoodleCloud or Moodle Partners, which changes who operates the environment. The operational load includes PHP and database version requirements, the web server document root change to /public from Moodle 5.1, upgrades on the April and October major cycle, and point releases every two months. Authorization and assessment evidence is a separate skill. Teams that choose a partner should ask for a written, fixed scope covering installation, hardening, backup testing, and handover, with named deliverables. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside the client's own infrastructure, and prepares evidence for assessments, but it does not issue authorizations or audit reports.
Can Moodle meet the ADA Title II WCAG 2.1 AA requirement for agency training?
Moodle can be configured and used in ways that support WCAG 2.1 AA, but the platform alone does not make training content compliant. The ADA Title II web rule requires state and local government web content and mobile apps, including those provided through contracts or licenses, to meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts (28 CFR 35.200). Most accessibility failures in training come from the content: uploaded SCORM or PDF files, video without captions, and custom course pages. Ask the vendor for its accessibility testing approach for the theme and plugins in use, and confirm the status of each third-party content library the agency uses, since those packages stay under their publishers' control.
Does Cornerstone's FedRAMP authorization transfer to a self-hosted Moodle?
No. A FedRAMP authorization applies to a specific cloud service offering, and it does not move with the software license. Cornerstone describes its learning platform as holding FedRAMP Moderate authorization, but that authorization covers Cornerstone's service, not an agency-run copy of Moodle. Under OMB memo M-24-15, FedRAMP's scope covers cloud products and services that handle federal information on behalf of an agency, while systems used only for one agency's operations on cloud infrastructure, and not offered as a shared service, are out of scope. That means the agency's own system must be assessed under the agency's authority to operate, using the control baselines NIST SP 800-53B defines: 149 controls at low, 287 at moderate and 370 at high. Ask the assessor, early and in writing, which baseline and which authorization path applies to the planned environment.
How DeployOpen plans an agency Moodle deployment under federal constraints
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including authorized environments. For agencies replacing Cornerstone, the work starts with written scope that maps which controls the agency inherits, which it must operate itself, and which evidence an assessor will need.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists the Moodle version, hosting boundary, database, identity sources and training content formats in use.
- We map which controls the agency's authorized environment already covers and which Moodle controls the agency must operate.
- Scope also records the training records to migrate, retention rules and the people who approve each decision.
How we build
- We install Moodle inside the agency's own authorized environment, configuring the web server document root to the /public directory.
- Authentication is set up against the agency's identity source using the core plugins the agency has approved.
- We configure database, backup, logging and TLS settings to match the baseline the agency's assessor has accepted.
- Vulnerability scanning and testing cover the Moodle instance, plugins and the hosting stack before handover.
How we hand over
- Deliverables include configuration documentation, a control mapping and runbooks for upgrades and restores.
- We reload SCORM, AICC and xAPI packages and document how completion records were exported and verified.
- Staff receive admin training on user, course, certification and reporting tasks the agency will run itself.
- Evidence packages are prepared for the agency's assessors, who decide what they accept.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainer work can cover Moodle release upgrades, plugin reviews and patching on the agency's schedule.
- Ask for the support hours, response expectations and change process to be written into the quote before signing.
- DeployOpen prepares systems and evidence for assessments but does not issue audit reports or authorizations.
