Open source LMS and FERPA student records: what the law asks of your platform
If your school or university runs or plans a self-hosted LMS, the platform holds education records, so access control, disclosure logging and partner contracts have to be designed into the system from the start. FERPA's regulations in 34 CFR Part 99 apply to any educational agency or institution that receives funds made available under a program administered by the US Secretary of Education (see 34 CFR Part 99 on eCFR). Grades, assignment submissions, discussion posts, quiz results and course enrollment tied to a named student are typically in scope when they are directly related to a student and maintained by the institution. Whether you run Moodle on your own servers, in a cloud account you control, or through a hosting partner, the obligations attach to the records, not to the hosting arrangement. A partner does not change the institution's duties.
Before go-live, confirm which LMS data your institution treats as education records and map where each category is stored, including backups, logs, analytics exports and any LTI tools that receive learner data. Then decide who holds each role on the platform. The regulations require reasonable methods, such as physical or technological access controls, so that school officials see only the records in which they have a legitimate educational interest (34 CFR 99.31(a)(1)(ii)). In Moodle, that means reviewing role assignments at the system, category and course levels, restricting what teachers and support staff can export, and testing whether a support account can open another course's gradebook.
Disclosure logging is the control most often missed in self-hosted setups. FERPA requires a record of each request for access to, and each disclosure of, personally identifiable information from a student's education records, including the parties and their legitimate interests, kept for as long as the records are kept (34 CFR 99.32). Confirm that your audit logs capture exports, bulk downloads and API access, that they are retained for the full records retention period, and that a hosting or support partner can act as a school official only when it performs a service the institution would otherwise use employees for, remains under the institution's direct control, and follows the redisclosure limits in 99.33(a) (34 CFR 99.31(a)(1)(i)(B)). Put those conditions, along with breach notice, subprocessor approval and deletion at exit, into the written contract before any learner data is copied to a partner's environment.
How each FERPA requirement maps to LMS functions and configuration
This table maps the FERPA provisions that matter most for a self-hosted LMS to the functions, roles and settings that support them. Read each row as a starting point for your own control design, since the institution owns the final mapping and should confirm it with counsel and its privacy office.
| Requirement | What the LMS function needs | Configuration notes and evidence to keep |
|---|---|---|
| School official status (34 CFR 99.31(a)(1)(i)(B)) | A written agreement that the hosting or support partner performs a service staff would otherwise do, works under the institution's direct control for records use and maintenance, and observes redisclosure limits | Contract clauses on direct control, redisclosure limits and return or deletion of records. In Moodle and Canvas, limit partner administrator accounts to named people and document each grant |
| Role-based access by legitimate educational interest (34 CFR 99.31(a)(1)(ii)) | Roles that give instructors, advisors, administrators and support staff only the course, group and user data they need | Moodle: define custom roles under Site administration and review capabilities such as viewing participants, grades and user reports at course and category level. Canvas: use account-level and course-level roles and custom permissions, then test each role with a sample account |
| Grade and course permission boundaries | Only the instructor of record and authorized staff can view or change grades, submissions and feedback for a section | Check grade capabilities in Moodle gradebook roles and Canvas grading permissions. Confirm that teaching assistants and observers cannot export gradebooks beyond their section. Keep a dated record of role changes |
| Disclosure logging (34 CFR 99.32) | A record of each request for access to and each disclosure of personally identifiable information, with the parties and their legitimate interest, kept as long as the records are kept | Enable and retain the platform logs that show logins, report generation, data exports and admin changes. Logs alone may not record the legitimate interest, so pair them with a request and disclosure register the registrar maintains. Confirm log retention with the platform team |
| Export for inspection requests (34 CFR 99.10(b)) | Ability to locate and produce a student's education records within a reasonable period and not more than 45 days after the request | Build a repeatable export procedure covering course activity, grades, submissions and messages. Test it on a sample student before the first real request. Record the date each request was received and fulfilled |
| Retention and deletion settings | Records kept only as long as the institution's retention schedule requires, with a documented process for deletion of courses, users and backups | Set course and user retention rules in the platform and in backup jobs. Confirm that backup copies follow the same schedule. Keep evidence of each deletion run |
| Enforcement exposure (34 CFR 99.67) | A working compliance program, because noncompliance can lead to withheld payments, a cease and desist order or termination of eligibility for funding | Keep the role design, access reviews, disclosure register and partner contract together as one evidence set. Review them after each platform upgrade, since role capabilities can change between releases |
Which open-source LMS platforms fit a FERPA-scoped deployment
Moodle, Canvas and Open edX each fit different institutions, identity stacks and operations teams. The choice affects who holds the school official relationship with the hosting partner, how logs are produced and retained, and how much of the access control model you build yourself.
Moodle for broad, identity-integrated campuses
Moodle is licensed under GPL-3.0 and ships core authentication plugins for LDAP, Shibboleth, OAuth 2, LTI and web services, which covers many campus directory and single sign-on designs without custom code. Moodle 5.3 is the next long-term support release, with security fixes until 1 October 2029, which helps match upgrade planning to budget cycles. Confirm which authentication method your directory needs and whether the SAML2 plugin is required. Check that logging of record access meets your disclosure log design before you select.
Canvas for teams that can run a Rails stack
Canvas LMS is licensed under AGPL-3.0 and needs PostgreSQL 14 or later and Redis for caching and OAuth2, plus Apache with Passenger, a background job daemon and outgoing SMTP. The Production Start guide recommends at least 8GB of RAM and directs installation problems to the community mailing list or IRC rather than vendor support. Choose Canvas only if you have engineers who can operate that stack and a partner who will carry support obligations in writing. Confirm which audit and access logs the release you deploy produces.
Open edX for course delivery
Open edX is licensed under AGPL-3.0 and is strongest for delivering courses to large external audiences. Its release model supports only the latest release, so every upgrade becomes a planned event. Its record-keeping and role model fit course delivery more than institutional academic records, so confirm whether gradebook and enrollment data your school must protect can be exported, restricted and logged. Treat it as a secondary option unless course delivery is the primary need.
Matching platform to institution size
Large universities with a central identity office and an in-house systems team can absorb Moodle or Canvas operations. Smaller colleges and districts usually need a hosting partner that takes on patching, backups and restore testing under a written agreement. Illustrative example: a district with one part-time administrator should weigh a platform whose upgrade path a partner can run on a fixed schedule over one that depends on local staff for every point release.
Matching platform to identity stack
Map the platform to your identity provider before you choose. Moodle's core plugins cover LDAP, Shibboleth and OAuth 2, which suits most campus directories. Canvas integrates with identity through its own configuration and OAuth2 services that depend on Redis. Confirm how role claims, departmental groups and deprovisioning at the end of enrollment flow into each platform, because this governs access by legitimate educational interest.
Confirm logging support before selection
FERPA requires a record of each disclosure of personally identifiable information, kept as long as the records are kept. Core features do not guarantee this log for every access path, so test each candidate. Ask the vendor or community which events are recorded, whether logs can leave the application database, how they are retained, and whether a plugin is needed. Record the answers in your selection file so the audit trail is designed, not assumed.
When a hosting or support partner can act as a school official
A hosting or support partner can receive student education records without written consent only when it qualifies as a school official under 34 CFR 99.31(a)(1)(i)(B). The regulation sets three conditions. First, the partner must perform a service the institution would otherwise use its own employees for, such as running the Moodle server, applying security patches or restoring course data after an outage. Second, the institution must keep direct control over the use and maintenance of the records. Third, the partner must follow the redisclosure limits in 99.33(a), meaning it may use the records only for the purposes the institution authorized and may not pass them to anyone else without a lawful basis. All three must hold at the same time. A partner that meets the first condition but works on its own terms for its own product purposes fails the other two.
Three common arrangements produce three different answers. A vendor that hosts a Moodle or Canvas instance in its own cloud and uses student data to improve its wider product is unlikely to meet the direct control test, because the institution does not control how the vendor maintains or uses the records. An implementation partner that deploys the platform inside the institution's own cloud account or data center, works under the institution's written instructions and returns or deletes data at the end of the engagement is in a much stronger position. A plugin developer is a separate question again: a plugin that sends user data to an external service for its own analytics or AI features creates a disclosure path the institution may not have reviewed. Ask each party which systems it can reach, whether it can see identifiable records and where any copies are stored.
The written contract is where direct control is demonstrated, so it should not be an afterthought. Confirm that the agreement names the institution as the owner of the records, limits use to specified services, bars secondary use and onward disclosure, requires notice of any subpoena or access request, sets retention and deletion timing and gives the institution audit rights over access logs. Ask who holds administrator credentials, where backups are kept and who can approve a restore. Also confirm how the arrangement fits the institution's annual notice of directory information and its policy for school officials. The institution remains responsible for FERPA compliance, and the Department of Education can act on noncompliance under 34 CFR 99.67, so a partner's paperwork should be reviewed by counsel before the first student record is loaded.
What do schools ask before hiring a FERPA-aware LMS partner?
What drives the cost of a FERPA-scoped LMS engagement?
Cost is driven by scope, not by a license fee, because Moodle has no license cost to pay. The main components are hosting sized for your peak enrollment and exam periods, setup and theming, identity and student information system integration, role and access design, audit logging configuration, documentation of the controls, and upgrades and support after go-live. Ask any partner for a written scope that lists each component separately, states which items are one-time and which recur (hosting, upgrades, support retainers), and names which party supplies policies, role lists and legal review. DeployOpen does not publish prices; a quote follows from the agreed written scope.
How long do setup and access design take for a FERPA LMS?
Duration depends on the number of roles, the number of systems that feed or read student data, and how quickly the institution can make decisions. Access design is usually the longest step because each role needs a documented list of the education records it may see and a reason tied to a legitimate educational interest. Ask the partner for a timeline built from your role inventory and integration list, with the dependencies on your registrar, IT security and counsel marked. Be cautious of any partner who gives a fixed duration before reviewing those inputs.
What must the institution supply before a partner starts?
The institution supplies the decisions and documents that only it can make. These include a role list with the records each role needs, the FERPA annual notification and directory information policy, the data retention schedule for course and grade records, the list of outside parties that will receive student data, and the signed contract terms with the hosting or support partner. Legal counsel should review the school official designation and the redisclosure language before go-live. Ask the partner to provide a checklist of these inputs in the first week so that work does not stall on missing policy.
Can our IT staff run a FERPA-scoped Moodle themselves?
Some institutions have the skills in-house, but a FERPA-scoped deployment adds recurring work that is easy to underestimate. Staff must keep upgrades on schedule, apply security fixes, maintain role mappings, review audit logs and answer records requests within the timeframes FERPA sets. Ask yourself whether you have named owners for each of these tasks and backup coverage during exam periods. A partner can take on some or all of these tasks under a retainer, or train your team and document the procedures so that the work stays inside the institution. The split should be written into the contract.
How do Moodle 5.1 public directory and database requirements affect the work?
They add a configuration step and a platform check that should be in the scope from the start. 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. Moodle 5.1 requires 64-bit PHP 8.2 or later, with 8.3 and 8.4 supported, and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or Microsoft SQL Server 2017 or later. Sites must already be on Moodle 4.2.3 or later to upgrade. Confirm your current version and server stack against these requirements before you plan the access work, because an upgrade can change the environment that your controls depend on.
What happens if a parent or student requests access to records?
The institution must comply with a request to inspect education records within a reasonable period and not more than 45 days after receiving it (34 CFR 99.10(b)). In practice, the LMS team needs a documented process to locate grade, submission and course activity data for the student, export it in a reviewable form, and hand it to the registrar or records office. Ask the partner to show how audit logs and reports support that search, who is authorized to run it, and how the request is recorded. The institution remains responsible for the response, so the partner's role should be described in the contract.
What does a FERPA violation mean for our LMS funding?
If an institution does not comply with FERPA, the Secretary of Education may withhold further payments, issue a cease and desist complaint, or terminate eligibility to receive funding under any applicable program (34 CFR 99.67). That is why the controls around the LMS need to be documented and testable, not assumed. Ask any partner how it supports evidence of access rules, disclosure logs and contract terms for review, and make clear that DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications. Counsel should confirm how the institution's obligations apply to its own circumstances.
Does a FERPA-aware partner handle the legal interpretation?
No. A technical partner can implement access controls, logging, retention settings and contract clauses, but interpreting FERPA for your institution is a legal decision. The partner should be able to explain how the school official exception applies to a contractor, including the requirement that the institution keeps direct control over the use and maintenance of the records and that redisclosure limits are followed (34 CFR 99.31(a)(1)(i)(B)). Ask for a written statement of which decisions the institution's counsel must make and which the partner will implement, so that responsibilities are clear before the engagement begins.
Evidence auditors and FERPA reviewers ask for, and which component produces it
This table maps each piece of FERPA evidence a reviewer may request to the LMS component or process that produces it on a self-hosted Moodle or Canvas. Read each row as a question to answer before an inspection, and note that the institution decides what counts as sufficient for its own records.
| Evidence item | What it shows | Component or process that produces it |
|---|---|---|
| School official designation and contract | The hosting or support partner qualifies as a school official under the institution's direct control | Signed contract with redisclosure limits, data use terms and institution control clauses, held by the registrar or general counsel |
| Role and permission export | Which staff roles can view which student records | Moodle role assignments and capability reports, or Canvas account and role settings, exported on a schedule |
| Access review record | Periodic confirmation that only people with legitimate educational interest keep access | Dated review signed by the data owner, built from the role export and the partner's administrator account list |
| Authentication and MFA configuration | How administrators and staff sign in to the platform | Identity provider settings, such as SAML2 single sign on or LDAP, and the MFA policy applied to administrator accounts |
| Disclosure log | Each request for and disclosure of personally identifiable information, with parties and legitimate interest | Institution-maintained log, supported by platform logs for report exports, data extracts and API calls; confirm which events your version records |
| Inspection request tracking | Dates a parent or eligible student asked to inspect records and when the institution responded | Case entry in the registrar's request workflow, linked to the record export produced for the student |
| Retention and deletion settings | How long course and student data is kept and how it is removed | Written retention schedule and platform purge or deletion settings, with a dated record of each run |
| Backup and restore test | Backups exist, are protected and restore to a working state | Backup job logs and a restore test report from a separate environment, run on a dated schedule |
| Plugin and version inventory | Which third-party plugins can read student data and whether they are supported | Installed plugin list, version record and vendor data processing terms for each plugin that handles learner data |
What the LMS alone does not satisfy under FERPA
A self-hosted Moodle or Canvas can hold the right controls, but FERPA, the GLBA Safeguards Rule and COPPA also depend on contracts, staff practice and decisions the software cannot make. Each card below names a gap and the owner who has to close it.
Contract terms and redisclosure limits
A hosting or support partner can receive education records as a school official only when it performs a service the institution would otherwise use employees for, stays under the institution's direct control for the use and maintenance of the records, and follows the redisclosure limits in 34 CFR 99.33(a). The contract must state these conditions, the permitted uses, the deletion or return process at exit, and who approves access. Owner: the institution's general counsel or registrar, with procurement.
Legal classification of records
The institution, not the software, decides which LMS data are education records. Gradebooks, submissions, discussion posts, completion records and analytics about an identifiable student usually need review, while directory data and anonymized usage data may be treated differently under the institution's own policy. Document the classification for each data type, including logs and backups, so access rules and disclosure logs follow the same map. Owner: the registrar and privacy office.
Staff training and access policy
Access controls in Moodle or Canvas only work if the people assigned course roles, site administrator rights and report permissions understand which records they may see. Instructors, teaching assistants, help desk staff and vendor engineers each need a documented legitimate educational interest and a periodic review of who holds those roles. Staff also need training on handling requests from parents, students and third parties. Owner: the institution's HR, IT leadership and academic departments.
Third-party plugins and AI or video services
Plugins, LTI tools, video hosts and AI assistants can send student names, submissions or usage data to external servers, and each such flow may be a disclosure that needs an agreement and a log entry. Inventory every plugin and external service, record what data it receives, and confirm its contract terms before enabling it on production. Check Moodle's plugin types and each vendor's data handling terms rather than assuming a plugin is contained within the site. Owner: the LMS administrator with the privacy office.
GLBA Safeguards Rule for Title IV schools
Schools in the Title IV programs agreed in their Program Participation Agreement to comply with the GLBA Safeguards Rule, and the Department of Education reviews this in annual compliance audits. The rule requires a written information security program and multi-factor authentication for anyone accessing an information system, which includes the LMS and its admin consoles. It also requires FTC notification within 30 days of discovering an event affecting at least 500 consumers. Owner: the chief information security officer and the financial aid office.
COPPA duties for children under 13
If the LMS or a course on it collects personal information from children under 13, such as K-8 learners on a platform open to the public, the operator must maintain a written information security program with a designated coordinator and at least annual risk assessments. Operators must also keep a written retention policy with a deletion timeframe and cannot keep children's data indefinitely. Confirm whether the institution or a course provider is the operator before setting up accounts. Owner: the district or school privacy officer.
Which contract terms to put in place for a self-hosted Moodle or Canvas
This sequence turns FERPA's school official conditions into signed contract terms that a self-hosted Moodle or Canvas partner must meet. It ends with a written agreement that counsel has reviewed and that names who controls records, how they are protected, how disclosures are logged, and how data leaves at exit.
Confirm school official status in writing
Start by establishing whether the hosting or support partner will receive education records as a school official. Under 34 CFR 99.31(a)(1)(i)(B), the outside party must perform a service the institution would otherwise use employees for, so the contract should describe the specific services in scope, such as hosting, upgrades, plugin support or help desk work. Institutional counsel and the registrar confirm the institution's annual FERPA notification covers this category of party. The step is done when the scope and the school official designation are written into the agreement.
Define direct control over records
The institution must keep the partner under its direct control for the use and maintenance of education records. The contract should state who owns the Moodle or Canvas data, who approves access to student records, which staff at the partner may touch production databases, and how the institution can direct, suspend or review that work. Where the institution holds the cloud account or data center tenancy, the terms should say so. The step closes when a named institutional owner and an approval path for record access are documented.
Set redisclosure limits
The partner must follow the redisclosure limits in 34 CFR 99.33(a), which restrict further disclosure of personally identifiable information from education records. The contract should prohibit the partner from using student data for its own purposes, from sharing it with subcontractors or plugin vendors without written approval, and from transferring it to other parties. It should also address AI services, video providers and analytics add-ons that may receive learner data through a plugin or integration. The check is a list of approved subprocessors and a written prohibition on secondary use.
Specify access controls and multi-factor authentication
Institutions must use reasonable physical or technological methods so school officials see only the records in which they have a legitimate educational interest (34 CFR 99.31(a)(1)(ii)). The contract should map role-based access in Moodle or Canvas to these interests and require the partner to use multi-factor authentication for administrative and support accounts. Confirm the Moodle authentication method, such as SAML 2.0 single sign-on, is set in the security schedule. The step is complete when the schedule lists controls, the roles that hold them and how access reviews are performed.
State logging, retention and disclosure record duties
FERPA requires the institution to record each request for access to and each disclosure of personally identifiable information, along with the parties and their legitimate interests, for as long as the records are kept (34 CFR 99.32). The contract should require the partner to preserve audit logs of administrative access, data exports and database changes, and to deliver them on request in a usable format. Retention periods for those logs should match the institution's records schedule. The step is done when the log scope, retention period and delivery method are written down and agreed.
Set breach notice timing
Agree on how and when the partner reports a suspected or confirmed incident affecting student records. The contract should set a notice window the institution's counsel accepts, specify the content of notices, and require cooperation with forensic work and institutional communications. Where the institution is also subject to the GLBA Safeguards Rule through its Title IV obligations, align the notice terms with the 30-day FTC notification requirement in 16 CFR 314.4(j). The check is a signed incident response schedule with named contacts on both sides.
Define data return and deletion at exit
Specify what happens to student records, course content, backups and logs when the engagement ends. The contract should require export of the database, file store and course archives in documented formats, a deletion timetable that covers backups and replicas, and a written certificate of deletion. Ask the partner to confirm how it will handle a Moodle or Canvas version upgrade path if the institution changes providers. The step closes when the exit plan lists each data set, the format and the deletion evidence the institution will receive.
Agree on audit access and have counsel review
Grant the institution, or an independent assessor it appoints, the right to review security controls, access records and hosting evidence. The contract should set how often reviews happen and how findings are remediated. Before signature, institutional counsel should review the full set of terms against FERPA and state law, because the wording of school official designations and liability clauses depends on the institution's own circumstances. The step is complete when counsel has signed off and the audit rights, notice terms and exit plan are attached to the master services agreement.
How DeployOpen scopes, configures and supports a FERPA-scoped LMS
DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a FERPA-scoped Moodle or Canvas deployment, that means the record boundary, access model and contract terms are agreed in writing before the build starts, and the evidence is handed over with the system.
How we scope
- Written scope lists which LMS data sets are education records, which are directory information, and which are excluded.
- Scope names every role that touches records, from instructors and advisors to vendor administrators and support staff.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- Role-based access is configured and tested against each school official's legitimate educational interest.
- Disclosure logging, retention settings and integrations with the student information system are built and tested in a staging environment.
- Hardening covers the web server document root, database access, backups and authentication options such as SAML2 or LDAP.
How we hand over
- Documentation covers access matrices, logging configuration, retention rules and the data flow map for auditors and counsel.
- Runbooks explain how to grant, review and revoke access, and how to answer an inspection request within the required period.
- Handover includes a tested backup and restore procedure and a written upgrade plan aligned with Moodle's support windows.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers, scoped separately from the build.
- Access reviews and disclosure log checks can be run on a schedule agreed in the retainer.
- Support scope, response expectations and the upgrade calendar should be confirmed in the written agreement before signing.
