How GLPI fits a hospital IT service desk
A hospital IT or security lead usually runs several sites, clinical and administrative systems, and a service desk that cannot close at night. GLPI covers tickets, assets and CMDB records in one platform, so a request from a ward, a theatre or a back-office team lands in the same queue as the device, software and contract records it refers to. GLPI is an open-source IT service management platform that also handles contracts and financial management, distributed under the GNU General Public License version 3, so the same record set can answer both the helpdesk question and the inventory question. For a multi-site hospital, the practical starting point is the asset inventory. GLPI Agent collects hardware and software inventory and sends it to GLPI, and it runs on Windows, macOS and Linux, which helps when workstations, servers and specialist devices are managed by different teams. Your team should confirm early which device classes the agent can reach, which ones need manual records, and who owns the data for equipment that clinical engineering manages rather than IT.
Self-hosting changes who controls that record set. The database, the uploaded files and the glpi.key and glpicrypt.key files stay in your data centers or cloud accounts, which matters when inventory, ticket text and user details describe clinical environments. Before go-live, confirm the supported database versions for your target release, choose the web server layout described in the installation docs, and plan how you will back up the encryption keys together with the database. Those decisions determine whether the service desk can be restored after an incident, so they belong in the design phase rather than after launch.
Healthcare requirements and what they mean for the GLPI build
This table maps each healthcare requirement to its source and to the consequence it has for a GLPI build. Read it as a scoping checklist: the first decision is whether GLPI records touch electronic protected health information, because that choice sets the controls the rest of the build must meet. The main takeaway is that most GLPI data is outside HIPAA scope until asset or ticket records link to patients or clinical systems.
| Requirement | What it asks for | Build consequence for GLPI |
|---|---|---|
| HIPAA Security Rule scope | Applies to covered entities and business associates for all ePHI they create, receive, maintain or transmit (45 CFR 164.302) | Decide early whether GLPI holds ePHI. Asset records alone may fall outside scope; tickets that describe patients or clinical systems may bring it in. |
| Implementation specifications | 18 standards with 36 implementation specifications: 14 required and 22 addressable (Appendix A to Subpart C) | Map each GLPI control to a specification and record why any addressable item is adopted, modified or not applied. |
| Technical safeguards | Five standards in 45 CFR 164.312 with 7 implementation specifications, including unique user identification and automatic logoff | Give every GLPI user a named account, set session timeouts and enforce encryption for data in transit and at rest. |
| Business associate contract | Requires the associate to follow the Security Rule, flow terms to subcontractors and report security incidents (45 CFR 164.314(a)(2)(i)) | If a partner hosts or supports GLPI and can reach ePHI, the contract must cover GLPI operations, hosting and incident reporting. |
| GDPR Articles 32 and 34 | Security of processing and notice of personal data breaches, shown by the CNIL fine of EUR 500,000 on 3 September 2026 | Require VPN and multi-factor authentication for remote access and limit GLPI profiles to what each team needs to know. |
| NIS2 Annex I health sector | Lists healthcare providers and medical device manufacturers among high-criticality sectors (Directive (EU) 2022/2555) | EU organizations should confirm whether their entity is in scope and whether GLPI supports the incident handling and asset records that follow. |
| Planned HIPAA Security Rule revision | Proposed on 6 January 2025 (90 FR 898); no final rule as of October 2026; final action projected for July 2027 | Design GLPI controls to the current rule and track the revision. Confirm final requirements with counsel once published. |
| No HIPAA certification | HHS states no standard requires certifying compliance; enforcement runs through complaints, reviews and audits | Do not promise a HIPAA certificate for GLPI. Keep evidence that an assessor can review, and confirm expectations with your compliance lead. |
Building an asset inventory across hospital sites
A hospital group rarely has one flat inventory. Each campus, clinic, outpatient site and administrative building needs to be modeled so that records can be filtered, owned and reported by location. In GLPI this usually means defining entities for the organizational boundaries that matter to access control, then locations beneath them for buildings, floors, wards and rooms. Keep the entity tree tied to how support teams are actually staffed, because entities also drive visibility of assets and tickets for each group of users.
- Entity boundaries: Decide whether each site, each legal entity or each service line becomes an entity, and document the reason. Changing this later is expensive.
- Location hierarchy: Model buildings, floors and rooms so that a device can be found during an outage or a fire-safety walk-through.
- Ownership fields: Record the responsible department and a named contact for every location, not only for devices.
- Naming conventions: Agree one naming scheme for sites and rooms across all campuses before any import.
- Access scope: Confirm which profiles can see which entities, so that staff at one site do not view another site's records by default.
Confirm the entity and location design with the people who run each site and with your information security lead before importing any data.
Inventory accuracy depends on how records reach GLPI. GLPI Agent collects hardware and software inventory from Windows, macOS and Linux computers and sends it to GLPI. It can also run network discovery and inventory, which helps find printers, switches and other network devices that cannot run an agent. Clinical and administrative devices should not be treated the same way: workstations and servers may accept an agent, while imaging workstations, infusion pumps and other connected equipment often must not be changed without the manufacturer's agreement.
- Agent deployment: Use your existing software distribution tooling for administrative endpoints, and test the agent on a small pilot group before wider rollout.
- Discovery scope: Limit network discovery to address ranges you have approved, and schedule scans outside clinical peaks.
- Clinical network segments: Agree with biomedical or clinical engineering which segments may be scanned at all, and whether SNMP queries are permitted.
- Import rules: Define how discovered devices are matched to existing records, so that duplicates are not created each time a machine is re-imaged.
- Stale data handling: Decide how long a device may be absent before it is flagged for review, and who makes that decision.
Confirm the agent version, supported platforms and discovery options against the GLPI Agent documentation for the version you plan to run.
Hospitals run on-premises server rooms, small data centers and sometimes co-located equipment. GLPI can hold records for racks, enclosures and the devices installed in them, along with their power and network connections where you choose to capture them. Good rack records answer practical questions during an incident: which physical host runs a clinical application, which switch uplinks a ward, and what must be powered down for maintenance. They also reduce the time needed to prepare for an audit of data center controls.
- Rack and position records: Record each rack, its location and the position of each device, updated at the time of physical change.
- Connection data: Capture which devices connect to which switches or power feeds where this matters for resilience planning.
- Hosting ownership: Identify which records belong to the hospital and which belong to an outsourced provider, and set access accordingly.
- Change linkage: Connect rack changes to change records so that the reason for each move is traceable.
- Backup of the inventory itself: Include the GLPI database in your backup plan, since the inventory is evidence as well as an operational tool.
Confirm which data center modules you need and how they are licensed for your deployment before modeling racks in detail.
Auditors and regulators ask for evidence that you know which assets handle health information, who owns them and how they are protected. Under the HIPAA Security Rule, covered entities must address device and media controls and information system activity, and there is no HIPAA certification, so evidence comes from your own records and from independent assessments. An accurate, dated inventory supports those controls, but it does not prove them alone. Medical devices need a separate track because their software, patching and network behavior are often controlled by the manufacturer and by clinical engineering.
- Control mapping: Link asset classes to the safeguards they support, such as access control and audit controls under 45 CFR 164.312, and keep the mapping under review.
- Medical device register: Keep medical devices in a distinct asset type with fields for manufacturer, model, clinical owner and whether an agent is permitted.
- Manufacturer confirmation: Before any scan, agent or patch touches a medical device, obtain written confirmation from the manufacturer and the clinical engineering team.
- Evidence exports: Define the reports you will produce for an assessor and test them before the audit date.
- Retention and review: Set a review cycle for the inventory and record who signed off each review.
Confirm with your compliance lead and independent assessor which evidence they expect, since HIPAA does not prescribe a certification format.
Which GLPI modules and settings matter for hospitals
A hospital GLPI instance is shaped by a few settings that interact: how tickets are timed around the clock, how clinical priorities reach the right team, how changes to clinical systems are recorded, and how staff sign in. The cards below cover the components to design first and the points to confirm before the build starts.
SLA and OLA calendars for 24/7 coverage
Hospital service levels usually run around the clock, while many support teams work fixed shifts. In GLPI, calendars define the hours that count toward SLA and OLA targets, so a ward outage at 03:00 is not measured against a day-shift clock. Model the calendars per site and per service, and test a sample ticket opened on a public holiday. Confirm with the vendor how calendars apply when a team is shared across sites and how OLA targets for group-managed work are timed.
Escalation and routing for clinical priorities
A ticket that affects medication administration or a theatre schedule should not wait in a general queue. Define urgency and impact rules that map clinical services to priority levels, route those tickets to on-call teams, and set escalation steps when acknowledgement times are missed. Keep the rules simple enough that clinical staff can choose the right category at the point of request. Confirm which routing and escalation conditions GLPI can match on in your version before promising specific response paths.
Change management for clinical systems
Changes to electronic health records, interfaces and medical device networks need approval records that an auditor or clinical safety lead can read later. Use GLPI change records linked to the affected assets and services, with approvers from clinical and security roles and a rollback note for each change. Decide early which changes need a clinical sign-off and which can follow a standard procedure. Confirm how change approvals and their history are retained and exported in your GLPI version.
Authentication order, profiles and entities
GLPI tries authentication sources in a fixed order: the internal database, then LDAP, then IMAP, then external methods such as REMOTE_USER. For hospitals, this order decides which account can reach patient-adjacent asset data. Map directory groups to GLPI profiles and entities so that a clinic's technicians see only their site's inventory, and disable local accounts that are not needed. Test each source with a leaver account, since a dormant database login can outlive the directory entry.
Service catalog and two-factor authentication
The service catalog lets staff request equipment, access or support from a controlled list instead of free text, which helps keep requests for clinical devices complete. Two-factor authentication protects the accounts that can reach asset and ticket data, including technicians working remotely. Decide which request types need approval before fulfilment, and which accounts must enrol a second factor before first use. Confirm how two-factor enrolment and recovery work with your chosen directory and whether it applies to self-service users as well as staff.
Encryption keys and backup handling
GLPI relies on keys stored in its configuration directory, including glpi.key and glpicrypt.key, to protect encrypted data. Losing them makes restored backups unreadable, and copying them carelessly exposes the data they protect. Back up the database, files and configuration directory together, store the keys separately under restricted access, and rehearse a restore to a clean host. Record who can authorize a restore, since hospital IT often needs to recover asset and ticket data within a defined window. Confirm the restore procedure with your own backup tooling before go-live.
How change control protects clinical systems in GLPI
A change record in GLPI answers three questions after the fact: which clinical system was altered, who made the change, and when it happened. The record is only as useful as its links, so connect each change to the affected computers, servers, network devices and clinical applications in the CMDB. Agree on a naming convention for clinical assets and a flag or category that marks them, so a change touching the laboratory information system or the pharmacy dispensing module is easy to filter and report on. Then confirm in your GLPI version how change status history, approval decisions and linked items are retained, because the evidence trail depends on those records staying intact.
The approval path should reflect who depends on each system. Route changes to clinical systems to the service owner and the care team lead who would be affected by an outage or a faulty update, alongside the infrastructure approver. Build those approver groups from the same profiles and entities that control what users can see, so an approver cannot view or act on records for another site or department. Keep patient-identifying details out of change descriptions and attachments, because the change record itself becomes an access-controlled item. Test the path with a sample change raised by a user from each group and confirm that the right people see it and no one else does.
GLPI prepares records, approvals and linked evidence. It does not validate clinical software, test clinical functions or decide whether a release is safe for patient care. Those decisions stay with your clinical engineering, vendor and validation processes, and the change record should point to them. If a manufacturer's records fall under 21 CFR Part 11, which covers electronic records and electronic signatures, the scope is a question for your quality team. Do not assume that a GLPI approval meets that rule's requirements until the quality team has assessed it against the specific workflow and retention needs.
Rolling GLPI out across a hospital group
This sequence moves GLPI from a classified scope to a tested pilot site and then to group-wide inventory, service calendars and change control, with backups and plugin plans in place before anything changes in production. Each step closes with a check the hospital group's own staff can confirm.
Classify scope and data before building
Agree with the group's IT, clinical engineering, privacy and security leads which sites, asset classes and ticket categories GLPI will hold. Classify each data type, separating asset and configuration records from tickets that may describe patients, staff or clinical incidents, and record which of those fields must stay out of free text. Ask your privacy office whether staff data in GLPI needs a documented purpose and retention period under GDPR. The step closes with a signed scope document that names the data owner for each class.
Build hosting and database to the supported baseline
Confirm the PHP and database versions for the GLPI release you intend to run against the current GLPI prerequisites, because the README and the installation docs list different minimums for GLPI 11 and 12. Use MySQL or MariaDB only, and set the web server document root to GLPI's public directory with URL rewriting routed through index.php, not the installation root. Place the database and file layout inside the infrastructure the group controls. The step closes when a test instance loads over TLS and the web server serves nothing outside the public directory.
Pilot GLPI on one site
Choose a single hospital site with a cooperative service desk and load its real assets, users, locations and contracts into a pilot instance. Run the helpdesk for a fixed set of ticket types, including one clinical-engineering request and one access request, and review which fields staff actually use. Record what the pilot showed about naming, locations and approval routing. The step closes with a documented list of configuration changes that the group agrees before wider rollout.
Deploy GLPI Agent and run discovery
Install GLPI Agent on the Windows, macOS and Linux endpoints in the pilot site, using the group's existing software deployment tooling, then enable network discovery only on subnets that clinical engineering has approved. Compare agent inventory against the pilot site's asset register and resolve duplicates, including devices that move between wards. Verify that discovery does not scan medical device networks that the manufacturer or biomedical team has not cleared. The step closes when inventory counts reconcile with the register for the pilot site.
Configure SLA calendars and change workflows
Build 24/7 SLA calendars for wards and clinical systems separately from administrative calendars, and agree with operations which escalations page on-call staff. Set up change templates for clinical system changes that require sign-off from the clinical owner, security and the service owner before implementation, and record the rollback plan on each change. Check that change approvals produce a retrievable audit trail. The step closes when a test change and a test incident each move through the expected SLA clock and approvals.
Plan plugin reactivation for each upgrade
List every installed plugin with its owner, version and whether the vendor or community maintains it. Since GLPI 11, plugins are suspended when a new version is detected, so schedule a reactivation and regression test for each upgrade, including the GLPI 10 to 11 move where plugin data migrations apply. Confirm that clinical-facing workflows still work after each reactivation. The step closes with a plugin register and an upgrade runbook that the group's change board has approved.
Set backup and key handling before production
Document backup jobs for the database, the application files and the config directory, and store them separately from the production hosts. The update procedure requires backing up these items and the config directory, including the glpi.key and glpicrypt.key files, so keep those keys in a controlled vault with restricted access and a tested restore path. Run a restore into a separate environment and confirm the instance comes up with working logins and encrypted fields. The step closes with a restore test record signed by the service owner.
Compliance considerations for healthcare GLPI deployments
A GLPI deployment that holds patient-adjacent systems, staff data and change records sits inside several overlapping regimes. The cards below separate what each regime requires, what it does not require, and where your organization, its hosting partner and its assessors each carry part of the work.
HIPAA has no certification
The HIPAA Security Rule applies to covered entities and their business associates for electronic protected health information. HHS states that no standard requires certifying compliance, and private certifications do not stop HHS from later finding a violation. Your organization produces the evidence (access reviews, asset records, change approvals, logs) and its own assessors or the HHS Office for Civil Rights review it. Confirm with counsel which GLPI records count as ePHI in your setting, since a ticket that names a patient can bring the whole ticket store into scope.
Business associate contracts for hosting partners
If a partner installs, hosts, patches or supports GLPI and can reach ePHI, that partner is usually a business associate. The contract must require Security Rule compliance, flow the same terms to any subcontractor that handles ePHI, and require reporting of security incidents to your organization. Ask any implementation partner, including DeployOpen, whether its work touches ePHI, which subcontractors it uses and where backups are stored. Keep GLPI tickets free of clinical detail where the contract does not cover it.
HITRUST as a voluntary assessment
HITRUST CSF is a voluntary framework, not a legal requirement under HIPAA, and organizations choose it to show control maturity to customers or payers. Its e1 and i1 certifications last one year and r2 certifications last two years. Before committing, decide which CSF version applies and map GLPI controls such as asset inventory, access and change management to the framework's control specifications. Certification is issued by HITRUST-authorized assessors, so DeployOpen can only prepare the controls and evidence for that process.
GDPR limits on staff data in GLPI
GLPI holds staff names, contact details, login history, device assignments and sometimes ticket comments about individuals. Under the GDPR, access to this data should follow a documented need, so technicians see only the entities, profiles and assets their role requires. Document the lawful basis, retention for leavers and the access review cycle. The Hopital Prive de la Loire case, fined by France's CNIL on 3 September 2026, centered on access control that ignored the care team's need to know, so profile design is a compliance control, not only an administration task.
NIS2 health sector scope
NIS2 Annex I lists health as a sector of high criticality, covering healthcare providers, EU reference laboratories, certain pharmaceutical research and manufacturing, and medical device makers critical in a public health emergency. Whether your organization is an in-scope entity depends on its size, its national transposition and its classification, which you should confirm with your national authority. If it is in scope, GLPI supports asset inventory, incident ticketing and supplier records that NIS2 duties depend on, but it does not make the organization compliant by itself.
European Health Data Space to confirm
Regulation (EU) 2025/327 creates the European Health Data Space framework for health data use and exchange. Whether its obligations reach a GLPI instance that holds only staff and asset records, rather than patient data, depends on how the regulation applies to your systems and your member state's implementing steps. Treat this as an open question for your legal team. Record the answer in your compliance file along with the data categories GLPI actually stores, so the review can be repeated when the rules take effect.
Questions hospitals ask before hiring a GLPI partner
What drives the cost of a GLPI implementation for a hospital?
The written scope sets the cost, and the main drivers are the number of sites and entities, the integrations, the agent rollout and the data you bring in. Each site adds discovery, configuration and testing. Each integration with a directory, single sign-on, mail or monitoring tool adds design and test work. Loading asset data from spreadsheets or another system adds cleaning and mapping. Clinical change control adds approval steps that must fit clinical schedules.
Costs split into one-time work (planning, build, migration, testing, hardening, documentation and training) and recurring costs (hosting in your infrastructure, database and backup operations, upgrades and any support retainer). Ask for quote line items per site and per integration, each marked one-time or recurring. DeployOpen does not publish a price list, and a quote follows from the written scope.
How long does a multi-site GLPI rollout take?
No single duration fits every hospital, so the timeline should come from the written scope for your sites. Four factors set it most. The first is the number of sites and whether they go live in waves. The second is the quality of existing asset and contract data, since cleaning that data often takes longer than loading it. The third is how agents reach each site's devices, whether through deployment tools, network access or manual installs. The fourth is the change window for each clinical system, because clinical and biomedical teams often approve changes only on set dates.
A common pattern is a pilot site, a review, then the remaining sites in groups. Ask for milestones, acceptance criteria for each wave, and the dependencies you must clear first, such as firewall changes or directory access, with a named owner for each.
What must our hospital provide before a GLPI engagement starts?
Three groups of people and access decide whether the work stays on schedule. Name them before the scope is signed.
- Data owners for assets, contracts, locations and departments, who can confirm which records are correct and approve field definitions.
- Network access for the build team to the GLPI servers, directory services, database, mail relays and the sites where agents will run, including the firewall rules that allow it.
- Clinical and biomedical contacts who confirm which systems are in scope, approve change windows and sign off testing that touches clinical workflows.
Also provide an executive sponsor with authority to settle disputes between departments, a test environment close enough to production to rehearse upgrades, and your current backup and access policies. The written scope should list each contact by role and the date they are needed.
Can our internal IT team run GLPI after the build?
Yes, if the team can operate a PHP application on Linux or Docker, a MariaDB or MySQL database and a supported web server. Day-to-day work covers automatic actions, notification queues, backups, database growth and console maintenance tasks. These should be written as runbooks during the build, not left to memory. The skills gap usually appears at upgrade time, when plugins must be checked and reactivated.
Ask whether the scope includes training and handover, and which documents the team receives at the end. If your team wants help after go-live, DeployOpen offers ongoing support, upgrades and continuous testing as retainers, agreed separately from the fixed-scope build. Decide before the build which tasks your team will own and which you will buy back through a retainer.
How does GLPI licensing compare with a fixed-scope build?
GLPI is distributed under the GNU General Public License version 3, so the software is open source, and the costs you see come from work and from optional vendor services. Teclib', which maintains GLPI, sells GLPI Network subscriptions. According to the GLPI Network subscriptions page, public cloud costs 19 euros per user per month and private cloud 21 euros per user per month with a 25-user minimum. Self-hosted subscriptions range from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise), with level 3 support and GLPI Network marketplace plugins.
These subscriptions cover vendor services and plugins. A fixed-scope build pays for planning, configuration, integration, migration and handover of your deployment, and it is agreed in writing before work starts. Compare the two by listing what each one covers and whether you need both.
Does a GLPI partner need a HIPAA business associate agreement?
It depends on whether the partner creates, receives, maintains or transmits electronic protected health information (ePHI) for you. The HIPAA Security Rule applies to covered entities and their business associates for all ePHI they handle. If a partner does handle ePHI, 45 CFR 164.314 requires a business associate contract. That contract must oblige the partner to comply with the Security Rule, pass the same terms to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI.
Asset and ticket records can contain patient details, so decide with your privacy counsel whether GLPI will ever hold ePHI and whether partner access to it is in scope. Note also that there is no HIPAA certification. HHS states that no Security Rule standard requires certifying compliance, so ask the partner for written evidence of the controls in place.
How are GLPI 11 and 12 upgrades planned?
Treat the upgrade as a tested change with a rollback path. According to the GLPI releases page, GLPI 11.0.0 was released on October 1, 2025, and GLPI 12.0.0 on October 7, 2026. The GLPI installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0. The README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or MySQL 8.0. Check the target release's requirements first and upgrade the platform underneath if needed.
The update procedure requires backing up the database, the files and the config directory, including glpi.key and glpicrypt.key. Then replace the application files and run php bin/console db:update. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so confirm each plugin supports the target version. Rehearse the full sequence on a copy before production and schedule it through your clinical change control.
How DeployOpen scopes and delivers GLPI for healthcare
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted GLPI inside the client's own infrastructure, so asset records and staff data stay under hospital control. Engagements start with a written scope that fixes deliverables and timelines before any build work begins.
How we scope
- Map every site, campus and clinical area to GLPI entities and locations before any configuration begins
- Record which asset classes, including medical devices and clinical workstations, enter inventory and which stay out
- Agree 24/7 SLA calendars, holiday rules and escalation paths for each service in the written scope
- Confirm the change control process for clinical systems and which approvals must be captured as evidence
- Document the GDPR basis, retention periods and access roles for staff data held in GLPI with your data protection officer
How we build
- Deploy GLPI on infrastructure you control, with the web server document root set to the public directory
- Connect directory authentication and profile rules so clinical staff see only the assets and tickets they need
- Configure SLA and OLA calendars, escalation and change workflows to match the agreed scope
- Set up GLPI Agent inventory and import rules, and test them against a sample of each device class
- Harden session cookies, encryption keys, exposed endpoints and administrative re-authentication before go-live
How we hand over
- Deliver written runbooks for the build, the configuration decisions and the access model
- Provide test records showing the inventory, SLA and change workflows behaved as agreed in the scope
- Document backup, restore and update procedures, including the protection of glpi.key and glpicrypt.key
- Train administrators and service desk leads on daily operation, reporting and escalation handling
- Hand over evidence packs that show your controls, but state clearly that auditors and certification bodies issue any assessment
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing
- Plan GLPI 11 and 12 upgrades, including plugin reactivation and database update steps, as a separate workstream
- Review access, SLA performance and inventory accuracy with your team on an agreed schedule
- Retest hardening and integrations after each GLPI release or configuration change that affects security
- Confirm with your compliance and legal teams which HIPAA, GDPR or NIS2 obligations your organization carries before relying on any evidence
