Open source ITSM for education

Open source ITSM for education starts with who can see which records

An education IT director running a service desk for students, faculty, staff, device fleets and loaner laptops can cover the ITIL processes and asset records with GLPI or iTop, both of which are open source and self-hosted. The design, however, is driven by the rules on who may see which records, not by the tool. FERPA governs education records, so the first design decision is which roles can open, view or edit a ticket that mentions a student, and how that is enforced. Under the FERPA regulations, a contractor or outside party may act as a school official only under direct institutional control, and institutions must use reasonable access controls so that school officials see only the records in which they have a legitimate educational interest (34 CFR 99.31). Where a campus also participates in Title IV programs, GLBA Safeguards obligations add multi-factor authentication and a written information security program to the same help desk.

Corporate ITSM rarely faces this combination. A university service desk serves a population that changes every term, with students who are also customers, staff who are also administrators, and a term-start surge that can overwhelm a small team. Device fleets include loaners that move between students, so asset records carry personal data as well as hardware data. Multi-campus entities add another layer, because each department or campus may need its own queues, roles and asset ownership while the central IT team keeps oversight. These factors shape the data model before any workflow is configured.

Before selecting a platform, confirm with your registrar, general counsel and security office how education records, loaner histories and self-service tickets will be classified, and which roles may see each class. Ask any implementation partner to demonstrate role-based visibility for a ticket that references a student record, and to show how access to that ticket is logged. Confirm which authentication methods your identity provider supports, since GLPI documents internal database, LDAP, IMAP and external authentication tried in that order. Those answers will decide whether GLPI, iTop or a different helpdesk is the right fit for your campus.

Which education rules change the ITSM build

This table maps the US education and consumer privacy rules most likely to reach a university or district service desk to the specific ITSM design choices they affect. Read each row as a requirement, what it means for ticket content, access, logging, retention or admin access, and where builds usually fall short.

Rule	What it means for the ITSM build	Evidence an assessor will expect	Where builds usually fail
FERPA disclosure and school official access (34 CFR 99.31)	Tickets about student accounts, grades or records make the help desk a place where education records appear. Outside contractors or hosted support staff qualify as school officials only if the institution directly controls use and maintenance of the records and they follow redisclosure limits.	Written contracts naming the contractor's school official role, documented direct control, and role-based access limiting each technician to records with a legitimate educational interest.	Support contractors get full queue access by default, and ticket attachments with transcripts or accommodation letters are shared with vendors without a documented basis.
FERPA disclosure logging (34 CFR 99.32)	Each access to or disclosure of personally identifiable information from student records must be recorded with the parties and their interests. In ITSM, this means audit history on tickets and assets that touch student data.	Retained audit trails of ticket views, edits, exports and reassignments, kept for as long as the underlying records are kept.	Ticket history is editable, exports are untracked, and audit logs roll over before the records they describe are retired.
FERPA access request timing (34 CFR 99.10)	Requests from parents or eligible students to inspect records must be met within a reasonable period and no more than 45 days. Tickets that hold those records must be findable quickly.	A search and retrieval procedure that finds all tickets and attachments linked to a student identifier.	Tickets are indexed by requester name only, so records linked to a student ID or device are missed in a request search.
FERPA enforcement exposure (34 CFR 99.67)	Failure to comply can lead to withheld federal payments, a cease and desist order or loss of funding eligibility. A weak ITSM record of access raises the cost of proving compliance after an incident.	Written FERPA procedures, staff training records and a demonstrable access review for the service desk.	The desk treats FERPA as a records office problem and does not include ticket content in privacy reviews.
GLBA Safeguards: written program and MFA (16 CFR 314.4)	Title IV institutions must maintain a written information security program and require multi-factor authentication for anyone accessing any information system. Service desk admin consoles, remote support tools and asset platforms fall under this scope.	A written program covering the ITSM platform, MFA enforcement reports for all accounts, and an inventory of systems with customer financial information.	MFA is enforced on the student portal but not on the GLPI or iTop admin console, or on accounts used by contractors and service accounts.
GLBA FTC notification (16 CFR 314.4(j))	Notification to the FTC is required within 30 days of discovering an event affecting at least 500 consumers. The ITSM record must show when discovery happened and which assets and tickets were involved.	Incident tickets with discovery timestamps, affected asset links and a documented escalation path to the institution's privacy or legal office.	Incidents are logged without timestamps for detection, or affected records are not linked to the CMDB, which slows scoping.
COPPA retention (16 CFR 312.10)	Where the institution or its operator collects personal information from children under 13, that data may be kept only as long as reasonably necessary and needs a written retention policy with a deletion timeframe. Lab device tickets, sign-in requests and K-12 portal attachments can hold such data.	A retention schedule for tickets and attachments tied to K-12 services, with a documented deletion job and a record of deletions.	Old tickets with student names and parent contact details remain indefinitely because no one owns the purge schedule.
ITSM record retention and asset data	Asset records, loaner logs and ticket histories need a retention rule that balances FERPA access needs, GLBA evidence needs and COPPA deletion limits. One schedule rarely fits every record type.	A retention matrix by record class, with legal hold support and a tested purge process.	Retention is set once at go-live and never revisited, so asset records of departed students or staff are kept or deleted by accident.
28 CFR Part 35 Subpart H web and mobile accessibility	Public entities must make web and mobile content accessible. Self-service portals, knowledge base articles and ticket forms used by students and staff fall within scope and must work with assistive technology.	An accessibility conformance review of the portal and knowledge base, with remediation tracked as tickets or change records.	Portal forms and knowledge articles are published without testing, and accessibility defects are logged as low-priority requests with no owner.

Designing self-service portals for students, staff and parents

Students usually need a short catalog: account and password help, Wi-Fi and VPN access, software licenses, loaner device requests, and report-a-problem forms for classroom technology. Their portal should show only their own tickets and should never expose other students' records, grades or disciplinary data. Authentication normally runs through the campus directory, so GLPI's documented order (internal database, then LDAP, then IMAP, then REMOTE_USER) must be set so that student accounts resolve to the right profile before any local fallback applies.

Request catalog: Keep it to high-volume items such as password resets, loaner checkout and classroom equipment faults, with plain-language titles.
Authentication order: Confirm which source authenticates students and whether a local account is ever allowed for them.
Ticket data: Record the minimum needed to resolve the request, such as device tag and course code, and avoid storing grades or health details in free text.
Knowledge base: Publish articles for the top requests and link them from the login page so students can self-resolve before opening a ticket.
Public access: The GLPI 12.0.0 knowledge base rewrite and its accessibility work matter here, but the institution must test accessibility with its own users and assistive technology.

Confirm the access rules in your own test tenant before launch, with the registrar and privacy office signing off on what students can see.

GLPI or iTop for education: which fits which campus

Universities and school districts rarely share one service desk model, so the platform choice follows how each campus owns devices, data and support. The cards below set out where GLPI and iTop fit, and how a high-volume student queue layer on Zammad or FreeScout changes the design.

GLPI for single-institution service desks

GLPI is GPL-3.0 licensed and combines tickets, assets, a CMDB, contracts and financial records in one application. For a single university or district with one IT team, it keeps device loans, licenses and helpdesk tickets in a shared data set. GLPI Agent collects inventory from Windows, macOS and Linux lab machines and staff laptops, which helps reconcile what the fleet actually contains. Check how the agent rollout will reach student-owned and shared lab devices that are not domain joined.

Step-up authentication for admin actions

GLPI 12.0.0 added step-up authentication for certain administrative actions, along with a view of active user sessions that admins can revoke. Schools often have many staff with broad rights during enrollment and examination periods, so these controls matter for limiting who can change asset records or student-linked tickets. Confirm which actions trigger step-up in your build, and how revoked sessions are logged for audit.

iTop for multi-campus data models

iTop is licensed under AGPL-3.0 and its CMDB model can be customized, which suits entities where each campus, faculty or district school has different classes of assets, service owners and contract terms. A central office can define one model and let local campuses add attributes without forking the platform. The cost is more design work up front: someone must own the data model, naming rules and change control for it. Ask a partner how the model will be versioned across campuses.

Zammad for high-volume student queues

Seasonal peaks such as enrollment, registration holds and exam periods can produce large numbers of student questions across email and web forms. Zammad is AGPL-3.0 licensed and runs as a web-based helpdesk that can sit in front of GLPI or iTop for these queues, passing only confirmed hardware, access or service requests onward. Check that student contact data is handled under your access and retention rules, and confirm how the integration will carry ticket references between the two systems.

FreeScout as a lighter queue layer

FreeScout is AGPL-3.0 licensed and suits smaller districts or departments that need shared inboxes for student and parent questions without a full helpdesk program. It is simpler to operate than a larger platform, but its reporting and integration options differ from Zammad's, so the choice depends on the volume and the reporting the district needs. Confirm the current feature set against your queue volumes before deciding, and keep the handoff to the ITSM system as an explicit step.

Handling term-start peaks and multi-campus entities

Term-start peaks should shape your SLA definitions before you configure a single queue. Enrollment, add/drop, exam periods and the first week of each semester generate spikes in password resets, account provisioning, Wi-Fi and learning platform access tickets, and loaner device requests. Define a separate priority matrix for peak windows, with explicit response and resolution targets for access-blocking incidents, and agree in writing which services remain at normal targets. In GLPI 12.0.0, group-managed OLAs let you attach operational level agreements to a support group instead of to individual technicians, so a central identity team or a campus-level field team can carry its own commitments. Confirm in your own test instance how OLA calendars handle holidays and campus closures before you rely on them for reporting.

Multi-campus and district structures need a deliberate entity model in the CMDB. In GLPI, use entities to separate campuses or schools, and decide early whether shared assets such as a district licensing server or a central identity service sit in a parent entity with child-level visibility. In iTop, model sites and organizations as objects and link configuration items to them. Delegated administration per site should let a campus technician manage tickets and assets for their own entity without seeing other campuses' student records or device assignments. Keep one shared service catalog so students and staff see the same request names everywhere, with campus-specific approvers and fulfillment groups. Cross-campus reporting depends on consistent categories and status values, so agree those first. Before committing to either platform, confirm with the vendor how entity-scoped roles interact with your identity provider groups, whether SLA calendars can differ per entity, whether dashboards can aggregate across entities without exposing restricted fields, and how loaner device records are linked to borrowers under your FERPA access controls.

Rolling out ITSM across a campus in phases

This sequence moves a campus from scoping to a live service desk in controlled stages, so each phase produces evidence the next one depends on. It keeps student records, device data and loaner tracking under review before any ticket or asset migrates.

Scope FERPA and GLBA data in tickets
Work with the registrar, general counsel, financial aid office and the IT security lead to list which ticket fields, attachments, asset records and portal forms could hold education records or financial aid data. Confirm which staff act as school officials and which contractors would have access, since FERPA's school official conditions (34 CFR 99.31) apply to any outside party. Done when the team signs a scoped data map showing each data class, where it appears in the service desk and who may see it.
Select the platform and design hosting
Compare GLPI and iTop against the requirements in the data map, including ticket and asset models, CMDB depth, multi-campus support and reporting needs. Decide where the platform runs, how it is segmented from student-facing networks and which database and web server the chosen version supports. Confirm the license, support model and upgrade path with the vendor and the implementation partner. Done when an architecture decision record is approved and the hosting design is documented.
Configure identity and self-service portals
Connect staff and student authentication to the campus directory, and test the authentication order the platform uses for internal accounts, LDAP and mail-based logins. Build separate self-service catalogs for students, faculty and staff so each group sees only the requests it needs. Enable multi-factor authentication for every administrator and any account that reaches financial or student data, which the GLBA Safeguards Rule requires for anyone accessing an information system. Done when test accounts from each group complete their requests and access reviews confirm that no role can see records outside its scope.
Build the asset inventory and migrate loaners
Deploy inventory agents to managed laptops and lab machines, and run network discovery for devices that cannot take an agent. Import loaner records from the existing spreadsheet or loan system, then reconcile serial numbers, assigned borrowers and return dates against physical counts. Record the loan process as a request type with checkout and return steps so loans leave an audit trail. Done when a reconciled inventory report matches the physical count for each loaner pool and the team signs off the migrated records.
Run a pilot in one department
Choose one department with a clear owner and a manageable device count, then run the new catalog, approvals and loaner process with real users for a limited period before the term starts. Track ticket categories, misrouted requests, approval delays and any data that appears in ticket text that the data map did not expect. Adjust forms and access rules based on what the pilot shows. Done when the pilot owner accepts the results in writing and the defects list is closed or scheduled.
Test backup and restore before cutover
Perform a full backup of the database, files and configuration keys, following the platform's documented update and backup procedure. Restore that backup into a separate environment and confirm that tickets, assets, attachments and user access all return correctly. Record the restore time and any manual steps so the runbook reflects reality. Done when a tested backup and restore report is filed with the change records.
Cut over outside peak periods
Agree a change calendar with the registrar, housing, financial aid and help desk leads so the migration avoids registration, add-drop, grading, financial aid disbursement and the first weeks of term. Freeze changes to the platform during cutover, migrate tickets and assets in a tested order, and keep the legacy system read-only for a defined fallback window. Confirm the cutover in the change record with approvals, test results and back-out steps. Done when the change calendar shows the approved window and the cutover checklist is signed.
Hold post-go-live reviews
Review ticket volumes, first response and resolution data, self-service adoption, loaner return rates and access review results at scheduled intervals after go-live. Check the data map again against new ticket fields and integrations, and confirm that retention rules for tickets and loan records match the institution's records schedule. Feed findings into a prioritized backlog and the next peak-period plan. Done when each review produces a dated action list with named owners.

Evidence auditors and federal reviewers ask education IT for

This table maps each evidence item a university or school district is likely to be asked for to the part of the GLPI or iTop deployment that produces it. Read it as a checklist for design decisions made before go-live, since most gaps appear when logging, retention or history settings were left at defaults. DeployOpen prepares this evidence, but independent auditors and reviewers decide whether it is sufficient.

Evidence item	Produced by	What the reviewer checks	Where it usually fails
Ticket history and access records	GLPI or iTop ticket and event logs, with user and timestamp per action	Who viewed or changed a student-related ticket, and whether access matched a legitimate educational interest	Shared service desk accounts hide the individual who acted, and view events are not logged
Record of disclosures (FERPA 99.32 style)	Ticket fields and log entries for requests and releases of student personally identifiable information, with recipient and reason	Each disclosure is recorded with the party and legitimate interest, kept as long as the records are kept	Staff email or chat outside the ticket system carries student details that never reach the record
Admin session and step-up authentication records	GLPI session view and step-up checks for sensitive admin actions, plus directory or SSO login logs	Privileged changes were made by named administrators under stronger authentication	Local super-admin accounts used by several technicians, or directory logs not retained long enough to match
Asset inventory with assignment history	GLPI Agent inventory plus assignment and location history on loaner and fleet devices	Each laptop or tablet can be traced to the student or staff member it was assigned to and when it was returned	Loaner returns are logged late or not at all, and inventory data is overwritten by re-imaging
Retention and deletion settings tied to a written policy	Configured purge and archive rules in the ticket and asset tables, documented in the retention policy	Records of minors under 13 are deleted within the timeframe the written policy states, and the policy is current	Retention rules were never configured, backups keep data indefinitely, or no owner reviews the policy
Platform change records	Change tickets for upgrades, plugin changes and configuration edits, with approval and back-out notes	Each GLPI or iTop release, plugin change and database update was approved, tested and reversible	Upgrades run without tickets, and plugins are reactivated after updates without a recorded check

What do schools and universities ask before deploying self-hosted ITSM?

What drives the total cost of self-hosted ITSM for a school district or university?

The cost is driven by scope, data migration, agent rollout, administration effort and the support tier you choose, not by the software licence, which is free under GPL-3.0 for GLPI. Costs fall into one-time work (process design, CMDB modeling, migration, integrations, training) and recurring work (hosting, backups, upgrades, staff time and any support subscription). The number of campuses, the number of devices in the loaner fleet and the number of ticket channels move the price most. For a reference point only, the GLPI Network subscriptions page lists self-hosted plans from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise), and a managed public cloud at 19 euros per user per month. Ask any partner for a written quote that separates one-time and recurring items and states which support level it includes.

How long does an ITSM rollout take in a multi-campus school or university?

No fixed duration applies to every institution, because the timeline follows scope, data quality and the number of sites. The main variables are how clean the existing asset and user data is, how many campuses or districts must be onboarded in phases, whether the rollout includes the loaner fleet and how many integrations (identity, mail, monitoring, procurement) must be built. Plan a pilot campus or a single school before the seasonal peak, such as the start of term or enrollment periods, because cutting over during a ticket surge adds risk. Ask a partner to show the phases, the entry and exit criteria for each and the dependencies on your identity team and your data owners before agreeing on dates.

What must our IT team provide before a partner starts the ITSM project?

Your team supplies access, decisions and data. Typical inputs include the identity source (directory and how students, staff and contractors are grouped), a hosting target inside your own network or cloud account, mail and monitoring details for notifications and alerts, an inventory export from existing spreadsheets or procurement systems, and a list of device and loaner categories. You also need named owners for service catalog approvals, the data owner who approves what fields are stored about students and the person accountable for backups and the upgrade calendar. Confirm these items in the written scope, since missing access or unclear approvers are the most common reasons a rollout slips.

Can a small school IT team run a self-hosted GLPI or iTop instance alone?

A small team can run it alone if it has someone comfortable with Linux, a web server, a database and scheduled backups, and if the process design is kept simple. GLPI requires PHP 8.3 or later and MariaDB 10.11 or later, or MySQL 8.0 or later, according to its README, so the team must patch the stack and keep it supported. Daily work such as ticket triage, asset check-in and checkout for loaners, and password resets is within reach of staff with basic admin training. Where the team lacks time or depth, a partner can take on hardening, upgrades, monitoring of the platform and documented runbooks under a retainer, while your staff keep ownership of the data and approvals.

How does FERPA affect which staff can see student-related tickets?

FERPA limits who can see personally identifiable information from education records, so the ticketing design must restrict access by legitimate educational interest. Under 34 CFR 99.31(a)(1)(ii), an institution must use reasonable methods, such as technological access controls, so school officials see only the records they need. In GLPI this usually means separate entities or profiles, restricted ticket visibility, and not attaching grades, disciplinary notes or health details to tickets. An outside contractor may receive records as a school official only under the conditions in 34 CFR 99.31(a)(1)(i)(B), which means a contract with direct institutional control. Ask counsel to review the field list, the visibility rules and the disclosure log requirement in 34 CFR 99.32 before go-live.

How is a GLPI upgrade handled, including plugin reactivation after a major release?

Treat every GLPI upgrade as a planned change with a rollback path. The installation documentation requires you to back up the database, the application files and the config directory, including the glpi.key and glpicrypt.key files, before replacing the application files and running php bin/console db:update. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after a major update, so test each plugin on a staging copy first. GLPI 12.0.0 was released on October 7, 2026, and its release notes describe a rewritten knowledge base and step-up authentication for certain admin actions, which should be tested with your identity setup. Ask your partner for a written upgrade runbook and a staging environment before the first upgrade.

Which parts of a school ITSM deployment carry the most ongoing risk?

The highest ongoing risks are unmanaged access to student data, undocumented integrations and unplanned upgrades. Access risk grows when ticket visibility is broad, when attachments contain sensitive records or when former staff keep profiles. Integration risk appears when directory sync, mail notifications or procurement imports break silently after a change. Upgrade risk rises when plugins are not tested after a major release. Mitigate these with a periodic access review, a documented field list, monitored sync jobs and a patch calendar. Where the institution also falls under other rules, such as the Safeguards Rule for institutions in Title IV programs, check that the same controls can produce evidence on request.

Questions to ask an ITSM implementation partner for a school or university

Start with scope, because the answers drive everything else. Ask the partner which parts of your service desk touch education records under FERPA (34 CFR Part 99) and which touch financial aid data covered by the GLBA Safeguards Rule (16 CFR Part 314). Ask how they classify a ticket that contains a grade dispute, an accommodation request or a loaner laptop tied to a student, and whether they will document that classification in the design. Ask who on their team has worked through the school official conditions in FERPA's regulations, and what they will hand you in writing: a data inventory of ticket fields, a list of who can read each one, and a list of any external parties with access. If a partner cannot name the Title IV or COPPA exposure in your environment, expect surprises during your next audit.

Next, test how the partner treats its own people and terms. A contractor can receive education records as a school official only under direct institutional control and with redisclosure limits, so ask for the draft contract language before any build begins. Ask how their engineers get access to the production GLPI database, who approves that access, and whether support sessions are logged and reviewed. For role and campus separation, ask them to demonstrate how GLPI entities and profiles restrict a campus technician from seeing another campus's tickets, assets and users, and how they will test that restriction. Ask how they will document access for each request, because FERPA expects a record of disclosures kept for as long as the records exist.

Finally, press on operations: upgrades, backups, peaks and support. Ask for the exact backup set they will take before any GLPI upgrade, and confirm that it includes the database, the application files and the config directory with glpi.key and glpicrypt.key, since losing either key can make stored credentials unreadable. Ask how they will handle the plugin suspension that GLPI 11.0 applies after a new version is detected, and who reactivates plugins after a major update. Ask for a written definition of what the support subscription covers, including whether it is the GLPI Network subscription, the level of support, response expectations in writing, and whether it applies to your self-hosted instance or only to vendor software. Ask how they will size capacity for registration week and exam periods, and which loaner and device fields they will minimize and delete on a defined schedule.

Open source ITSM for education