Why GLPI for schools and universities starts with campus structure
An education IT team usually runs several campuses, schools or departments through one service desk, with loaned laptops, shared classroom devices and some student-owned hardware on the same inventory. GLPI fits this as a single platform for tickets, assets and the self-service portal, but its value depends on how the instance is divided before any ticket is logged. The entity tree is the decision that shapes the build most. Each campus or school can be modeled as an entity, so that asset records, tickets, users and rules sit in the right place and staff at one site see only what belongs to them. Decide the entity hierarchy early, because moving assets and tickets between entities later is far more work than setting the structure up front.
Loaner devices need a reservation model that matches how the school actually lends equipment. In GLPI, the checkout and return workflow is driven by the asset records, their status and the users attached to them, so the team has to decide which asset states mean available, loaned, in repair or retired, and who is allowed to change each one. Student-owned hardware raises a different question: whether it belongs in the inventory at all, and if so, under which entity and with what retention. The access model matters just as much. Profiles and entity-based visibility control which staff can open or read records about students, and the authentication source determines who gets an account in the first place. Confirm with your data protection officer and counsel which student-related fields the service desk may hold, since FERPA and related rules set limits on who may see education records. Those limits, not the software defaults, should drive the profile and entity design.
Which education requirements shape the GLPI build
This table maps the federal education and child privacy rules most likely to reach a school or university IT inventory to specific GLPI settings: entities, profiles, retention and sign-in. Read each row as a design question to settle before the build, then confirm the applicability of each rule with your counsel and compliance lead. The main takeaway is that the rules mostly constrain who can see which records, how access is evidenced, and how long data is kept.
| Requirement | What it asks for | What it means in GLPI |
|---|---|---|
| FERPA school official (34 CFR 99.31(a)(1)(i)(B)) | An outside contractor may receive education records only if it performs a service staff would otherwise do, stays under the institution's direct control, and follows redisclosure limits. | Give any partner or contractor a named profile limited to the entities they support, and document the direct control arrangement in the service contract. |
| Legitimate educational interest (34 CFR 99.31(a)(1)(ii)) | Institutions must use reasonable access controls so school officials see only records in which they have a legitimate educational interest. | Map each campus or department to its own entity, and use profiles and authorization rules so staff see only assets and tickets in their entities. |
| Access and disclosure records (34 CFR 99.32) | Record each request for and disclosure of personally identifiable information, with the parties and their interests, for as long as the records are kept. | Confirm which GLPI logs capture who viewed or exported student-linked records, and set a retention period for those logs that matches the records they describe. |
| Inspection requests (34 CFR 99.10(b)) | Comply with a parent's or eligible student's request to inspect records within a reasonable period, and not more than 45 days. | Keep student device and loan records findable by device owner and entity so the institution can respond within the deadline. |
| Safeguards Rule via Title IV agreements (16 CFR Part 314) | A written information security program and multi-factor authentication for anyone accessing any information system. | Enforce two-factor authentication for all GLPI accounts, including technicians and contractors, and document the policy in the security program. |
| Safeguards Rule notification (16 CFR 314.4(j)) | Notify the FTC within 30 days of discovering an event affecting at least 500 consumers. | Confirm that GLPI logs and asset records can be exported quickly enough to support the notification timeline your incident process sets. |
| COPPA retention limit for under-13 data (16 CFR 312.10) | Keep children's personal information only as long as reasonably necessary, under a written retention policy with a deletion timeframe. | Where student device records hold data about children under 13, set a documented deletion timeframe and confirm GLPI purge or anonymization steps before go-live. |
Which GLPI modules and settings matter on campus
Entities are the main structural decision on a campus. Each campus, faculty, residence hall or administrative unit can be modeled as an entity so that tickets, assets and users stay in the right scope. Profiles then decide what each IT staff member can do inside those entities. A central infrastructure team usually needs broad rights, while a campus technician should see and change only the assets and tickets of their own site. Decide the entity tree before importing data, because moving records between entities later is slower and easier to get wrong.
- Campus as top-level entity: Model each campus or site first, then add faculties or buildings beneath it only where the team needs separate reporting or rights.
- Profiles per role: Separate helpdesk agents, asset managers, read-only auditors and administrators so rights follow job duties.
- Recursive visibility: Confirm whether a parent entity should see child entity records, since this is the setting that most often exposes data across campuses.
- Naming discipline: Use stable entity names and codes so that imports, reports and authorization rules remain readable after staff turnover.
- Pilot the tree: Test one campus with two or three real staff profiles before rolling the model out to the others.
Confirm with your own IT leadership which staff can see records across campuses, and document that decision before the first import.
Loaner laptops, tablets and calculators are tracked as assets that move between borrowers. The configuration question is how a loan starts, how the device is checked out and returned, and who sees the device's status while it is away. GLPI's asset records can hold the current holder and location, while ticketing and approval features can route requests. The exact reservation behavior depends on the modules and plugins you select, so confirm the loan workflow against the version you deploy before promising it to staff or students.
- Asset status model: Define states such as available, reserved, on loan, under repair and retired, and keep the list short enough that front-desk staff use it consistently.
- Request path: Decide whether borrowers request through the portal, through a form or by email, and whether each request creates a ticket for audit trail.
- Approval steps: Set who approves loans for staff devices versus student devices, and record the approver on the request.
- Return and damage handling: Create a standard follow-up ticket for late returns or damage so that repair history stays attached to the asset.
- Consent for student borrowers: Ensure the loan form only collects the personal details the school needs to recover the device.
Ask your vendor or partner to demonstrate a complete loan cycle on a test instance, including a late return and a damaged device.
Student and campus-owned computers are usually inventoried with GLPI Agent, which collects hardware and software details and sends them to GLPI. The agent also supports network discovery and inventory, which helps when devices appear on networks that are not managed by a central deployment tool. Import rules then decide how incoming records are matched to existing assets, assigned to entities and linked to users. Devices owned by students and devices owned by the school should be handled differently, because the data collected and the retention expectations differ.
- Agent deployment: GLPI Agent runs on Windows, macOS and Linux, so confirm which operating systems your fleet uses before planning the rollout.
- Matching rules: Configure import rules so that a device reinstalled or renamed is matched to its existing record rather than duplicated.
- Owner classification: Separate school-owned and personally owned devices with a field or entity so that reports and retention rules can treat them differently.
- Software scope: Limit collected software data to what the school needs for licensing and security, and document that scope.
- Successor agent: GLPI Agent is the successor of FusionInventory Agent, so check any older deployments still reporting through the previous agent.
Verify with a sample of devices that the inventory fields match what technicians see on the physical machine.
GLPI checks user credentials against sources in a fixed order: the internal database, then LDAP directories, then IMAP mail servers, then other external methods such as REMOTE_USER. This order matters on campus because a student or staff account that exists in more than one source will be authenticated by the first source that accepts it. Single sign-on fits at the external method stage, where a web server or identity layer passes the authenticated username to GLPI. Staff and students use the same portal, so the self-service pages should show each group only the forms and tickets that apply to them.
- Source order: Plan which users live in the local database, which come from the directory and which are external, and avoid duplicate accounts across sources.
- Local accounts: Limit database accounts to emergency or service accounts, and document who holds them.
- REMOTE_USER and SSO: Confirm with your identity team how the web server or identity provider passes the username and whether group data reaches GLPI.
- Portal visibility: Use profiles and entities to show students a catalog of loan and support requests, and show staff a broader catalog.
- Session and access review: Check which accounts can reach administrative pages, since the GLPI 12.0.0 release notes describe session viewing and step-up authentication for some administrative actions.
Confirm the authentication order and the single sign-on path in a test environment before students log in to the production portal.
How loaner reservations and student device records fit together
The first decision is which records describe what the institution owns and which describe what a student or staff member holds at a given moment. Keep institution-owned hardware as assets with a stable owner entity, such as the campus or department entity that carries the budget. Model each loaner as the same kind of asset, then record the current holder through the assignment on the asset rather than by editing its owner. Ownership and custody should never share a field, because a loaned laptop still belongs to the institution while it sits in a student's backpack. Before you build, confirm in your GLPI version how assignment history is retained on an asset, since that history is what answers audit questions later. The exact reservation behavior depends on your version and any reservation or plugin features you add, so test it on a copy first.
Returns and overdue items need a defined event and a defined owner. In a typical design (illustrative), checkout creates a ticket or follow-up linked to the asset, and a return closes it. Overdue status should come from a date rule that a scheduled task or notification can evaluate, not from someone remembering to check a spreadsheet. Agree in advance who may mark a device lost, who approves a write-off, and which entity's staff can see the open loan. Confirm how your version's notification and automatic actions behave for overdue reminders, and whether reminders reach students through email you control.
Student device records should hold only what the institution needs to recover, account for, or support a loaned device. A serial number, asset tag, model, assignment dates and a reference to the student account usually suffice. Hardware inventory agents can collect far more, including installed software, logged-in users and network data, so decide per device class whether an agent runs on loaner machines and what it reports. Limit who sees personal fields through profiles and entity restrictions, and set a retention and deletion step for returned devices. Because FERPA access and disclosure rules apply to records that identify students, have your compliance lead confirm the data elements and access roles against the 34 CFR Part 99 regulations before go-live.
Which compliance duties education teams must plan for
Education teams running GLPI often hold student and staff records that fall under several regimes at once. The duties below decide what GLPI must log, who may touch it, how long data stays, and how quickly incidents must be reported. Confirm with your counsel which of them apply to your institution before the design is fixed.
FERPA access logging
Under 34 CFR 99.32, an institution must record each request for access to and each disclosure of personally identifiable information from education records, along with the parties involved and their legitimate interests, for as long as the records are kept. In GLPI, device assignments and tickets that name students need an audit trail that can answer who viewed or changed them. Check whether your GLPI logs and notifications retain that detail, and where they are kept.
Inspection requests within 45 days
An institution must comply with a parent's or eligible student's request to inspect education records within a reasonable period and not more than 45 days after receiving it (34 CFR 99.10(b)). Tickets, asset assignments and loaner histories about a student may all count. Plan a search method across entities and item types so staff can locate every record for one student inside that window.
Contractor school official conditions
An outside party such as a DeployOpen engagement or a managed GLPI provider may receive education records as a school official only if it performs a service the institution would otherwise use employees for, stays under the institution's direct control for use and maintenance of the records, and follows redisclosure limits (34 CFR 99.31(a)(1)(i)(B)). Put these conditions into the service agreement and restrict vendor accounts to the entities they support.
Entity-level access controls
Institutions must use reasonable access controls so school officials see only the education records in which they have a legitimate educational interest (34 CFR 99.31(a)(1)(ii)). GLPI entities, profiles and authorization rules map to campuses, departments and roles. Test them with a non-administrative account for a teacher, a registrar and a contractor, and record the results as evidence.
GLBA multi-factor authentication and FTC notice
Institutions in the Title IV programs agree to follow the GLBA Safeguards Rule, which requires a written information security program, multi-factor authentication for anyone accessing any information system, and FTC notification within 30 days of discovering a notification event affecting at least 500 consumers (16 CFR 314.4). Confirm GLPI's second factor for administrators and staff, and document who runs the 30-day notification decision.
COPPA retention and risk assessment
Where an operator collects personal information from children under 13, the COPPA Rule requires a written information security program with a designated coordinator, at least annual risk assessments, and a written retention policy with a deletion timeframe (16 CFR 312.8 and 312.10). For K-8 device loans or student accounts in GLPI, set retention periods for user records and purge exports, and schedule the annual assessment as a recurring task.
NIS2 and GDPR scope
Where the institution is established in the EU or processes personal data of people there, GDPR governs lawful processing, retention and data subject requests. NIS2 may apply to certain education entities depending on national transposition and sector rules. Establish with counsel whether either applies, then map the GLPI data fields, retention rules and incident reporting paths to those obligations before go-live.
How a campus GLPI rollout is sequenced
The sequence moves from agreeing scope and data classes to a working pilot, then to full agent rollout, migration and a handover that leaves the campus able to back up and upgrade GLPI itself. Each phase closes with a check the campus can verify before the next one starts.
Scope entities and data classes
Before any installation, the campus and DeployOpen agree which campuses, faculties, departments and service units become GLPI entities, and which data classes will be stored: staff records, student device loans, asset assignments and tickets that may mention students. Each data class is mapped to the people who may view it and to the legal basis your records office confirms, including whether FERPA, COPPA for pupils under 13, or GLBA Safeguards obligations apply to your institution. The output is a signed scope document listing entities, profiles, retained data classes and the retention questions still open for your legal team.
Install on a supported stack behind the public directory
DeployOpen builds the server on a PHP and database combination that the GLPI installation docs list for your target release, using MySQL or MariaDB, since those are the only databases the docs support. The web server document root points to GLPI's public directory rather than the installation root, with URL rewriting routing requests through index.php on Apache, Nginx, lighttpd or IIS. Session and encryption keys are generated and stored in a location your team controls. Done means the installer completes, the login page loads over TLS, and no application files are reachable from the web root outside the public directory.
Configure authentication and entities
The campus connects its directory for staff and student sign-in and sets the authentication order, which GLPI's user documentation describes as internal database, LDAP, IMAP and then external methods such as REMOTE_USER. Entities are created per campus, and profiles and authorization rules are tested so a campus administrator sees only their own assets and tickets. Test accounts from each campus and from the central IT team confirm the boundaries. Done means each test account sees only the entities it should, and an account from outside the directory cannot sign in.
Pilot with one campus
One campus runs for a limited set of users with real loan reservations, device records and self-service requests, while the rest of the institution keeps its existing process. The pilot tests the entity model, the loan workflow, the self-service portal, notifications and the ticket categories the help desk will use. DeployOpen records every change the pilot forces on the design so the wider rollout does not repeat it. Done means the pilot campus' help desk and loans staff sign off on the workflows, and the agreed fixes are closed or scheduled.
Roll out GLPI Agent to devices
GLPI Agent is deployed to managed Windows, macOS and Linux devices to collect hardware and software inventory and send it to GLPI, and the campus decides where network discovery and package deployment apply. Deployment uses the campus' existing software distribution tooling, with the agent configured to report to the production server only. Student-owned devices are handled under a written policy, since inventory of personal devices raises separate privacy questions. Done means inventory from each device group appears in the correct entity, and the campus has a list of devices that did not report and why.
Migrate existing records
Existing asset lists, loan logs and contacts from spreadsheets or a legacy system are cleaned, mapped to GLPI item types and imported into the matching entities. Each import is run first against a copy, reviewed by the owning campus, and only then loaded into production. Migrated student-related records are limited to the fields the loan and inventory processes need, and the campus confirms how old records will be retained or removed. Done means reconciliation counts match the source for each campus, and sample records were checked by a campus data owner.
Hand over backups and the upgrade plan
DeployOpen hands over a written backup procedure covering the database, the files and the config directory, including glpi.key and glpicrypt.key, and a restore test that the campus runs itself. The upgrade plan covers the move to GLPI 11 and then GLPI 12, including the rule that plugins are suspended after a new version is detected and must be reactivated after major updates, and the update steps from the installation docs. Done means the campus has completed one restore into a test environment and has a dated upgrade plan agreed with its change board.
What education IT teams ask before hiring a GLPI partner
What drives the cost of a GLPI deployment for a school or university?
The cost follows the written scope, and the main drivers are the number of entities (one per campus, faculty or loaner pool), the data sources to connect, the volume of records to migrate and the compliance controls to evidence. Hosting is a separate cost. The one-time work covers design, configuration, integrations and migration, while recurring costs cover hosting, backups, upgrades and support. For a subscription comparison, the GLPI Network subscriptions page lists public cloud at 19 euros per user per month, private cloud at 21 euros per user per month with a 25-user minimum, and self-hosted Basic at 100 euros per month for up to 10 agents and 500 assets. Ask any partner to price each driver separately so you can see how a larger campus changes the total.
How long does a GLPI rollout take for a multi-campus institution?
Duration depends on the number of campuses, how many directories and student systems feed GLPI, how clean the existing asset spreadsheets are and how many approval steps your governance requires. Most of the time usually goes to data cleanup and to agreeing entity and profile design, not to installing the software. Ask for a phased plan that separates a pilot campus from the full rollout, and ask which phases depend on your decisions, such as retention periods or who approves loaner reservations. No duration is promised here; the written scope should state the timeline for each phase.
What must our institution provide before a partner starts?
The partner will depend on your people more than on any tool. Expect to provide directory access for LDAP or Active Directory, named data owners for students, staff and devices, a list of campuses and departments that will become GLPI entities, and a sign-off process for retention rules. Legal or the data protection office should confirm how student records are handled under 34 CFR Part 99, because FERPA restricts who can see education records. Without these inputs, the design phase stalls, so confirm them in the quote rather than assuming they are included.
Can campus staff run GLPI themselves after the rollout?
Yes, many campuses run GLPI with a small internal team, but that team needs skills in the web server, PHP and database layer, plus a repeatable process for upgrades and backups. The GLPI update procedure requires backing up the database, files and the config directory including glpi.key and glpicrypt.key, then running php bin/console db:update, and since GLPI 11.0 plugins are suspended after a new version is detected and must be reactivated after major updates. Decide early which tasks stay with your staff (helpdesk configuration, asset imports, reports) and which need a partner (upgrades, plugin migrations, hardening reviews).
How do GLPI entities keep campus data separated?
GLPI entities let you split tickets, assets and reports per campus or department, and profiles and authorization rules decide what each person can see. This matters for schools because a loaner pool at one campus should not expose student device records to staff at another. Test the design with real roles before go-live, including helpdesk agents, campus technicians and read-only auditors. Ask the partner how entity boundaries are verified, and whether they document the access model for your data protection office.
What compliance scope applies to student device and loaner data in GLPI?
Scope depends on where you operate and which funding you receive. FERPA applies to institutions receiving funds under a program administered by the US Secretary of Education, and an outside contractor can receive education records only under the school official conditions in 34 CFR 99.31. If you participate in Title IV aid, the GLBA Safeguards Rule requires multi-factor authentication for anyone accessing an information system. Where children under 13 use school-provided devices, COPPA obligations may apply. Ask your counsel to define scope first, then ask the partner to show which GLPI controls produce the evidence. DeployOpen prepares systems and evidence for assessments but does not issue audit reports or certifications.
What should we check before choosing a GLPI partner for a school?
Check four things in the written proposal: the fixed scope of entities, data sources, migration volume and integrations; the GLPI version and upgrade path, since GLPI 12.0.0 was released on October 7, 2026 and GLPI 11 is the earlier line; the handover plan for your staff; and the retention and deletion rules agreed with your data owners. Ask how the partner handles backups, secrets and access to your directory. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted GLPI inside your own infrastructure, and most engagements are fixed-scope with agreed deliverables and timelines. Ongoing support is available as a retainer.
What to ask a partner before you sign a GLPI scope
The fastest way to tell a fixed-scope education build from an open-ended one is to ask how the partner will prove that entities and profiles work before go-live. Ask for the test matrix in writing: which entities (one per campus, faculty or department) are created, which profiles each role receives, and which records each test user must see and must not see. A credible answer names specific test accounts such as a campus technician, a central IT administrator, a loaner desk operator and a student, and states that each account is checked against ticket visibility, asset visibility and reservation rights. Ask whether the test results will be delivered as evidence, since this is what your FERPA access review will need later.
Next, ask how student data retention will be configured and who decides the period. A partner should be able to show where retention rules apply to tickets, asset history, loaner reservations and user records in GLPI, and which automatic actions or manual procedures remove or anonymize them. Because FERPA requires a record of each access request and disclosure, ask how that log is kept and for how long. Confirm the retention period with your registrar and legal counsel before the build, not after it. Ask also for the backup and restore test: the partner should restore the database, files and the glpi.key and glpicrypt.key files to a separate environment and confirm that logins, encrypted fields and attachments work there.
Finally, ask how plugin reactivation after updates is handled. Under the GLPI update procedure, plugins are suspended when a new version is detected and must be reactivated after major updates, so the partner's runbook should list every plugin, its owner, its compatibility check and the order in which it is re-enabled. On FERPA-related access decisions, ask the partner to name who approves them: the partner may configure access, but the institution's school official or records officer should sign off on who may see student-linked records. Put that approver, and the review cadence, into the written scope.
How DeployOpen works on this
DeployOpen plans, implements, customizes, hardens, documents and supports GLPI inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network. For schools and universities, the work starts with campus structure, data protection obligations and the services each user group needs.
How we scope
- Map campuses, departments and user groups to GLPI entities and profiles before any build starts.
- Record which student, staff and device data GLPI will hold, and which regulations apply to each category.
- Agree the written scope, deliverables and timeline in writing, since most engagements are fixed-scope.
How we build
- Configure entities, authentication order and loaner reservation workflows against your agreed design.
- Set up GLPI Agent deployment for student and staff devices, and test inventory results on sample machines.
- Test the self-service portal with staff and student test accounts, including access limits between campuses.
How we hand over
- Document the entity model, access rules, retention settings and backup procedure in a form your team can maintain.
- Run a walkthrough with helpdesk staff, asset managers and the administrators who will own the platform.
- Provide an upgrade runbook covering the GLPI 11 and 12 path, including plugin reactivation after major updates.
How we support
- Offer ongoing support, upgrades and testing as a retainer if your team wants continued help after handover.
- Confirm with your data protection office how deletion requests for student device records will be handled.
- Review the platform before each major version change so plugins, agents and access rules keep working.
