GLPI for managed service providers: what changes when one desk serves many clients
A managed service provider running one service desk and one asset inventory for many customers has a problem a single-company deployment never meets: every ticket, asset, contract and financial record must be visible to the customer it belongs to and to nobody else. GLPI is an open-source IT service management platform that covers tickets, assets, CMDB, contracts and financial management in one application, distributed under the GNU General Public License version 3. That licence matters for an MSP because the platform can be run in infrastructure the provider controls and adapted without per-seat software fees charged on top of the hosting you already pay for. The separation between customers is built on GLPI's entity model, where each customer becomes an entity, and on profiles and authorization rules that decide what a user in one entity can see and do. Your first decision is the entity tree itself: whether each customer is a top-level entity, whether customers with several sites get child entities, and where shared provider staff sit in that hierarchy.
Compared with a single-company deployment, the design work moves from configuring one organization to proving that configuration keeps customers apart. Ticket visibility, asset ownership, contract records and SLA definitions all depend on the entity a record is created in, so a mistake in the tree or in an authorization rule can expose one customer's data to another. Per-client SLAs and OLAs, prepaid credit tracking and customer-facing access are all configured against those entities, which makes entity design the foundation for the rest of the build. Ask whether your team can produce a test matrix that logs in as a user from each customer and confirms what that user cannot see, and whether that matrix is rerun after every plugin change or GLPI upgrade.
The work then spreads across four areas: entity and profile design, identity integration, inventory agents and plugins. Identity decides who signs in as which customer user, so it has to be settled before the desk goes live. Agents deployed to customer endpoints must report into the correct entity, which depends on how the agent is configured and how inventory rules place devices. Plugins that add customer-specific fields, credits or reporting need to respect the same entity boundaries, and each one should be checked against that test matrix before it is trusted. Confirm with the GLPI version you plan to run which of these features and plugins are supported on that release, and plan the upgrade path before the first customer goes live.
Which obligations shape an MSP's GLPI build
This table maps the regulatory and contractual obligations that most often reach a managed service provider and shows what each one means for a GLPI build. Read each row as a design input: entity structure, logging, access control and exit planning should be settled before clients are onboarded. The main takeaway is that client-facing evidence and data portability are set by the build, so they are cheaper to design in than to retrofit.
| Requirement | Source | What it means for the build |
|---|---|---|
| Managed service providers under high criticality | NIS2 Annex I places managed service providers and managed security service providers under ICT service management, a sector of high criticality | Expect clients and regulators to ask how your GLPI instance is secured, monitored and recovered. Document the platform as a service component, with named owners, access reviews and tested backups. |
| Technical requirements for managed providers | Commission Implementing Regulation (EU) 2024/2690 sets technical and methodological requirements for NIS2 Article 21(2) measures | Map GLPI controls such as access management, logging, backup and change handling to the regulation's requirements. Confirm with counsel which parts apply to your organization's status. |
| Processor contracts and documented instructions | GDPR Article 28(3) requires processors to act only on documented instructions and to apply Article 32 security measures | Each client entity holds personal data about its users and tickets. Configure entities and access so processing follows the client's written instructions, and record which entity data each instruction covers. |
| Switching rights and switching charges | EU Data Act, Regulation (EU) 2023/2854, requires switching support and from 12 January 2027 bars switching charges | Plan exit from day one. Keep ticket, asset and contract data exportable per entity, and confirm with your GLPI partner how exports, attachments and configuration are handled. |
| Client assessment through SOC 2 | AICPA 2017 Trust Services Criteria, with security criteria CC1 to CC9 applying to every SOC 2 examination | Clients often ask for SOC 2 evidence. DeployOpen prepares systems and records, but only an independent auditor issues the report. Build logs of administrative and entity-scope changes that an auditor can sample. |
Which GLPI settings an MSP configures first
A multi-client GLPI service desk stands or falls on a few settings that decide who sees what, how time is measured and who signs in. Each card below names one configuration area, what it controls for a managed service provider and what to test before any customer data goes in.
Entities per customer
Each customer is usually modeled as a GLPI entity, and entities can be nested to reflect a customer's own departments or sites. The hierarchy decides where tickets, assets and contracts live and which records inherit settings from above. Before go-live, create two sample customers with a child entity each, then confirm that a ticket raised in one child cannot be seen from a sibling. Also confirm which settings are inherited and which are set per entity.
Profiles and authorization rules
Profiles define what a role can do, and authorization rules decide which profile and entity a signed-in user receives. Together they keep a customer's contact from browsing another customer's tickets, even when both use the same service desk. Test with one account per role and per customer, including a technician who works across several clients. Check that the rules fire in the expected order and that a user who matches no rule gets no access.
SLAs and OLAs, including group-managed OLAs
SLAs set the time promised to each customer, while OLAs set the internal time a team or vendor has to meet its part. GLPI 12.0.0 added group-managed OLAs, which helps when several internal groups share one ticket. Build one SLA per contract tier with its own calendar, then run test tickets through escalation at each threshold. Confirm that holidays and time zones match each customer's contract, not your office's.
Customer credits through supporting plugins
Prepaid time is not a core ticket field, so billing credits usually come from a plugin that tracks hours bought and hours consumed per customer. The plugin choice shapes how credits reduce on ticket closure and how overruns are reported. Before go-live, confirm the plugin version against your GLPI version, then test a ticket that exhausts a balance, a partial consumption and a correction. Agree with finance who owns a wrong balance and how it is reversed.
GLPI Agent with inventory separated by entity
GLPI Agent collects hardware and software inventory and sends it to GLPI, and it runs on Windows, macOS and Linux. For an MSP, the risk is an agent reporting a device into the wrong customer entity, which is hard to unwind later. Set the entity targeting per deployment group, and test with one device per customer before rollout. Verify that inventory from a shared gateway or jump host is assigned to the right entity.
Authentication order for staff and client users
GLPI tries authentication sources in order: the internal database, then LDAP, then IMAP, then external methods such as REMOTE_USER. For an MSP, the order decides whether a customer's directory account can shadow a local technician account. Map each customer directory to its entity, decide whether the internal database is used for staff only, and test a login with the same username in two customers. Confirm the behavior when a directory is unreachable.
How entities and authorization rules keep customers apart
In a multi-client GLPI instance, the main isolation decision is to model each customer as its own entity, so that tickets, assets, contracts and reports belong to one customer by default. Entities are a data boundary, not a substitute for access control, so they only protect customers when they are combined with profiles and authorization rules. Profiles define what a user can do (create tickets, read assets, run reports), while authorization rules and the entity assignment of each user define which entities that user can see. Shared technicians are the hardest case: a technician who is given read access across several entities will see all of them, so each shared role should be scoped to the entities that person genuinely serves, and the profile should be reviewed for any right that exposes data across entities, such as global reports or saved searches. Confirm the exact behavior of each right in the GLPI version you deploy before you rely on it.
Isolation claims should be tested, not assumed. Create one test user per entity, with a client-facing profile and a technician profile, and attempt cross-entity access to tickets, assets, contracts and reports by direct URL, search, and exported files. Repeat the checks for notifications: confirm that a ticket update for one customer never reaches a recipient in another entity, including through followups, satisfaction surveys and reminders. Record each result as evidence, because the same checks become the regression suite you rerun after every GLPI upgrade or plugin change.
GLPI 12.0.0 adds two controls that matter for a provider's administrators. The session view lets an administrator see active user sessions and revoke them, which is useful when a shared technician account or a departing employee still has an open session. Step-up authentication requires a user to confirm their identity again before certain administrative actions, which limits the damage from an unattended, logged-in administrator console. Decide which administrative actions your operating model should protect, verify in a test instance which actions trigger step-up authentication in your target version, and document who may revoke sessions and how that action is logged.
Rolling out GLPI from a pilot client to the full portfolio
This sequence moves a multi-client GLPI service desk from a design on paper to a production platform in which every client is isolated, measured against its own SLAs and covered by a tested update routine. Each phase opens only when the previous one has passed a defined gate.
Confirm the entity and SLA model
Before any installation, the service owner and DeployOpen agree on the entity tree, one entity per customer, the SLA and OLA calendars each client has bought, the profiles that let technicians see across clients, and the rules for prepaid credits. The output is a written model that names every entity, calendar and authorization rule. The step is complete when the service owner signs off on that document, because every later isolation test is checked against it.
Build a non-production GLPI instance
The platform team installs GLPI in a non-production environment that matches the planned production layout. The stack must meet the prerequisites in the GLPI installation documentation: PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later for the current README, or the PHP 8.2, MySQL 8.0 or MariaDB 10.6 combination listed for GLPI 11.0. The web server document root must point to GLPI's public directory, with URL rewriting routing requests through index.php. The step closes when a test administrator can sign in, the entity tree from the model exists, and the instance passes a basic health review.
Pilot one client end to end
The team configures a single client with its own entity, SLA and OLA calendars, contacts, assets, and a GLPI Agent deployed to that client's devices. Technicians work real tickets through escalation, approvals and reporting for a set period agreed with the service owner. The gate is a review of ticket routing, SLA clocks, inventory accuracy and client-facing reports, with every defect either fixed or accepted in writing. Nothing moves to the next client until this review is signed.
Onboard remaining clients in batches
Clients are added in batches rather than all at once, each batch following the same pattern: entity creation, calendar setup, agent rollout and data load. After every batch, the team runs isolation tests: a user from one client must not see tickets, assets, contracts or credits belonging to another, and cross-client technician access must match the authorization rules in the model. The batch closes when the isolation test results are recorded and the service owner accepts them.
Verify isolation across the portfolio
Once all clients are onboarded, the team runs a full isolation review across the portfolio. It checks entity-scoped reports, notification recipients, the GLPI Agent inventory mapping, and access granted through any external authentication source. The output is a signed test register with each control tested, the observed result and the owner of any exception. This register becomes the reference for future changes to profiles, rules or entities.
Hand over to operations with backups
The platform team hands the instance to operations with a documented backup routine covering the database, the GLPI files and the config directory. The config directory must include glpi.key and glpicrypt.key, and the team must store copies of both separately from the server, because losing them can make encrypted data unrecoverable. The handover closes when a restore has been tested into a separate environment and the operations runbook names the owner of each backup job.
Run the update procedure with plugin checks
Each update follows the GLPI installation documentation: back up the database, files and config directory, replace the application files, then run php bin/console db:update. Since GLPI 11.0, plugins are suspended after a new version is detected, so the team must reactivate each plugin after the update and check that its custom fields, forms and integrations still work. Every update is first applied in the non-production instance. The step is complete when a production update has a recorded checklist, a rollback point and confirmed plugin status.
Choosing self-hosted GLPI or a GLPI Network subscription
Self-hosting means the MSP installs and runs GLPI in its own cloud accounts, data centers or virtual machines. The GLPI software is distributed under the GNU General Public License version 3, so the MSP pays no license fee for the core platform. Costs shift to infrastructure, staff time for upgrades and backups, and any plugins or support contracts the MSP chooses to buy.
- Infrastructure cost: Servers, database hosting, storage, backup targets and monitoring are billed to the MSP, whether in a public cloud or its own facilities.
- Upgrade effort: Major releases such as the GLPI 10 to 11 move require a planned update, and plugins are suspended after a new version is detected until they are reactivated.
- Data control: The MSP chooses where each client's tickets, inventory and contracts are stored, which helps with residency and contract terms.
- Hardening and isolation: Web server layout, encryption key handling, backups and entity-based authorization rules remain the MSP's work.
- Support: Community resources are free, while level 3 support comes only with a GLPI Network self-hosted subscription.
Confirm with your own platform team how many hours a month you can give to patching and backups before choosing this route.
A self-hosted subscription keeps GLPI in the MSP's infrastructure but adds a paid tier from GLPI Network. According to the GLPI Network subscriptions page, these range from 100 euros per month for the Basic plan, which covers up to 10 agents and 500 assets, to 4,500 euros per month for Enterprise. The subscription is the vendor's commercial offer, so the price is set by plan rather than by the number of clients you serve.
- Plan tiers: Basic, and the higher plans on the page, differ mainly in agent and asset limits and in the support and marketplace plugins included.
- Support level: The Enterprise tier includes level 3 support, which matters for MSPs running several client entities on one instance.
- Marketplace plugins: Some GLPI Network plugins are included in higher tiers, so check which ones you would use for SLAs or reporting.
- Limits to model: Agent and asset caps can be reached quickly across many customers, so count them per plan before choosing a tier.
- Ownership: Backups, client isolation and hardening stay with the MSP even with the subscription.
Ask the vendor which plugins and support hours each tier includes, and whether the price changes as your agent or asset count grows.
GLPI Network also offers hosted options. According to the GLPI Network subscriptions page, the public cloud costs 19 euros per user per month, and the private cloud costs 21 euros per user per month with a 25-user minimum. Pricing is per user, so the bill grows with the number of technicians and users who log in, which is a different driver from the self-hosted tiers.
- Per-user billing: Public cloud at 19 euros and private cloud at 21 euros per user per month are recurring charges that scale with staff headcount.
- Minimum commitment: The private cloud has a 25-user minimum, which can make it costly for a small MSP team.
- Hosting location: Ask where public and private cloud instances are hosted, and under which jurisdiction, before storing client data there.
- Responsibility split: The vendor operates the platform, but the MSP still defines entities, profiles and authorization rules that keep customers apart.
- Exit terms: Confirm how data is exported and what the notice period is if you move back to self-hosting.
Confirm all prices with the vendor, since the subscription page is the only source for these figures and terms can change.
Evidence MSP clients and auditors will ask the provider for
A managed service provider running GLPI for many customers is often asked to show its own controls, not only the ones it runs for clients. The cards below cover the attestation, certification and regulatory questions that come up most often, and what each one means for how the service desk is built. DeployOpen prepares systems, configuration and evidence; independent auditors issue SOC 2 reports and accredited certification bodies issue ISO/IEC 27001 certificates.
SOC 2 Type 1 versus Type 2
A Type 1 report describes the provider's system and the design of its controls as of a single date. A Type 2 report adds an auditor's opinion on whether those controls operated effectively over a period. Clients usually ask for Type 2 because design alone says little about daily ticket handling. Check who the report is restricted to, since a provider's SOC 2 is generally shared only under nondisclosure, unlike a general-use SOC 3 report. Ask the provider which report it holds and what period it covers.
Common criteria CC1 to CC9
Every SOC 2 examination includes the security common criteria, CC1 to CC9, drawn from the AICPA 2017 Trust Services Criteria. For a GLPI service desk, the evidence usually sits in access reviews of the GLPI profiles and entities, change records for configuration and plugin updates, logging of administrative actions, and vendor oversight of hosting. Other categories such as availability or confidentiality are added only when they are in scope. Confirm with the auditor which categories apply before collecting evidence.
ISO/IEC 27001:2022 Annex A
Annex A of ISO/IEC 27001:2022 lists controls in four themes: organizational, people, physical and technological. A provider seeking certification must show which Annex A controls it applies and why, in a statement of applicability. For GLPI, asset inventory, access control and supplier management records are the most visible items. Certification is issued by an accredited certification body, not by ISO, and it runs on a three-year cycle with audits in intervening years. Ask for the certificate scope and confirm it covers the GLPI service.
NIS2 obligations for MSPs
NIS2 Annex I places managed service providers and managed security service providers under ICT service management, a sector of high criticality. Where a provider falls in scope, its obligations include the security measures in Article 21, and the implementing regulation adopted in October 2024 sets technical requirements for managed service providers. Clients in regulated sectors will ask how the provider handles incident reporting and supplier risk. Confirm with counsel which national rules apply to your provider and your clients.
GDPR processor contract terms
Tickets routinely contain client personal data such as names, addresses and login details. Under GDPR Article 28(3), the contract between the MSP and each client must bind the processor to act only on documented instructions, including for transfers, and to meet the security requirements of Article 32. Map where ticket attachments, agent inventory and email-to-ticket content are stored, and which sub-processors touch them. Review the data processing agreement against this list before the GLPI service goes live.
EU Data Act switching rights
The EU Data Act, which has applied since 12 September 2025, requires data processing service providers to let customers switch to another provider or to on-premises infrastructure. The notice period is capped at two months, with a 30-day transitional period. From 12 January 2027, switching charges may not be imposed. For a GLPI MSP, this means ticket history, assets and configuration must be exportable in a usable form. Ask the provider how it would export a client's GLPI data and how long that would take.
What the Data Act means for leaving a GLPI service
The EU Data Act gives an MSP a legal footing for moving customer service data out of a hosted GLPI service. Under Regulation (EU) 2023/2854, which has applied since 12 September 2025, data processing service providers must let customers switch to another provider or to on-premises ICT infrastructure. The regulation sets a maximum two-month notice period and a 30-day transitional period. From 12 January 2027, providers may not impose any switching charges, and until then reduced charges may not exceed the costs directly linked to switching. Whether a given hosted GLPI arrangement falls under these articles depends on how the service is contracted and who operates it, so confirm the applicability with counsel before relying on these periods in a customer or vendor agreement.
Being able to switch on paper is not the same as being able to leave. For an MSP, the exit set should cover tickets with their full history and follow-ups, asset records and their links to customers, contracts and renewal dates, SLA and OLA definitions with their calendars, the entity tree that separates each client, and the attachments stored against tickets and assets. Ask the provider which of these leave through the interface, which need a database-level export, and whether attachments and audit history arrive in a usable form. Then run a test export for one client entity and load it into a scratch GLPI instance, checking that ticket counts, contract end dates and SLA targets match the source. Written instructions for this test belong in the exit plan.
Plan the exit as a project with its own timeline, because the statutory notice and transitional periods are short relative to the work of re-pointing customer contracts, monitoring and inventory agents. Keep the glpi.key and glpicrypt.key files and the database dump under the MSP's own control, so the data can be read after the platform changes hands. Ask the current provider for a written statement of any switching charges and when they apply, and confirm with counsel whether the MSP's own client contracts need matching exit clauses so that customers can leave the MSP without losing their records.
Questions MSPs ask before a GLPI implementation
What drives the cost and effort of a multi-client GLPI build?
The main drivers are the number of entities (one per customer in most MSP designs), how many distinct SLA and OLA schedules you need, how many integrations sit behind the service desk, how many devices must be enrolled with GLPI Agent, and whether you are migrating tickets and assets from another tool. Each entity adds configuration for profiles, authorization rules, notifications and reporting, so the count multiplies the review and testing work. Ask any partner to break the quote down by these drivers. A written scope should list each client entity, each SLA schedule, each integration and each migration source so you can see what changes the price.
Which GLPI costs are one-time and which recur?
One-time costs usually cover design, configuration, data migration, agent packaging, testing and handover. Recurring costs cover hosting, database and backup storage, operating system and PHP patching, GLPI version upgrades, plugin maintenance and any support contract. GLPI itself is distributed under the GNU General Public License version 3, so the software has no licence fee, but GLPI Network is a separate paid option. The GLPI 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 subscriptions from 100 euros per month (Basic) to 4,500 euros per month (Enterprise). Confirm which of these, if any, your service model needs.
How long does a multi-client GLPI implementation take?
Duration depends on the number of client entities, how much SLA and approval logic must be designed, how many data sources must be migrated and cleaned, and how many client-side stakeholders must review and test. Clients with their own identity provider, strict network rules or unusual approval chains add time. No fixed duration can be given before the scope is written, so ask for a phased plan with milestones for design sign-off, a pilot entity, migration rehearsal and production cutover. The GLPI 11 and 12 upgrade path, if you plan to upgrade during the build, should also appear as its own phase.
What must our MSP provide before the build starts?
Expect to provide a current client list with legal names and contract boundaries, written SLA and OLA schedules per client, business hours and holiday calendars, the identity sources each client uses, and the network paths from GLPI and from agents to client sites. You also need named staff who can test ticket routing, approvals and reports for each client, plus access to your current ticket tool and asset exports. Confirm who signs off on authorization rules, because a client isolation error is a security issue, not only a configuration bug.
Can our internal team deliver a multi-client GLPI build alone?
A capable internal team can do it if it has people with PHP and Linux operations experience, database administration for MySQL 8.0 or MariaDB, web server configuration, directory integration and service desk process design. GLPI requires PHP 8.2 or later for GLPI 11.0 and PHP 8.3 or later for the current main branch, so your build pipeline and hosts must match. Be honest about who will own the entity model, authorization rules and upgrades after go-live. If those skills or staff are thin, a fixed-scope partner engagement with knowledge transfer is an option.
How do we keep one client from seeing another client's tickets?
Use GLPI entities as the primary boundary, then test profiles and authorization rules against real user accounts before every release. Authentication order also matters: GLPI tries the internal database, LDAP directories, IMAP and external methods such as REMOTE_USER in that order, so a client directory must not accidentally match another client's users. Review who holds super-administrator or entity-wide rights. Write isolation tests as acceptance criteria in the scope, and repeat them after each GLPI upgrade and plugin change.
What should we ask for in a written, fixed-scope quote?
Ask for a quote that lists every deliverable and assumption: the entity count and naming, SLA and OLA schedules, integrations, agent rollout scope, migration sources and record volumes, test cases, acceptance criteria and handover documents. Confirm which GLPI version is in scope and whether the upgrade path to GLPI 11 or 12 is included. Require a statement of what the client provides, what is excluded, how change requests are priced and what post-go-live support or retainer is offered. Fixed scope is usually agreed in writing before work starts, so every item you care about should appear there.
How DeployOpen scopes and delivers a GLPI MSP service desk
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For GLPI as a multi-client service desk, we start from a written scope that sets out entities, SLAs, credits and authorization rules before any build begins.
How we scope
- List every customer entity, its contracted SLA and OLA calendars, and which contracts and prepaid credits it holds.
- Define the authorization model that keeps each customer's tickets, assets and reports separate from the others.
- Agree in writing which integrations, agents and plugins are in scope, and which are excluded from the fixed scope.
How we build
- Deploy GLPI on infrastructure you control, with the web server document root set to the public directory and PHP and database versions checked against the release requirements.
- Configure entities, profiles, SLA rules, escalation and routing per customer, then test each boundary with accounts from different customers.
- Validate the GLPI 11 and 12 upgrade path on a staging copy, including plugin reactivation steps, before production changes are scheduled.
How we hand over
- Document entity structure, authorization rules, SLA configuration and credit handling so your operators can explain and change them.
- Provide backup and restore runbooks covering the database, files and the glpi.key and glpicrypt.key encryption keys.
- Run a handover session with your service desk leads and walk through the test evidence for customer separation.
How we support
- Support is available as a retainer for updates, plugin maintenance, and new customer onboarding after the initial delivery.
- Ongoing work is priced from the written scope, so the cost of each new customer or entity is known before it is added.
- Confirm with DeployOpen which release train and support level your team needs before the retainer scope is signed.
