Open source ITSM for the public sector: why the build differs
A public body running a service desk has to keep audit-ready records of assets and contracts, often for several departments or municipalities that each carry their own budgets, owners and procurement cycles. The short answer is that GLPI is the usual starting point for asset- and contract-heavy estates, because its inventory, contract and financial modules cover that ground out of the box, while iTop suits a customized CMDB model where the data structure has to follow local governance more closely. The ITIL processes themselves change little between a ministry and a private company. What changes is the set of rules around them.
Federal, state and EU rules shape the build more than the process model does. In the United States, NIST SP 800-53 Rev. 5 and its baselines, along with FedRAMP scope under OMB M-24-15, decide whether a hosted ITSM service can hold agency data at all, and the FBI CJIS Security Policy sets encryption and scanning requirements where criminal justice information appears in tickets. In the EU, NIS2 defines which public administration entities are in scope and which are excluded for national security or law enforcement work. Accessibility is a separate obligation: under the ADA Title II rule, state and local government web content must meet WCAG 2.1 Level A and AA, with compliance dates in April 2027 or April 2028 depending on the size of the entity. The self-service portal is therefore part of the compliance surface.
Before you select a platform, confirm which of these regimes applies to each entity in scope, and who in your organization owns that answer. Ask whether ticket content can contain regulated data, whether identity will come from a government identity service, and whether the portal must meet WCAG 2.1 on a fixed date. These answers decide where the instance is hosted and which identity connectors you need. This page covers only what is specific to public bodies, so the general ITSM process, CMDB and integration guidance is handled in the sibling sections and related topics.
Which public-sector rules shape the ITSM build
This table maps the public-sector rules most likely to touch a service desk and CMDB to concrete build decisions. Read each row by asking which rule applies to your entity, then check the build column for hosting, key length, scanning, portal accessibility and audit logging. Most rows depend on what data the tickets hold, so confirm scope with your legal and compliance leads before design.
| Rule or control | What it asks for | What it means for the ITSM build |
|---|---|---|
| NIST SP 800-53 Rev. 5 baselines | Low, moderate and high baselines select 149, 287 and 370 controls and enhancements respectively under SP 800-53B (Release 5.2.0) | Choose the baseline with your authorizing official or agency security office, then map GLPI or iTop audit logs, access control and backup to the selected control IDs |
| FedRAMP scope | Applies to cloud products that hold federal information on behalf of an agency; single-agency systems on cloud infrastructure not offered as a shared service are out of scope | Self-hosting in your own data center or agency-controlled cloud generally keeps the ITSM platform out of FedRAMP scope; confirm this in writing if a vendor or managed host is involved |
| CJIS Security Policy v6.1 encryption | FIPS 140-3 validated modules or FIPS 197 AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations | Police-linked tickets or asset records containing CJI need 256-bit encryption on database, file store and TLS paths; confirm module validation with your CJIS Systems Agency |
| CJIS vulnerability scanning | Vulnerability scanning at least monthly under the RA-5 control family | Schedule authenticated scans of the GLPI or iTop server, database and agent endpoints at least monthly and keep results with the change records |
| 32 CFR 2002.14(h)(2) and CUI | Federal agencies use NIST SP 800-171 requirements to protect CUI on non-federal systems unless the CUI category sets other safeguards | If tickets describe CUI, treat the ITSM host as a non-federal system under SP 800-171 and restrict attachments, free-text fields and report exports accordingly |
| ADA Title II web accessibility | State and local government web content and apps, including contracted ones, meet WCAG 2.1 Level A and AA from 26 April 2027 (50,000 or more people) and 26 April 2028 (smaller entities and special districts) | Self-service portals and knowledge base pages built on the ITSM platform need WCAG 2.1 AA testing, and vendor theme or plugin work must be included in the acceptance scope |
| NIS2 for EU public administration | Covers central government entities regardless of size; Member States may extend it to local administration; excludes national security, public security, defense and law enforcement | Confirm national transposition before scoping; for in-scope bodies, keep incident timestamps, asset and supplier records linked in the ITSM tool as evidence |
| Audit logging for public records | Records of administrative actions and access must be retrievable for oversight and inspection | Enable audit trails for administrator actions, role changes and asset edits in GLPI or iTop, and forward logs to a protected store with retention set by your records schedule |
How multi-entity departments and municipalities fit one GLPI or iTop instance
Decide the data separation model before go-live, because it is hard to change later. In GLPI, the natural unit for separating departments, municipalities or agencies is the entity, with tickets, assets, contracts and users assigned to an entity and visibility controlled through profiles and groups. In iTop, the equivalent starting point is the organization object, which many CMDB records reference. For each candidate unit, confirm with the vendor and your own tests which records can be scoped to a single entity, which must stay visible across all of them, and whether reporting can be restricted per entity without custom development. Do not assume that a feature available in one product exists in the other, and do not assume that a restriction set in the user interface also applies to API access or exports. Write the answers down as a data ownership matrix that your architects, records managers and legal team sign off before the first asset is imported.
A shared service catalog and a shared CMDB are what make one instance worth running for a public body. Keep the catalog and the core configuration items (network services, identity platforms, shared line-of-business applications) in a common scope, so a single outage in a shared service can be linked to every affected municipality or department in one record. Entity-specific assets, such as local printers or school-level devices, stay in their own scope. This split lets an incident in a shared service be recorded once and related to the affected entities without copying data. Test a cross-entity incident in a non-production copy: confirm that the entity owner sees only the relationships they are allowed to see, that approvals route to the right authority, and that the audit trail records who changed a shared item.
Authentication must follow the government directory design, not a local shortcut. GLPI tries authentication sources in a fixed order: the internal database first, then LDAP directories, then IMAP mail servers, then external methods such as REMOTE_USER, as described in the GLPI user documentation on authentication. Because the internal database is checked first, keep local accounts limited to break-glass administrators and confirm that no directory user can be shadowed by a local account with the same login. Confirm with your identity team how each entity's directory structure maps to GLPI entities and profiles, and whether group membership from the directory can assign entity access automatically. Document the mapping, and test it with a user from each entity before go-live.
Which open-source ITSM platform fits a public body
Public bodies usually need one asset and CMDB record across many departments, plus a separate intake for citizen requests. The cards below separate the service management core from the helpdesk channel and the licence duties that follow from modifying either one.
GLPI as the service management core
GLPI covers tickets, assets, contracts and financial management in one GPL-3.0 platform, which suits a multi-entity setup where each department keeps its own inventory and contract records under a shared model. Version 12.0.0 was published on October 7, 2026. Check that its entity hierarchy, profiles and OLA rules match how your departments are actually organized, and test them with a pilot department before rolling out.
Step-up authentication for administrators
GLPI 12.0.0 adds step-up authentication for certain administrative actions and a view of active user sessions with the ability to revoke them. For a public body, these controls help answer audit questions about who changed profiles, entities or asset ownership. Confirm which actions trigger step-up prompts in your version, and how revoked sessions are logged.
iTop for a customizable CMDB model
iTop is AGPL-3.0 licensed and built around a customizable CMDB model, which fits agencies that must record dependencies between applications, services, contracts and infrastructure in their own vocabulary. Version 3.3.0 was published on September 15, 2026. Before choosing iTop over GLPI, agree the CMDB classes and relationships with the business owners, since model changes are the main effort in iTop projects.
Zammad for citizen and internal channels
Zammad is a web-based helpdesk licensed under AGPL-3.0 and suits a broad intake with multiple channels, queues and reporting. Release 7.2.2 on October 8, 2026 was a security update, so patch cadence should be part of the operating model. Ask whether ticket data flows into GLPI or iTop by API or manual entry, because duplicate records weaken audit trails.
osTicket or FreeScout for narrow channels
osTicket (GPL-2.0) and FreeScout (AGPL-3.0) suit a single department, such as a permit or benefits inquiry form, where the scope is small and fixed. Keep these tools limited to one channel and route anything requiring asset or change linkage into the ITSM core. Confirm that each tool's release cadence and plugin set meet your security review before approving it.
Licence duties for agency modifications
AGPL-3.0 obligations can apply when an agency modifies a program and makes it available to users over a network, including offering the source of the changed version to those users. GPL-3.0 and GPL-2.0 carry distribution duties. Procurement should record which components are modified, who holds the code, and whether contractor changes are delivered under compatible terms. Have counsel confirm these obligations against your jurisdiction.
Deployment patterns for federal, state and municipal bodies
An on-premises deployment keeps the GLPI database, file store and configuration inside the agency's own facilities, under its own physical and administrative control. This pattern is usually the first choice where the service desk records contain criminal justice information or controlled unclassified information, because the agency can show exactly where the data sits and who can reach the servers. The application runs on a PHP 8.3 or later stack with MariaDB 10.11 or later or MySQL 8.0 or later, according to the GLPI README, while the GLPI 11.0 installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6. Confirm which version line you are installing before you build the server image.
- Runtime baseline: Only MySQL and MariaDB are supported as the database engine, so plan the database service around one of those two.
- Document root: Point the web server's document root at GLPI's public directory, not the installation root, and enable URL rewriting so requests route through
index.phpon Apache, Nginx, lighttpd or IIS. - Key backup before updates: Back up the database, the application files and the config directory, including
glpi.keyandglpicrypt.key, before replacing files and runningphp bin/console db:update. Losing these keys can leave encrypted data unreadable. - Plugin reactivation: Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so schedule time for that check.
- Evidence trail: Keep the update and backup records in the change system so the approval history matches the running version.
Before approving this pattern, ask your implementation partner to show the restore test for the key files and to confirm the controls that apply to your own CJI or CUI boundary.
A sovereign private cloud places GLPI on virtual infrastructure located within national territory, operated under contract by a provider or by the agency's own platform team. It suits bodies that need cloud-style elasticity and managed hardware but must keep data, administrators and backups inside the country. The runtime requirements do not change: the same PHP, MariaDB or MySQL, web server and document root rules apply. What changes is the set of parties with access, so the boundary and the operator obligations need to be written down before go-live.
- Operator access: Record which staff of the hosting provider can reach the database, the file store and the hypervisor, and whether support access is logged and approved.
- Backup location: Confirm that database dumps, file archives and copies of
glpi.keyandglpicrypt.keyare stored in national territory and encrypted with keys the agency controls. - Upgrade ownership: Agree who runs
php bin/console db:update, who reactivates plugins after a major release and who signs off each change. - Network path: Place the instance behind the agency's identity and reverse proxy layer so directory authentication is handled before a request reaches GLPI.
- Hosted option: GLPI Network public cloud costs 19 euros per user per month and private cloud 21 euros per user per month with a 25-user minimum, according to the GLPI subscriptions page. Ask the vendor whether that price and the data residency terms match your national requirements.
Ask the provider for a written description of the data locations, operator roles and key custody before comparing any quote with a self-hosted build.
A shared instance serves several small councils or special districts from one GLPI installation, with each council represented as a separate entity inside the same database. This reduces the number of servers and patch cycles any single council must carry, and it gives smaller bodies access to a maintained service desk they could not run alone. The trade-off is that one operator administers every tenant, so entity boundaries, role assignments and backup scope have to be designed as carefully as the software itself. Illustrative example: a host serving four councils would need separate entity trees, separate approval groups and a documented process for restoring one council's data without touching the others.
- Entity separation: Define one entity per council, with visibility rules and administrator roles that stop one council's staff from viewing another's tickets or assets.
- Shared update window: One upgrade affects every council, so agree a common maintenance calendar and a rollback plan before each major release.
- Backup scope: Test whether a single council's data can be restored on its own, and keep
glpi.keyandglpicrypt.keyunder controlled custody with access logged. - Authentication order: GLPI tries the internal database, LDAP directories, IMAP mail servers and other external methods such as REMOTE_USER in that order, so confirm which directory each council authenticates against.
- Cost sharing: Ask how the hosting, support and administration effort is split between councils and who pays for upgrades.
Before committing, ask for the tenant isolation test results and the restore procedure for a single council, not only the platform installation guide.
Rollout phases for a public-sector service desk
The sequence moves from scoping and control mapping to a tested go-live and a repeatable update procedure, with each phase producing evidence that the next one depends on. Agencies and municipalities can use it to check what a partner should deliver at each stage before accepting it.
Scope the service desk and map controls
Confirm which departments, entities and service channels the desk covers, and which control baseline applies to the system (for example, NIST SP 800-53 low, moderate or high, or a state framework that references it). DeployOpen maps the applicable controls to the GLPI processes, asset records and audit logs that will hold the evidence. The step closes when the agency signs off a written scope and a control-to-configuration matrix that names the owner of each control.
Design hosting and identity boundaries
Decide where the platform runs (agency data center, government cloud account or a hosted environment the agency controls), which database engine is used, and how the web server presents the GLPI public directory. Define how staff authenticate, including the order in which GLPI tries the internal database, LDAP, IMAP and external methods, and which government identity source is authoritative. The step closes with an approved architecture diagram, a backup and key-custody plan, and a list of accounts that need step-up authentication for administrative actions.
Discover and inventory existing assets
Deploy GLPI Agent to a pilot set of Windows, macOS and Linux endpoints, then run network discovery to find devices that have no agent. Reconcile the results with procurement records and any existing asset register, and flag unknown devices for investigation. The step is complete when inventory counts are compared against the agency's own source lists and every discrepancy has an owner and a disposition.
Migrate data and reconcile contracts
Move tickets, asset records, software licenses, support contracts and supplier details from spreadsheets or legacy tools into GLPI, keeping the original identifiers so that audit trails remain traceable. Reconcile contract end dates, license counts and purchase orders with the finance or procurement team. The step closes with a migration report listing record counts by type, rejected rows and the reconciliation sign-off from the contract owner.
Pilot with one department
Run the service desk for one department with its real request types, approval chains and SLA definitions, and collect feedback from the requesters and the agents who handle the tickets. Test the identity integration with a limited group of accounts and verify that audit records capture who changed each asset and ticket. The step is done when the pilot exit criteria agreed in scoping are met and the open defects have documented fixes or accepted workarounds.
Go live with staff and public channels
Enable the service catalog, self-service portal and any public intake channel for the wider organization, with the support hours, escalation paths and contact points published in advance. Confirm that backups have run successfully and that the restore procedure has been rehearsed. The step closes when go-live is recorded with the cutover date, the named service owners and the first operational report covering tickets, assets and open approvals.
Run the post-go-live update procedure
Before every GLPI update, back up the database, the application files and the config directory, including the glpi.key and glpicrypt.key files, then replace the application files and run the database update command. Because plugins are suspended when a new version is detected, schedule a review of each plugin and reactivate it only after confirming compatibility, particularly after a major version change. The procedure is verified when a test restore and a post-update smoke test pass, and the change record is stored as evidence for the next audit.
Evidence auditors and inspectors ask for from the ITSM
This table maps each evidence artifact a public sector auditor or inspector typically requests from a GLPI or iTop service desk to the component that produces it. Read it as a checklist to confirm before go-live, since the exact fields and export options depend on the version and plugins you deploy. DeployOpen prepares this evidence and the controls behind it, but does not issue audit opinions, attestations or certifications; independent auditors and certification bodies do.
| Evidence artifact | Produced by | What to confirm before go-live |
|---|---|---|
| Asset inventory export with owners and locations | GLPI asset module fed by GLPI Agent inventory; iTop CMDB for configuration items | Owner and location fields are mandatory, and exports can be scheduled and retained outside the application |
| Software and license records tied to contracts | GLPI contract and license management; iTop contract links | Each license links to a contract, supplier and renewal date, with reconciliation against agent-reported installs |
| Ticket histories with timestamps and approvals | GLPI and iTop incident, request and change records with approval workflows | Audit log retention period, timezone handling and whether approval steps cannot be edited after closure |
| Role and admin action logs, including step-up authentication records | GLPI administration logs and session views; authentication source (LDAP, IMAP or external) | Whether step-up authentication events are logged in the version you deploy, and where logs are forwarded |
| Backup and restore records | Database and file backups under your own backup tooling, plus restore test logs | Restore tests are recorded with dates, scope and results, not only backup job success |
| Vulnerability scan records at the baseline cadence | Your scanning tool and the ITSM ticket trail for each finding and remediation | Scan frequency matches the baseline your system is assessed against, such as the monthly cadence in the CJIS Security Policy where it applies |
| Accessibility test results for public portals | Testing performed by you or a third party against WCAG 2.1 Level A and AA, with issues tracked as tickets | Results cover the self-service portal and any contracted web content, with dates for the 2027 and 2028 ADA Title II deadlines |
Questions public bodies ask before hiring an ITSM partner
What drives the cost of open source ITSM for a public body?
The software license is free, because GLPI is distributed under GPL-3.0 and iTop under AGPL-3.0, so the cost sits in the work around it. You pay for implementation and configuration of the CMDB and processes, agent rollout, data migration, hosting, ongoing administration and, if you want them, vendor support subscriptions. Support subscriptions are optional and recurring. As a sourced reference point, Teclib' lists GLPI Network self-hosted subscriptions from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise), and public cloud at 19 euros per user per month. Ask every bidder for a quote that separates one-time work from recurring hosting, support and admin effort.
How long does an open source ITSM rollout take in government?
There is no fixed duration, and the timeline is set by the scope agreed in writing before work starts. The main drivers are the number of entities and departments on a multi-entity setup, the quality of existing asset and contract data, and how many approval steps your governance requires for design, access and go-live. Migration from spreadsheets or a legacy service desk usually takes longer than the software configuration itself. Ask a partner to show the phases, the approval gates and the assumptions behind the schedule, and to name which of those assumptions depend on your data and your decision-makers.
Can our own staff run GLPI or iTop after go-live?
Yes, if you have the administration skills in-house. Running GLPI or iTop means maintaining the web server, PHP and database layers, applying updates, managing user authentication, configuring agents and keeping the CMDB and process rules current. GLPI's update procedure requires backing up the database, files and the config directory, including the glpi.key and glpicrypt.key files, and then running php bin/console db:update, and plugins are suspended after a new version is detected. Many public bodies split the work: internal staff own daily operations and a partner covers upgrades, incident support or periodic reviews under a retainer. Ask the partner which tasks they would hand over and which would stay with them.
Does using open-source ITSM avoid FedRAMP requirements?
Not automatically, and the answer depends on the service model, which counsel should confirm. FedRAMP's scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. Systems used only for a single agency's operations on cloud infrastructure, and not offered as a shared service, are out of scope. An open-source license does not decide this question. If a vendor or a hosted deployment serves multiple agencies or stores federal information, FedRAMP may apply to that service. If you self-host inside your own accredited environment, the question shifts to your own authorization boundary. Ask counsel and your federal sponsor to confirm the scope against OMB M-24-15 before you choose a hosting model.
How do accessibility deadlines apply to an ITSM self-service portal?
State and local government web content and mobile apps, including those provided through contracts or licenses, must meet WCAG 2.1 Level A and AA under the ADA Title II rule. The compliance date is 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts, according to 28 CFR 35.200. A self-service portal for employees or residents falls within that scope if the public entity provides it, including when a partner builds or configures it. Ask the partner to test the portal against WCAG 2.1 AA, document the results and include accessibility fixes in the written scope, and confirm with your legal office which date applies to your entity.
Which asset and contract records do public audits usually request?
Auditors typically ask for a current asset inventory, proof of who owns each asset, software license and contract records, and evidence that changes were approved. In GLPI and iTop, this means linking assets to contracts, suppliers, owners and tickets, and keeping timestamps on changes. The exact evidence depends on your audit body and any framework you are assessed against, so confirm the request list with your internal audit office before designing the CMDB. A partner can configure these links and reports, but the audit requirements themselves come from your governance and the auditor.
How does the ITSM tool connect to government identity systems?
GLPI can authenticate users against its internal database, LDAP directories, IMAP mail servers and other external methods such as REMOTE_USER, tried in that order. For a public body, this means the design must confirm which directory is authoritative, how groups map to entities and roles, and whether a single sign-on method is supported by your identity provider. Confirm the supported methods for your identity platform with the GLPI documentation and your identity team, and test the login order and group mapping in a staging environment before go-live.
What to ask an implementation partner before you sign
Start with entity separation. Ask the partner to show, in writing, how a GLPI or iTop deployment models each department, agency or municipal entity: which objects are shared (such as the CMDB classes, service catalog and contract records), which belong to one entity, and which roles can see or change each entity's tickets and assets. Ask how a central IT team can report across entities without giving every administrator access to every record. Then ask how government identity is integrated and tested. For GLPI, the authentication order is the internal database, LDAP, IMAP and then external methods such as REMOTE_USER, so ask which source is authoritative for staff accounts, how deprovisioning reaches the service desk, and whether step-up authentication is enabled for administrative actions in GLPI 12.0.0. Next, pin down the data and hosting boundary. If the desk will hold criminal justice information or controlled unclassified information, ask which hosting location the partner proposes, whether the cryptographic modules are FIPS 140-3 certified, and which key lengths protect data in transit and at rest. The CJIS Security Policy version 6.1 sets AES with at least 256-bit keys or FIPS 140-3 modules for CJI outside physically secure locations, so the partner should name the exact encryption settings and where key material is stored, and should confirm in writing which scope applies to your data. Ask as well how monthly vulnerability scanning and patching will be run against the desk, the web server and the database, and who signs off on each update. Finally, test the public-facing parts and the paperwork. Ask how any citizen portal or self-service page will be checked against WCAG 2.1 Level AA, which tools and manual reviews are used, and whether the work is covered by the ADA Title II timelines that apply to your entity size. Ask how contracts, licenses and asset records will be migrated, how the partner reconciles counts and totals against the source systems, and who signs off on the reconciled data. Last, ask for the support subscription in a written scope: response targets, covered components, plugin and upgrade handling, and what is excluded. The GLPI Network subscription tiers, for example, are priced by agents, assets and support level, so compare the quoted tier against the scope you have agreed.
