Moodle for public sector training

Government and agency learning on Moodle depends on where the platform is hosted, how staff and citizens sign in, and whether courses meet accessibility deadlines. This page sets out those requirements and what to ask a partner.

On this page

Moodle for public sector training starts with where the data lives

A public body that must train its staff or serve citizens with courses needs a learning platform it can keep inside its own legal and technical boundary. Moodle fits this need because it is open-source software that can be self-hosted in infrastructure the agency controls, so the agency decides where learner records, assessment results and course content are stored, who can administer them and how they are backed up. Moodle's code is licensed under GPL-3.0 and is maintained by Moodle HQ (Moodle Pty Ltd). Managed hosting through MoodleCloud or Moodle Partners is available, but it is an option rather than a requirement for a public body. Hosting jurisdiction is the first decision. A commercial SaaS course platform usually places the service, and often the support staff with remote access, in a jurisdiction chosen by the vendor. Learner records in a public body can include staff personnel information, citizen identifiers and records of mandatory training that auditors may ask to see. Before choosing a host, confirm with legal counsel which laws govern each data category, whether any data may leave a given country or region, and whether support engineers in other countries would see data on screen. Those answers determine whether the hosting is a national cloud region, a government data center, a sovereign cloud or on-premises servers. Remote administration from outside the jurisdiction also counts as a access question, so write it into the support model from the start. Identity source changes what the platform must do. In a SaaS course platform, the vendor often manages accounts. In a public body, the authoritative source is usually a workforce directory, a citizen identity service or a single sign-on provider that already governs access to other systems. Moodle core includes authentication plugins for LDAP, external database, OAuth 2, Shibboleth and web services, and SAML 2.0 is commonly delivered through the SAML2 Single sign on plugin (auth_saml2) maintained by Catalyst IT. Decide which source creates accounts, which attributes map to Moodle profile fields, how leavers are removed and whether course enrolment follows role data from HR or a separate register. Confirm the plugin version supports your Moodle release before you commit to it. Accessibility and procurement carry obligations that stay with the agency. In a SaaS contract, the vendor's accessibility statement may be the only evidence. Under the ADA Title II web rule in the United States, state and local government web content and mobile apps, including those delivered through contracts or licenses, must meet WCAG 2.1 Level A and AA. The compliance date depends on population served: 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts. Because the agency owns the deployment, it must also own themes, custom plugins and course content accessibility testing. Ask a partner to include accessibility review in scope and to record which findings the agency must fix. Procurement teams should also ask whether the implementation contract and support retainer can be awarded separately from the software, and what happens to the data and configuration if the support provider changes.

Which public sector requirements shape a Moodle build

This table lists the public sector requirements most likely to change how a Moodle build is hosted, secured, configured and supported. Read each row as a question to answer early: which obligation applies to your agency, and what that means for the architecture. The main takeaway is that hosting location, admin access and course content each bring their own obligations, so scope them before the build starts.

RequirementSourceWhat it means for the build
NIST SP 800-53B control baselinesNIST SP 800-53B; SP 800-53 Rev. 5 catalogLow, moderate and high baselines select 149, 287 and 370 controls and enhancements. Choose the baseline before hosting, logging and access design.
FedRAMP scope for cloud servicesOMB M-24-15 (25 July 2024); FedRAMP scope rulesApplies to cloud services handling federal information for an agency. A single-agency Moodle may fall outside scope, so confirm with the authorizing official.
ADA Title II web and app accessibility (WCAG 2.1 Level A and AA)28 CFR 35.200 (ADA Title II)Plan around 26 April 2027 (50,000 or more people) or 26 April 2028 (smaller entities, special districts). Vendor-built content counts.
NIS2 coverage of public administrationDirective (EU) 2022/2555, Articles 2 and 3, Annex ICentral government bodies are covered regardless of size. Entities in defense, national security, public security or law enforcement are excluded.
Transfers of personal data outside the EEA, including remote adminGDPR Article 44 and Chapter V; EDPB Guidelines 05/2021Remote support or admin from a third country counts as a transfer, even when only a screen is shown. Restrict, log and document that access.
Controlled unclassified information (CUI) on non-federal systems32 CFR 2002.14(h)(2)Agencies use NIST SP 800-171 when setting CUI safeguards for non-federal systems, unless the category sets other rules. Confirm markings before loading material.
Criminal justice information (CJI) storage or processingFBI CJIS Security Policy v6.1, effective 26 June 2026 (via California DOJ bulletin 2026-ISRS-001)Applies only where CJI is stored or processed. Then FIPS 140-3 modules or AES-256 are needed at rest and in transit outside secure locations.

How hosting jurisdiction changes the Moodle architecture

The hosting choice decides who holds administrative access to the Moodle database, the file store, backups and logs, and that answer shapes the rest of the architecture. A public body usually considers three options: a national or sovereign data center, a government cloud tenancy in a provider region the agency controls, or a managed Moodle partner that runs the stack. In a sovereign data center, the operator's own staff typically hold root and database roles. In a government cloud tenancy, the provider's engineers operate the hypervisor and storage layers, while the agency controls accounts, keys and application administration. With a managed partner, the partner's engineers administer the application and often the database, so the contract must name the locations and the roles involved. Ask each candidate for a written list of who can log in to each layer, from which countries, and under what approval.

Under the GDPR, two patterns count as transfers that teams often miss. Storing personal data outside the EEA is a transfer, and so is remote access from a third country, even when the person only views records on a screen during a support session. EDPB Guidelines 05/2021 (version 2.0) state both points directly. This matters for a training platform because learner records, assessment results and certificate data are personal data, and support desks, offshore managed-service teams and vendor engineers using screen sharing all touch them. Article 44 requires every transfer, including onward transfers, to meet the conditions in Chapter V, and infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c). Map every role that can view learner data, its physical location, and whether backups replicate to other regions.

An EU location does not by itself settle the exposure. Under 18 U.S.C. 2713, added on 23 March 2018, electronic communication and remote computing service providers must preserve or disclose data in their possession, custody or control, whether that data sits inside or outside the United States. A provider with a US parent or US-based operators may therefore receive such an order even for an EU region. EDPB Recommendations 01/2020 (version 2.0) state that where a cloud provider needs access to data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure. Encryption does not fix this if the provider can access the keys. The guidelines' Example 12 treats engaging an EU processor subject to third-country law as outside the transfer definition, while complying with a third-country request would fall inside it. Assess this exposure with counsel before signing.

FedRAMP matters when a US federal agency, or a contractor serving one, hosts the platform on cloud infrastructure. In plain terms, FedRAMP covers 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 of 25 July 2024, systems used only for a single agency's operations on cloud infrastructure, and not offered as a shared service, fall outside FedRAMP. That does not remove federal security requirements. Agency systems under FISMA are still assessed against NIST SP 800-53, where the low, moderate and high baselines select 149, 287 and 370 controls and enhancements respectively. The agency must confirm its own classification with its authorizing official, record the reasoning, and check whether the Moodle tenancy will serve other agencies, since that changes the answer.

Which Moodle modules and integrations agencies configure first

Before a ministry or agency builds courses, it has to decide how staff sign in, who gets enrolled and how completion is proven. The cards below cover the core authentication options, the SAML2 plugin, enrolment from HR data, role design, audit evidence and the Moodle 5.1 document root change that every upgrade should check.

Core authentication plugins

Moodle core ships authentication plugins for LDAP, OAuth 2, Shibboleth, external database, LTI and web services, alongside manual accounts and email self-registration. The decision is which source of truth holds staff identities and whether accounts are created on first login or provisioned in advance. Ask the partner which of these the agency's directory can actually feed, and what happens to accounts when a person leaves.

SAML 2.0 single sign-on with auth_saml2

SAML 2.0 single sign-on in Moodle is commonly provided by the SAML2 Single sign on plugin (auth_saml2), maintained by Catalyst IT, which creates users with field mapping configured in Moodle. The agency must decide which identity provider attributes map to username, email, first name, last name and any organizational fields. Ask the partner how attribute mapping is tested against a staff directory before go-live, and who maintains the plugin when Moodle changes.

Field mapping for staff directories

Directory attributes rarely match Moodle profile fields without adjustment, and government directories often hold several candidate values for the same person. The agency needs to decide which attribute is authoritative for each profile field and how changes flow in after first login. Ask the partner to produce a mapping table with example records, and to confirm which fields update on every sign-in and which are set only once.

Enrolment synced from HR for mandatory training

Mandatory training depends on enrolment being correct, so the agency has to decide whether enrolment is driven by HR records, directory groups or manual cohorts. Each option has different failure modes, such as staff who move departments mid-course or contractors who should not appear in staff reports. Ask the partner how removals are handled, how sync errors are reported, and how a rerun is audited.

Role and category design for ministries and agencies

Moodle role assignments and course category structure determine who can build courses, see learner records and read reports across a multi-agency estate. The agency needs to decide where course authority sits, which roles are delegated to each agency, and whether reporting crosses agency boundaries. Ask the partner to show the role matrix and category tree on paper before any configuration starts, and to test that one agency cannot see another's learner data.

Certificates and completion records as audit evidence

Certificates and completion records are often the evidence an auditor or inspector asks for when proving that staff were trained. The agency must decide which completion criteria count, how long records are kept and whether exports are stored outside Moodle. Ask the partner how completion logic is documented, how records are retained under the agency's records schedule, and how a sample export would be produced for an assessor.

Document root change for Moodle 5.1

From Moodle 5.1, the web server document root must point to the new /public directory rather than the main Moodle folder, otherwise the site may show directory listings or errors. This is a server configuration decision that affects every environment, including test and staging. Ask the partner to confirm the web server configuration for each environment, to check it during the upgrade runbook, and to verify that no code outside /public is exposed.

Meeting the accessibility deadline for training content

Under the ADA Title II web and mobile rule, state and local government web content and mobile apps must meet WCAG 2.1 Level A and AA, and this includes content provided through contracts or licenses. The compliance date is 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts. A Moodle site that delivers training to staff, contractors or the public falls within this rule, and so does training content a vendor supplies under a license. Before planning the work, the agency should confirm with counsel which entity category it belongs to, because that category sets the date the agency must meet and how the population threshold is counted.

The review covers more than the Moodle core code. It reaches the site's theme, the content uploaded to courses, and every third-party plugin that renders pages or activities. In practice that means the login page, course pages, navigation, activity modules, H5P and SCORM packages, and quiz interfaces, including each question type that learners answer. Each of these layers can introduce barriers even when core Moodle is compliant. The agency should build a test inventory that lists every theme, plugin, and content package in production, with an owner for each item, so that testing covers the full learner path rather than a sample of courses.

Theme choice needs particular attention in Moodle 5.3, released on 5 October 2026, because it removes the Classic theme from core. Sites that still rely on Classic will need to select a replacement theme and test it before go-live. Custom themes and theme overrides, including custom CSS and template changes, must be retested against WCAG 2.1 A and AA after the theme choice changes. The same applies to every later upgrade, since a change in core templates or a plugin update can alter focus order, color contrast, or form labels in a theme that previously passed. Treat the theme as a versioned component with its own regression test set.

Automated scanning finds some barriers quickly, but it cannot confirm that a quiz is usable by keyboard or that a screen reader announces a SCORM player's controls in a sensible order. Manual testing should include keyboard-only navigation, screen reader checks on representative courses, caption and transcript review for video, and timed quiz checks that allow extra time where the course design requires it. For H5P and SCORM packages supplied by third parties, the agency should request each supplier's accessibility documentation and decide whether non-conforming packages will be remediated, replaced or retired. Contracts for new content should require conformance to WCAG 2.1 AA and name who performs the testing.

Plan two budget lines: one-time remediation of the existing theme, plugins and legacy content, and a recurring testing cycle after each upgrade and each batch of new content. When requesting a quote, ask the partner to list the theme, plugins, and content types in scope, the test methods used, who performs remediation, and what evidence is delivered. Ask whether retesting after each Moodle upgrade is included. DeployOpen can prepare test records and remediation evidence for the agency, but conformance decisions and any formal assessment remain with the agency and its independent reviewers.

Compliance evidence public sector learning teams must produce

Government Moodle sites often answer to several frameworks at once, and each one asks for different evidence. The cards below cover the controls, encryption rules, scanning cadence and procurement terms that learning teams should map before training content goes live. DeployOpen prepares systems, controls and evidence for assessment, but independent auditors and certification bodies issue any audit report, attestation or certification.

NIST SP 800-53 control mapping

Federal agencies and their contractors often use the SP 800-53 Rev. 5 catalog as the baseline for learning systems. For Moodle, map access control (AC) to role assignments, SSO configuration and administrator accounts. Map audit and accountability (AU) to web server, database and Moodle logs, configuration management (CM) to version-controlled settings and plugin inventories, and contingency planning (CP) to tested backup and restore. Confirm with your assessor which baseline (low, moderate or high) applies to the site.

CUI handling under 32 CFR 2002

When training materials carry a controlled unclassified information (CUI) marking, 32 CFR 2002 and the agency's own requirements decide how that content is protected. For a non-federal system, 32 CFR 2002.14(h)(2) points to NIST SP 800-171 unless the CUI category's authority prescribes other safeguards. Check who can view marked courses, whether files sit in the Moodle file area or external storage, and whether backups and staging copies carry the same protection.

CJIS encryption requirements

CJIS Security Policy version 6.1, effective 26 June 2026, applies only where criminal justice information (CJI) reaches the Moodle site, for example in law enforcement training that uses case data. It requires FIPS 140-3 certified modules or FIPS 197 AES with keys of at least 256 bits for CJI in transit and at rest outside physically secure locations. Check TLS termination, database and backup encryption, and whether the key management service is itself validated.

Monthly vulnerability scanning

CJIS Security Policy version 6.1 expects vulnerability scanning at least monthly, mapped to control RA-5, wherever CJI is in scope. For a Moodle stack, that means scanning the operating system, web server, PHP runtime, database and every installed plugin, not only the public URL. Keep scan reports, remediation dates and documented exceptions in one record, because assessors review the trail as well as the scan results. Agree the scanner's authorized scope with the hosting team before the first run.

NIS2 obligations for public administration

NIS2 covers central government entities regardless of size and lists public administration as a sector of high criticality. Member states may extend it to local public administration. It does not apply to entities working in national security, public security, defense or law enforcement. Confirm with your national authority whether the agency is in scope, and which risk management and incident reporting duties apply to the learning platform as a supporting system.

EU Data Act switching right

The EU Data Act, applicable since 12 September 2025, gives customers of a data processing service the right to switch to another provider or to on-premises infrastructure. The maximum notice period is two months and the transition period is 30 days. Switching charges are banned from 12 January 2027. Check these terms in any hosting or managed Moodle contract, including export formats for courses, user records and completion data.

How a public sector Moodle rollout moves from scoping to live courses

This sequence takes a public sector agency from agreed scope to a live Moodle service for staff or citizen training. Each phase has an owner on both sides and closes with a written output that the next phase depends on. The order matters because hosting, identity and version decisions constrain everything that follows.

  1. Classify data and approve the hosting decision

    The agency classifies the training data, including any personal data, criminal justice information or controlled unclassified information, and decides where the platform will run. Security and legal teams review the classification before any build starts. The agency provides the data inventory, applicable policies and named approvers. DeployOpen maps the relevant control baselines and transfer conditions to a written hosting record and prepares the evidence those reviewers need. The step is done when security and legal sign-off are recorded against that hosting record.

  2. Design identity and directory integration

    The agency decides which populations need accounts, such as staff, contractors and citizens, and names the authoritative directory or identity provider for each. DeployOpen selects the authentication methods for each group from Moodle core, such as LDAP, external database, OAuth 2 or Shibboleth, and plans SAML 2.0 through the auth_saml2 plugin where the agency uses it. The partner designs field mapping, cohort and role rules, and how leavers lose access. Confirm that the plugin supports the Moodle version chosen in the next phase. The step is done when test logins for every user type succeed and a removed test account loses access.

  3. Select the Moodle version against support windows

    The agency states how long the platform must stay in security support and how often it can take upgrades. DeployOpen compares the support windows of the candidate releases. Moodle 4.5 has security support until 4 October 2027. Moodle 5.3 is the next LTS, with general support and security support until 1 October 2029 for security support. Each candidate has its own server requirements, such as PHP 8.3 or later and PostgreSQL 17 for 5.3, and its own upgrade starting version. The step closes with a decision record that lists the version, the server stack and the document root layout.

  4. Build the course platform and test accessibility

    DeployOpen builds the theme, course templates, plugins and integrations agreed in scope, then runs functional and security testing on the build. The agency supplies accessibility requirements, test accounts and content owners who review course designs. Public bodies that serve many residents face WCAG 2.1 Level A and AA obligations under the ADA Title II rule from 26 April 2027, and smaller entities from 26 April 2028, so confirm which deadline applies to your organization. The step is done when a written accessibility test report shows every issue closed or formally accepted by the agency.

  5. Migrate existing course content and users

    The agency provides exports from the current learning system, a course inventory, question banks and the user population to be carried over. DeployOpen maps each source object to its Moodle equivalent, runs the import in a staging copy and checks the results against the source. The partner also tests that enrolments, grades and activity links survive the move. Confirm with the agency which records must be kept and for how long before any source data is deleted. The step is done when a reconciliation report of course, question and user counts is signed by the agency content owner.

  6. Run a pilot with a limited set of agencies

    The agency selects a small group of participating agencies, their course owners and a set of pilot learners. DeployOpen supports the pilot with a triage process, a support runbook and a feedback channel for course owners. Both parties agree the exit criteria before the pilot opens, covering access, course function, accessibility issues and support response. The partner records defects and fixes them in the build, then reruns the affected tests. The step closes when the agency confirms in writing that the exit criteria are met and that the pilot has ended.

  7. Go live with a documented upgrade and patch cadence

    The agency assigns a platform owner and approves the change process for production. DeployOpen hands over runbooks for backups, restore tests, monitoring and incident response. The partner also documents the patch cadence, which should follow Moodle's published schedule of major releases in April and October and minor point releases in February, April, June, August, October and December. Each point release and each major upgrade is rehearsed on staging before production. The step is done when the agency accepts the runbooks and the first restore test has passed.

How to procure implementation and support for a Moodle platform

Public bodies usually divide Moodle work across three parties: their own staff, a managed hosting provider and an implementation partner. The split decides who holds the database, who applies patches, who answers when a course fails at 9 a.m. on an exam day, and who signs for accessibility outcomes. Before any work starts, the written scope should name each party's responsibilities against the components that matter for public sector training: the web server and PHP runtime, the database engine, the authentication source, the theme and custom plugins, the backup policy and the release calendar. A scope that says only "set up Moodle" leaves each of those gaps open, and gaps are where cost overruns start.

The one-time build covers installation, hardening, course and category structure, role and permission design, theme work, plugin selection and configuration, and training for administrators and course designers. Data migration is a separate line. Moving courses, question banks, user records and completion history from an older system requires field mapping, test imports and reconciliation, and its effort depends on how clean the source data is. Accessibility remediation is also separate. Public bodies serving 50,000 or more people must meet WCAG 2.1 Level A and AA for web content and mobile apps from 26 April 2027, and smaller entities and special districts from 26 April 2028 (28 CFR 35.200). Ask the partner to scope an accessibility review of the theme, core activities and any custom plugin, and to state which findings it will fix and which the organization's own content owners must fix.

Recurring costs are where public bodies most often underestimate the total. Hosting, whether in national or sovereign infrastructure or with a managed provider, is paid every period. Security patching of the operating system, PHP, the database and Moodle itself is also ongoing. Upgrades between releases are the largest recurring item. Moodle 5.1 requires PHP 8.2 or later and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later, and sites must be on Moodle 4.2.3 or later to upgrade. Moodle 5.3 requires PHP 8.3 or later, PostgreSQL 17 and sites on Moodle 4.4 or later. Confirm with the partner which release the site will run, which support window applies (Moodle 5.1 security support ends 19 April 2027), and what each upgrade includes, such as test environments, custom plugin compatibility checks and rollback.

DeployOpen engagements most often start as fixed-scope agreements, with scope, deliverables and timelines agreed in writing before work begins. Ask any provider for the same: a deliverables list, acceptance criteria, named exclusions, the responsibilities of the client team and a change process for requests that fall outside scope. Ongoing support, upgrades and continuous testing are available as retainers, and the retainer should state response expectations, patch cadence and what happens during a major release. DeployOpen publishes no price list. A quote follows from the written scope, so the most useful preparation is a clear statement of the systems to connect, the number of courses and users, the migration sources and the accessibility obligations that apply to the organization.

Questions agencies ask before hiring a Moodle partner

What drives the cost of a Moodle public sector project?

Scope drives most of the cost, and the main levers are integration count, custom plugins, accessibility remediation and migration volume. Integrations: each connection to a student or HR record, identity provider or reporting tool needs field mapping, error handling and testing against a non-production copy. Custom plugins: a plugin you write or heavily modify must be maintained through every Moodle upgrade. Accessibility remediation: cost depends on how much existing content fails WCAG 2.1 AA and how much of it staff must re-author. Migration volume: the number of courses, question banks and user records sets the transfer and validation effort. Design, build, migration and rollout are one-time costs. Hosting, upgrades, security patching and support recur every year. Ask any partner for a fixed-scope quote that lists each driver separately, so you can see which items to reduce if the budget tightens.

Can our agency run Moodle itself after launch?

Yes, if your team can operate a PHP application, a supported database and a web server, and can upgrade on a fixed schedule. Moodle ships major releases in April and October and minor point releases every two months, so upgrades need a standing calendar routine. Check the release notes before each step. For example, Moodle 5.1 requires 64-bit PHP 8.2 or later and moves the web server document root to the /public directory, and sites must be on Moodle 4.2.3 or later to upgrade. Moodle 5.3 requires 64-bit PHP 8.3 or later and PostgreSQL 17, and sites must run 4.4 or later. Confirm your upgrade path from your current version in a test environment before deciding whether your staff or a partner will carry out upgrades.

How long does a Moodle implementation take and what staff time does it need?

Duration depends on scope, integration count, content volume and how quickly decisions are made, so do not accept a timeline before a written scope exists. Your side typically needs a business owner who signs off the design, an identity or HR contact for user feeds and sign-on, a course content lead, an accessibility reviewer, a data owner for migrated records, and an approver for security and hosting controls. Your staff usually spend the most time on decisions, content review and sign-off, while a partner carries most of the build, configuration and testing. Ask for a plan with named milestones, the approvals required at each one, and the dependencies on your procurement and change control processes.

Which hosting option fits a data sovereignty requirement for Moodle?

Self-hosting in infrastructure you control, such as a national data center or an air-gapped network, gives you the most direct control over where data is stored and who can reach it. Managed hosting from a vendor or partner is workable only after you confirm where data is stored, which operators can access it and how support access is granted. Under GDPR Article 44, remote access from a third country, even only to display data for support, can count as a transfer, so support arrangements matter as much as storage. Laws with extraterritorial reach can also apply to providers. The US CLOUD Act provision at 18 U.S.C. 2713, for example, can require a provider to preserve or disclose data in its possession, custody or control wherever it is located. Ask your legal team to map every data flow and every operator access path before you choose a host.

When do the ADA Title II accessibility deadlines apply to Moodle courses?

For state and local government entities, the ADA Title II rule requires web content and mobile apps, including those provided through contracts or licenses, to meet WCAG 2.1 Level A and AA. The compliance date is 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts. Whether your courses, portal pages and embedded content fall within the rule, and which date applies to your entity, are questions for your legal team and counsel. Start the accessibility review early so remediation of existing courses, including documents, media captions and quiz design, appears in the plan from the beginning. Ask any partner to test against WCAG 2.1 AA, report the findings in writing, and state which fixes they will carry out and which your content team must complete.

Does a Moodle partner certify our compliance with NIST or CJIS?

No. A partner can design controls, configure Moodle and its hosting, and prepare evidence, but independent auditors and certification bodies issue audit reports and certifications. The framework that applies depends on your data and contracts. NIST SP 800-53 Rev. 5 is the federal control catalog, and the SP 800-53B low, moderate and high baselines select 149, 287 and 370 controls and enhancements respectively. Where criminal justice information is involved, the FBI CJIS Security Policy version 6.1, which took effect on 26 June 2026, requires FIPS 140-3 certified modules or FIPS 197 AES with keys of at least 256 bits for CJI in transit and at rest outside physically secure locations, plus vulnerability scanning at least monthly. Ask the partner which controls they will implement, which evidence they will hand over, and how that evidence will be reviewed by your assessor.

How do Moodle SSO and HR integrations affect the project?

Moodle core includes authentication plugins for manual accounts, email self-registration, external database, LDAP, LTI, OAuth 2, Shibboleth and web services. SAML 2.0 is commonly handled by the SAML2 Single sign on plugin (auth_saml2), maintained by Catalyst IT, which creates users with field mapping configured in Moodle. Its directory entry lists support for Moodle 2.7 through 5.1, so confirm compatibility with the maintainer before moving to a newer release. Decide first which system is the source of truth for accounts, and how accounts are created, suspended and mapped to roles. Then test attribute release with your identity provider on a staging site. Each HR feed added later needs the same test cycle, and each one adds recurring maintenance.

How DeployOpen scopes and supports public sector Moodle work

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted Moodle inside the agency's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.

How we scope

  • Confirm which agency, staff or citizen groups will enroll, and which data sets Moodle will hold
  • Map identity sources and the SAML 2.0 or LDAP path to the agency directory before build starts
  • Record hosting location, accessibility obligations and the Moodle release and database versions in the written scope

How we build

  • Design course, category and role structures around training catalogs, certificates and reporting needs
  • Configure core authentication, enrolment and any community plugins, testing each integration against a staging site
  • Verify accessibility of the theme and custom content against the WCAG 2.1 AA criteria the agency must meet

How we hand over

  • Deliver installation, configuration and integration documentation for the agency's administrators and developers
  • Walk through backup, restore and upgrade procedures, including the web server document root change required from Moodle 5.1
  • Agree which operational tasks stay with the agency's team and which the retainer covers

How we support

  • Offer ongoing support, upgrades and testing as a retainer after handover
  • Plan upgrades around each release's minimum starting version and server requirements, confirmed against the release notes
  • Keep security patching, backups and access reviews running on a schedule the agency approves

Sources and further reading

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.