Why GLPI fits public sector IT service management
A public body with several departments or councils sharing one IT estate needs its service desk and asset records to separate work by organization while still giving central teams a single view. GLPI answers the first need with *entities*, which hold tickets, assets, contracts and users for each department, and lets profiles and authorization rules decide who sees what across them. Because GLPI is distributed under the GNU General Public License version 3 and maintained by Teclib', procurement teams can evaluate it as open-source software without a per-seat license decision at the core, while the paid GLPI Network subscriptions remain an optional add-on for support and marketplace plugins. This page does not assume any particular country's procurement or public-sector rules, so confirm with your own legal and procurement staff how an open-source licence and any paid support contract will be classified.
For the team, the practical changes start with ticket routing. Each department's requests should land in its own entity with its own categories, approvers and service levels, and the design of entities, profiles and authorization rules should be agreed with the department heads before any data is loaded. Inventory changes the audit conversation: if hardware and software records are collected automatically by GLPI Agent and reviewed on a schedule, the asset register can serve as evidence of what the body owns and runs. Self-hosting is the sovereignty choice here. Deploying GLPI on servers and in data centers you control keeps asset, user and ticket data under your own governance, and the hosting location, backup copies and administrator access should be written down as part of that decision. Confirm the exact hosting, support and data-residency terms of any managed or partner-hosted option before you rely on it.
Which public sector requirements shape the GLPI build
This table compares the public sector requirements most likely to affect a self-hosted GLPI deployment, what each one asks for, and the build decision it creates. Applicability depends on your jurisdiction, mandate and the data GLPI will hold, so confirm each row with your legal, procurement and security owners. The main takeaway is that hosting location, key custody and portal accessibility are settled during design, before go-live.
| Requirement and source | What it asks for | What it means for the GLPI build |
|---|---|---|
| NIST SP 800-53 Rev. 5 baselines (FISMA) | A federal control catalog with low, moderate and high baselines selecting 149, 287 and 370 controls and enhancements. | Ask the authorizing official which baseline applies, then map GLPI access, logging and change controls to it. |
| FedRAMP scope (M-24-15) | Covers cloud services handling federal information for an agency. Single-agency systems not offered as a shared service are out of scope. | A GLPI instance run for one agency on infrastructure you control may sit outside scope. A shared hosted service needs its own FedRAMP check. |
| CJIS Security Policy v6.1 | Version 6.1 took effect on 26 June 2026. It requires FIPS 140-3 modules or AES-256 for CJI, and vulnerability scanning at least monthly. | Keep criminal justice records out of GLPI unless encryption and scanning are in place. Confirm with your state CJIS Systems Officer. |
| 32 CFR 2002.14(h)(2) and NIST SP 800-171 | Agencies set CUI safeguards on non-federal systems using NIST SP 800-171, unless the CUI category prescribes other safeguards. | Asset records for sensitive systems may become CUI. Host and harden GLPI to the requirements the agency sets and keep evidence of them. |
| ADA Title II, WCAG 2.1 Level A and AA | Web content and apps, including those supplied through contracts or licenses, must conform from 26 April 2027 (50,000 or more people) or 26 April 2028 (smaller entities). | The self-service portal, ticket forms and custom templates are web content. Test plugins and custom pages, not only the GLPI core. |
| NIS2 public administration | Central government is in scope regardless of size. Public administration is high criticality, and Member States may extend it to local bodies. | Confirm whether your council or agency is in scope. If it is, incident reporting and supplier controls for the GLPI hosting must be documented. |
| GDPR Chapter V and EDPB Guidelines 05/2021 | Remote access from a third country, even only displaying data for support, is a transfer. Cloud storage outside the EEA is also a transfer. | Support sessions into GLPI from outside the EEA count as transfers. Restrict support access paths and keep administration inside approved locations. |
| Key custody and foreign access (18 U.S.C. 2713, GDPR Article 48) | US providers must preserve or disclose data in their control wherever it sits. GDPR Article 48 limits foreign disclosure orders to recognized international agreements. | Keep the glpi.key and glpicrypt.key files and database backups under the agency's own control, not a vendor's. |
How entities separate departments, councils and agencies
A ministry with directorates usually has one legal owner but several operational units that should not read each other's work. The simplest pattern is a root entity for the ministry, with a child entity for each directorate or large unit. Smaller directorates can share a parent entity if they hold no sensitive case data and their managers accept shared visibility. Decide early whether assets such as shared printers or network gear belong to the root entity, because moving them later means re-assigning records one by one.
- Root entity for the ministry: Hold central services such as the service desk team, the asset register owner and the security function.
- Child entities per directorate: Separate tickets, assets and contracts for each directorate that has its own budget or data.
- Shared assets at the root: Keep network equipment and shared services visible to the central team only.
- Recursive visibility setting: Decide whether a parent profile sees child entities, and document the answer per profile.
- Naming convention: Use stable entity names that match the official organization chart, not nicknames.
Before the first import, ask the ministry's records office to confirm the current organization chart and who approves changes to it.
A council usually has departments such as housing, social care, highways and finance, plus shared services such as IT, HR and procurement. Those shared services need to see many departments, but departments should not see each other's casework. A workable model places the shared services in a central entity and gives departments their own child entities. Shared service staff then use profiles scoped to the entities they support, rather than a global administrator role. Test this with a small pilot before loading the full asset register.
- Shared services entity: Host the IT service desk and the central asset team with profiles limited to the entities they support.
- Department entities: Give each department its own tickets, locations and budget-linked contracts.
- Cross-entity tickets: Agree how a request that involves two departments is split, copied or assigned.
- Location records: Link buildings to the entity that pays for them, so a shared building does not give one department control of another's assets.
- Pilot before full load: Load one department, check what each profile sees, then load the rest.
Ask the council to confirm which roles can read asset financial data, because contract and purchase fields are often more sensitive than the asset names themselves.
An agency network has several legal bodies that may share a platform but must keep their records apart for legal, audit or contractual reasons. Each legal body should map to its own top-level entity, with clear rules for any shared group function. Where a central body operates the platform for several agencies, it should avoid giving itself a broad profile over every agency's data unless the governing agreement requires it. Confirm the governing arrangement for each body before the entity structure is drawn.
- One top-level entity per legal body: Keep each body's records separable for audit and for any future transfer of functions.
- Central operator profile: Limit it to platform administration and document any exceptions in writing.
- Inter-agency requests: Route them through a defined process, with a named approver on each side.
- Separate contracts and budgets: Keep purchasing records within the body that owns the contract.
- Exit planning: Note which records would need to be exported if a body is merged or closed.
Ask each agency's legal or governance team to confirm the boundaries in writing, since the platform design should follow those boundaries rather than the reverse.
GLPI's user documentation describes sign-in against the 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 a user who exists in the internal database may be matched before the directory, so local accounts can shadow directory accounts if they share a login name. The entity model depends on this order, because a user's entity and profile assignments are usually tied to the directory group they belong to. If the directory structure and the entity model disagree, users can land in the wrong entity or lose access to their records.
- Local account shadowing: Remove or rename internal accounts that duplicate directory logins.
- Directory groups as the source: Map directory groups to entities and profiles where the directory holds the truth.
- IMAP and REMOTE_USER roles: Use these only where the directory or web server SSO layer is not available, and document the trust model.
- Break-glass account: Keep one tightly controlled internal administrator account, with its use logged.
- Directory changes: Plan how a transfer between departments updates the user's entity in GLPI.
Before the first import, confirm with the directory team that group names and organizational units match the agreed entity names.
Most entity problems come from decisions made after data is loaded. Changing an entity assignment later can require re-tagging tickets, assets and contracts, and it can change who can see historical records. Before the first import, the team should agree the entity tree, the profiles for each role, the rules that assign incoming assets to entities, and the owner of each decision. These choices should be written down and approved by the people who own the data, not only the platform team.
- Entity tree sign-off: Get the business owner of each department to approve the tree in writing.
- Profile matrix: List each role, the entities it can read and the actions it can take in each.
- Assignment rules: Define how assets from discovery or import land in the right entity.
- Retention and archive: Decide how records of closed departments are kept and who can read them.
- Test accounts: Verify visibility with one account per profile before go-live.
Ask the implementation partner to show how the profile matrix will be tested, and ask the security team which entity boundaries they will rely on as audit evidence.
Which GLPI modules and integrations matter for public bodies
Public bodies usually need GLPI to answer three questions: what they own, who is allowed to change it, and whether service commitments were met. The cards below cover the modules and integrations that answer those questions, along with the checks to run before you configure them.
Asset inventory with GLPI Agent
GLPI Agent collects hardware and software inventory from managed desktops and servers and sends it to GLPI, which gives an auditor a record that does not depend on manual spreadsheets. Decide which device classes must report, how often, and who owns records for devices that never check in. Confirm with your security team which software fields they need for licence and vulnerability reviews, and test the agent on each operating system in your estate before rollout.
Contracts and financial records
Contract and financial management in GLPI holds licence terms, support agreements and purchase records next to the assets they cover. This supports procurement reviews and renewal planning. Define a contract template per supplier type, record renewal notice dates, and agree with finance who maintains cost centres. Confirm how your procurement rules classify open-source licences and support subscriptions before you enter them.
SLA and OLA calendars
Service levels in public bodies often depend on working hours, public holidays and local closure days. Build calendars for each service desk and attach them to SLAs and OLAs so that response and resolution clocks stop outside agreed hours. Confirm with your service owners which obligations are contractual and which are internal targets, since the two need different escalation rules.
LDAP, Active Directory and web server SSO
Most councils and ministries already run a directory, so GLPI sign-in should follow it rather than create a second set of accounts. GLPI tries the internal database, LDAP directories, IMAP and external methods in a fixed order, so plan which source wins for staff, contractors and administrators. Confirm with your identity team whether web server SSO passes a trusted user name to GLPI, and test removed accounts to be sure they lose access.
Step-up authentication and session revocation
GLPI 12.0.0 adds a view of active user sessions with the ability to revoke them, and step-up authentication for certain administrative actions. Together they limit what a compromised administrator session can change and let an operator end suspicious sessions quickly. Decide which actions your policy treats as sensitive, document who may revoke sessions, and confirm with the vendor which actions trigger step-up in your release before writing the procedure into your access controls.
Knowledge base and service catalog
The knowledge base and service catalog give citizens and staff one place to find answers and request services, which reduces repeated tickets for the same questions. Start with the ten or so requests your service desk handles most often, write articles that match them, and set visibility by profile so internal procedures do not reach the public. Confirm with your accessibility lead how the published content will meet the WCAG 2.1 Level AA requirement that applies to your entity.
What sovereign hosting means for a GLPI instance
Self-hosting GLPI in a body's own data centers or a national provider's facilities changes where the database sits, but it does not settle the transfer question by itself. Under GDPR Article 44, the test is whether personal data reaches a third country, and remote access counts. The EDPB's Guidelines 05/2021 state that access from a third country, even only displaying data on a screen for support or administration, is a transfer. A vendor engineer outside the EEA who opens a GLPI ticket containing staff names, user assignments or location records is therefore making a transfer, and so is a remote session into the server. Support access is the first transfer decision to map. Before signing any hosting or support contract, ask where each support role connects from, who can view the database, and whether jump hosts and session logging keep access inside the EEA. Legal advice is needed for each jurisdiction, because the position depends on the body's legal basis and national rules.
The second question is which transfer tool or adequacy basis applies. The CJEU's Schrems II judgment of 16 July 2020 invalidated the Privacy Shield decision while holding that standard contractual clauses remained valid. Commission Implementing Decision (EU) 2023/1795 finds adequate protection only for US organizations on the Data Privacy Framework List, and an appeal in Case C-703/25 P is pending, so confirm its status before relying on it. Where a provider needs access to data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, EDPB Recommendations 01/2020 state that no effective technical supplementary measure can be envisioned. The CLOUD Act provision at 18 U.S.C. 2713 applies to US providers regardless of where the data is located, so a US-controlled operator in a European data center may still face disclosure orders. Article 48 of the GDPR limits recognition of such orders to those based on an international agreement, such as a mutual legal assistance treaty. Ask counsel to review each provider's ownership, support model and contract terms.
Exit planning belongs in the same review. The EU Data Act, applicable since 12 September 2025, gives customers of data processing services the right to switch to another provider or to on-premises ICT infrastructure, with a maximum two-month notice period and a 30-day transition, and it bans switching charges from 12 January 2027. Those rights matter when a GLPI instance runs on a hosted or cloud service, so the contract should state how the database, attachments, configuration and the glpi.key and glpicrypt.key files will be exported. Without those keys, encrypted values in a database backup may not be recoverable, so the export test must include them. Article 32 also requires providers to take measures against third-country governmental access to non-personal data held in the Union. Confirm with counsel how these rights and obligations apply in your jurisdiction, and do not treat the provider's standard terms as a substitute for that review.
How a public sector GLPI rollout runs in phases
The sequence moves from agreeing entity design and security requirements, through a controlled hosting build and identity integration, to a tested inventory pilot, data reconciliation, accessibility checks and a handover the agency's own staff can run. Each phase closes with an output the owners can sign off before the next one starts.
Agree scope and entity design
Procurement, the security owner and the business owners of each department agree which departments, sites and asset classes the first release covers, and how GLPI entities map to those departments. The team also records the hosting location requirements, data classification and open-source licensing needs that procurement will ask about later. Done means a signed scope document and an entity tree that the security owner has reviewed, with any open questions on hosting jurisdiction assigned to an owner. Confirm with your own legal and data protection staff which transfer and sovereignty rules apply to your data before the hosting decision is final.
Build hosting and database to prerequisites
The infrastructure team provisions servers in the agency's own environment and installs GLPI against the prerequisites in the installation documentation. That covers the PHP version, a supported MySQL or MariaDB version, and a web server whose document root points to GLPI's public directory with URL rewriting routed through index.php. Done means a fresh instance answers only through the public directory, the installer completes, and the team has checked the version pairings against the current documentation for the release they chose, including whether they plan to use the official Docker image.
Integrate directory and single sign-on
The identity team connects GLPI to the agency's directory and, where required, to its web single sign-on. GLPI tries authentication sources in a set order, so the team must decide whether the internal database remains a fallback for break-glass administrator accounts and document that choice. Done means test users from each department sign in through the expected source, profiles and entity assignments resolve correctly, and the break-glass path has been tested and recorded.
Run an agent-based inventory pilot
The desktop support team deploys GLPI Agent to a single department's devices and confirms that hardware and software inventory arrives in the correct entity. The pilot tests the deployment method, the server address the agents report to, and how the team handles machines that move between departments. Done means the pilot department's device count in GLPI matches a list the department confirms by hand, with any gaps explained and the deployment steps written down for the wider rollout.
Import data and reconcile records
The asset and records team loads existing registers, such as spreadsheets, contract lists and older tool exports, into GLPI and then compares them against the inventory the agents collected. Duplicates, missing owners and conflicting serial numbers are resolved with the department that owns each asset. Done means a reconciliation report shows each asset as matched, corrected or accepted as a known exception, and the team has a repeatable import method for the remaining departments.
Test portal accessibility
The team tests the self-service portal and the forms that citizens or staff use against the accessibility standard that applies to the agency, and records the findings with owners and fixes. Done means a written test result covers the pages in scope, each defect has an owner, and the remaining issues are scheduled into the change process. Confirm with your legal or accessibility office which standard and compliance date apply to your entity, since these depend on jurisdiction and size.
Hand over with the update procedure
The implementation partner or internal platform team hands operations to the agency's staff, including a runbook for the update procedure. Before any upgrade, the operator backs up the database, the application files and the config directory, including the glpi.key and glpicrypt.key files, then replaces the application files and runs the database update command. After a major update, plugins are suspended until someone reactivates them and checks them. Done means the operations team has performed a restore test in a non-production copy, the key files are stored under the agency's access controls, and a named owner has signed the handover.
Which compliance frameworks turn GLPI records into evidence
GLPI inventory, asset, ticket and access records can support several frameworks at once, but each one asks for different evidence. The cards below name the frameworks public bodies most often face and what a GLPI configuration needs to show, while auditors and certification bodies decide whether the evidence is sufficient.
NIST SP 800-53 asset inventory controls
NIST SP 800-53 Rev. 5 is the federal control catalog, and its SP 800-53B baselines select 149 controls and enhancements at low, 287 at moderate and 370 at high. For GLPI, the asset and configuration controls are where inventory records matter most: a current component list, owners, and change records tied to each asset. Check that GLPI Agent inventory runs on a schedule and that stale assets are reviewed rather than left to age silently.
CJIS Security Policy encryption and scanning
Police-related systems that hold criminal justice information fall under the FBI CJIS Security Policy, and version 6.1 took effect on 26 June 2026. It expects FIPS 140-3 validated modules or AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations, plus vulnerability scanning at least monthly. A GLPI instance that records devices linked to CJI systems should be scoped out of that data, or hosted to the same standard, and its scanning schedule documented.
CUI handling under NIST SP 800-171
Under 32 CFR 2002.14(h)(2), federal agencies use NIST SP 800-171 to set protection requirements for controlled unclassified information on non-federal systems, unless the CUI category prescribes other safeguards. A contractor or partner that runs GLPI for a public body and records CUI-related assets or tickets inherits those expectations. Confirm which ticket fields and attachments may carry CUI, and who may view them through entity and profile rules.
ADA Title II accessibility for the 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. Entities serving 50,000 or more people must comply from 26 April 2027, and smaller entities and special districts from 26 April 2028. A self-service GLPI portal used by residents or staff counts as covered web content, so the accessibility review belongs in the rollout plan, along with the theme and any custom forms.
NIS2 applicability to public administration
NIS2 covers central government entities regardless of size and lists public administration as a sector of high criticality. Member States may extend it to local public administration, and it excludes entities working in national security, public security, defense or law enforcement. Whether a council or agency falls in scope depends on national transposition, so confirm that with the relevant authority. If it applies, incident handling, supplier security and asset records in GLPI become part of the evidence set.
GDPR and Data Act expectations for hosting and support
Every transfer of personal data to a third country, including remote access for support that only displays data on a screen, must meet GDPR Chapter V. The Data Act also requires providers to take measures against third-country government access to non-personal data held in the Union. For GLPI, this means the hosting location, backups, and support access paths must be documented, and vendor or partner staff outside the EEA should be treated as a transfer until assessed. Ask every provider for its access log and support location.
What public bodies ask before hiring a GLPI partner
What drives the cost of a GLPI implementation for a public body?
Scope drives cost more than anything else: which modules go live, how many entities the organization needs, how many integrations must be built, how messy the source data is, and where the platform is hosted. Entity count matters because each department or district that needs its own ticket queues, visibility rules and reporting adds configuration and testing. Data migration cost depends on whether records come from clean spreadsheets or from several legacy asset registers. Hosting adds cost for servers, backups and the database, and that cost recurs. Ask any partner for a quote built from a written scope that lists each of these items separately, with the one-time work (design, build, migration, training) shown apart from recurring work (updates, backups, support). DeployOpen does not publish a price list, and its quotes follow from the agreed scope.
How long does a GLPI rollout take in a public body?
The pace is usually set by approvals and inputs rather than by the software. Procurement and security sign-off, directory cleanup in Active Directory or LDAP, and agreement on which department owns which entity can each take longer than the technical build. A pilot with a small set of departments lets the team test entity rules, authentication and inventory agents before wider rollout. Ask the partner for a timeline that names the dependencies it expects from your side, and for the phases it will deliver against. Any duration should appear in the signed scope, not in a sales conversation.
What must our organization provide before the project starts?
Three things decide whether the project keeps its plan. First, read access to the directory (LDAP or Active Directory) so that authentication and group mapping can be designed and tested. Second, a list of asset sources, such as existing registers, procurement records, spreadsheets and network discovery, with an owner for each. Third, a named person who can decide entity boundaries, approval routes and who sees which records. Without that owner, design decisions stall. Confirm these inputs in writing before the scope is signed, and confirm which of them your security team must approve.
Can our own staff run GLPI after handover?
Yes, if the handover includes the update procedure and your staff rehearse it. The GLPI update procedure requires a backup of the database, the files and the config directory, including the glpi.key and glpicrypt.key files, before application files are replaced and php bin/console db:update is run. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so plan that step into every upgrade window. Ask for runbooks, a tested restore, and a clear list of recurring tasks such as backups and notification queues. Whether your team takes this on alone depends on its skills and capacity, which you should assess before deciding.
Do we need a GLPI Network subscription, and what does the price list say?
A GLPI Network subscription is optional. GLPI itself is distributed under the GNU General Public License version 3, so a self-hosted instance does not require one. The GLPI Network subscriptions page lists public cloud at 19 euros per user per month and private cloud at 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), including level 3 support and marketplace plugins. Those figures are list prices from the vendor's page and may change, so confirm the current terms with Teclib' before a procurement decision. Also check whether any plugin you need is available only under a subscription.
Can DeployOpen support air-gapped or national hosting?
DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For a GLPI deployment, that means the instance, database, agents and backups can run where your sovereignty rules require. Air-gapped work needs extra planning for offline updates, package delivery, time sources and how inventory agents report. Confirm the hosting location, network rules and who holds administrative credentials in the written scope. DeployOpen does not issue audit reports or certifications, so any compliance assessment for the hosting model will come from an independent auditor.
Does a sovereign hosting decision change what compliance evidence we need?
It can. Public bodies that handle regulated data may need to show where data is stored, who can access it from abroad, and how cloud providers respond to foreign legal requests. Those questions apply to the hosting model, not to GLPI's license. A self-hosted GLPI instance in your own data center keeps those answers under your control, but it still needs documented access, backups and vulnerability management. Frameworks such as NIST SP 800-53 Rev. 5 and the FBI CJIS Security Policy set controls that your auditor may test against. DeployOpen prepares systems, controls and evidence for those assessments, but the assessment itself belongs to an independent auditor.
How open-source licensing changes procurement and total cost
GLPI is distributed under the GNU General Public License version 3, so the licence itself costs nothing to acquire, copy or run. For a public body, that changes the procurement file: there is no per-seat software licence to tender, renew or justify each year. The money moves to the work around the software. You still pay for planning, implementation, customization of entities and profiles, integration with your directory and identity provider, hosting in your own infrastructure, backups, upgrades and support. Ask every bidder to price those items separately so the file shows what the public body is buying and what recurs after go-live.
Teclib', the company that maintains GLPI, also sells optional vendor services under GLPI Network. The published prices are 19 euros per user per month for the public cloud and 21 euros per user per month for the private cloud, with a 25-user minimum on the private option, according to the GLPI Network subscriptions page. Self-hosted subscriptions range from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise), and include level 3 support and access to GLPI Network marketplace plugins. These are vendor subscriptions, not a requirement. A council can run GLPI without them, but should compare them with a partner quote if it needs vendor-backed support or marketplace plugins. Confirm current prices and terms directly with the vendor, since these figures can change.
A written quote from an implementation partner should separate one-time work from recurring work. Ask for the scope of each entity and profile, the directory and SSO integration, the hosting assumptions and who provides the servers, the upgrade plan for GLPI 11 and 12, and the support hours and response targets, stated in the contract rather than implied. Ask which plugins are included, who owns their maintenance, and what happens to fees if a plugin must be replaced. Require the quote to state the assumptions behind each estimate, such as user numbers and asset counts, so you can re-price the work if the scope changes.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports GLPI inside the infrastructure your public body controls, whether that is a government cloud account, a data center or an air-gapped network. Engagements are fixed-scope, so the entity structure, identity sources, agent rollout and upgrade path are agreed in writing before build work starts.
How we scope
- Map your departments, agencies and sites to GLPI entities and document the access rules between them.
- Confirm which identity sources, such as LDAP directories or web server SSO, sign-in will use.
- Agree in writing the hosting location, data residency requirements and the systems GLPI must integrate with.
How we build
- Install GLPI on your web server, database and PHP versions, with the public directory as document root.
- Configure entities, profiles, authorization rules and the GLPI Agent rollout for inventory across departments.
- Test sign-in, role separation, backups and restore, and the plugin reactivation steps before any go-live.
How we hand over
- Document the configuration, key storage, backup procedures and the update runbook your team will operate.
- Provide asset inventory records and configuration evidence your internal audit or external auditors can review.
- Run a knowledge transfer session with your administrators, and note that auditors, not DeployOpen, issue any assessment or certification.
How we support
- Offer ongoing support, upgrades and periodic security testing as a retainer, scoped separately from the build.
- Plan GLPI 11 and 12 upgrades as their own written scope, including plugin data migrations and backups first.
- Confirm response expectations, service levels and retainer terms with your team before signing any agreement.
