Why open source ITSM for manufacturing needs plant context
When a line stops, the first ticket usually lands in a generic queue with no site, no line and no indication of whether the failed device is a PLC, a historian server or a laptop. A manufacturing operations lead needs the service desk to know where the affected asset sits, which line depends on it and whether a production change window is open before anyone touches it. A plain helpdesk cannot answer those questions, so the ITSM design has to carry plant context from the start. The short answer is GLPI or iTop, self-hosted inside the plant's own infrastructure, with the CMDB modeled around sites and production lines. Which of the two fits depends on how deep the CMDB model must go and how many integrations with monitoring, historians and procurement the plant needs.
Three design decisions follow from that answer. First, OT and IT inventory should be kept distinct: control-system assets on segmented networks need their own classes, owners and discovery rules, so that a scan or agent rollout never reaches into a controller network without a plan. The ISA/IEC 62443 series, which organizes requirements into general, policy, system and component groups, is the reference most plant security teams will ask about, and ANSI/ISA-62443-2-1-2024 addresses the asset owner's security program. Second, change records for production systems need a maintenance window attribute and an approval step that operations, not only IT, can sign. Third, incidents should link to a line or site object so that stoppage history can be read by plant. Ask any implementation partner how they will model these links and who maintains the OT asset list after go-live.
Confirm the platform-specific details with the vendor and in your own environment before committing. The GLPI 12.0.0 release, published on October 7, 2026, is the current major version, and GLPI's installation documentation lists supported database and PHP versions that you should check against your standard build. Also confirm whether your sites need separate entities or only location trees, because that choice shapes reporting and access control. Finally, treat the answer as a starting point: a plant with a heavy OT estate, a regulated product line or a multi-site historian integration may need the deeper modeling and integration effort that iTop's customizable CMDB supports.
Which manufacturing requirements shape the ITSM build
This table maps each manufacturing requirement to its source and to what it changes in an ITSM build on GLPI or iTop. Read it as a list of record-keeping and evidence duties: the ITSM tracks assets, changes and incidents, while safety and control decisions stay with engineering and operations teams.
| Requirement | Source | What it means for the build |
|---|---|---|
| Asset owner security program and zones and conduits | ANSI/ISA-62443-2-1-2024, ANSI/ISA-62443-3-2-2020, ANSI/ISA-62443-3-3-2013 | Model OT assets by zone and conduit in the CMDB so each asset records its security zone, owner and connections. Confirm with your OT security lead how zones are named before building classes. |
| OT asset inventory across PLCs, SCADA and DCS | NIST SP 800-82 Rev. 3 (September 2023) | Add OT asset classes for PLCs, SCADA servers, DCS nodes and HMIs. Passive or manual discovery is usually preferred on production networks, so confirm which methods plant engineering accepts. |
| Performance, reliability and safety priorities | NIST SP 800-82 Rev. 3 (September 2023) | Tag assets whose change could affect production or safety. Route those records through engineering sign-off and do not treat the ITSM workflow as the control that protects the process. |
| Manufacturing as a critical sector with incident reporting | NIS2 Annex II (NACE Rev. 2 divisions 26 to 30), Directive (EU) 2022/2555 | Link incident tickets to affected lines and sites so timestamps support reporting. Confirm with counsel whether your entity is in scope, since this depends on size and classification. |
| Early warning, notification and final report timelines | NIS2 Article 23(4): 24 hours, 72 hours and one month | Set incident categories and timers that show when detection, early warning, notification and final report occurred. The ITSM stores the trail; reporting decisions remain with the response team. |
| Reporting of actively exploited vulnerabilities and severe incidents | Cyber Resilience Act Article 14, applicable from 11 September 2026 (Article 71(2)) | Applies to manufacturers of products with digital elements. Record vulnerability and incident cases against the product and affected customer installations so reporting evidence is traceable. |
| Protection against connected devices or remote devices | Machinery Regulation (EU) 2023/1230, Annex III 1.1.9, applicable from 14 January 2027 | Track remote access and added devices on machines as configuration items with approvals. The ITSM records these connections but does not replace the technical protection the machine design requires. |
| Change control for production systems | ANSI/ISA-62443-2-1-2024 and plant change procedures | Use change records with engineering and operations approval steps, maintenance window fields and back-out plans. Emergency changes on lines need a defined path that engineering signs off afterward. |
What data and systems an ITSM must hold for plants
An ITSM serving a plant has to hold two different kinds of asset record side by side. Corporate IT assets such as laptops, servers and virtual machines are usually discovered by software. Plant assets include programmable logic controllers (PLCs), operator panels (HMIs), process historians, manufacturing execution system (MES) servers, SCADA servers, industrial PCs, managed switches and firewalls in the cell network, and vendor-maintained equipment such as robots, test rigs and packaging machines whose controllers the supplier manages under a service contract. Each class needs its own record type, and the record should name the owning line, cell and site, the vendor support contact, the firmware or operating system version, and the physical location. Those fields are what make an incident or change on a line answerable later, so define them before any import. Confirm with operations which fields the plant already keeps in engineering documents so you do not build a second, conflicting source.
Many OT devices cannot run a standard inventory agent. A PLC runtime, a legacy HMI or a vendor appliance may be unsupported by the vendor for third-party software, and an agent install can change timing or trigger a warranty dispute. For these assets the CMDB record is usually populated manually from engineering drawings, vendor documentation and walkdowns, and it is refreshed from passive observation only where the plant's security team has approved a monitoring approach. Ask the control engineers and the OT security owner in writing which device classes may receive an agent, which may only be recorded by hand, and who signs off on any network scan. Passive discovery tools and manual entries should be kept distinct in the data, with a field that shows how each record was obtained and when it was last verified.
Tickets become useful on a plant only when they point to a line, cell or site, not just a host name. Link each incident and change record to the affected configuration item and to a location object that reflects the production hierarchy used by operations. Maintenance windows should be calendar objects in the ITSM, tied to the line or cell they cover, so a change request can be checked against planned downtime and a production freeze before approval. Confirm with production planning how far in advance windows are booked, who may release a window early, and whether emergency work can override a freeze. Also confirm which records must be exported to the MES or historian so both systems describe the same line state, because a mismatch between a ticket and the production schedule is one of the more common reasons plant changes are approved at the wrong time.
How segmented plant networks change the deployment
The corporate IT zone is the simplest environment for a GLPI or iTop server. It usually sits alongside the enterprise directory, the help desk users and the procurement systems, so the server, its database and its web front end can be placed where the IT team already runs line-of-business applications. Inventory agents on Windows, macOS and Linux endpoints report to the server directly, and GLPI Agent network discovery can scan the office subnets that the IT team owns. The OT zone is not reached from here, so the corporate instance should hold only what it can see directly.
- Server placement: Host GLPI on a web server whose document root points to the public directory of the GLPI installation, with URL rewriting in place, and back it with MySQL 8.0 or MariaDB as the database.
- Agent reach: Endpoints and servers in the corporate subnets report over the network paths that the agents already use.
- Discovery scope: Network discovery covers corporate address ranges only, and scan ranges should be reviewed so that no plant subnet is scanned by accident.
- Data boundary: Asset and ticket data stays inside the corporate zone, so no cross-zone transfer rules apply to this tab.
- Plant references: Record the plant, line or site on each corporate asset, so that incidents raised at the plant can be traced to the correct location.
Confirm with your network team which corporate subnets may be scanned and whether the GLPI database service is reachable only from the application tier.
A plant DMZ or shared services segment sits between the corporate network and the production networks. Many manufacturers place the ITSM server here, or a read-only copy of its data, because it must serve plant technicians and receive information from both sides without granting the corporate network direct access to control systems. Traffic that crosses this segment should be limited to named flows, such as ticket submission from plant users and asset or status updates from a plant collector. Firewall rules and the change records that approve them become part of the ITSM evidence trail.
- Server placement: The GLPI or iTop instance can run in the DMZ for plant access, with its database kept in the same segment or in the corporate tier under strict port rules.
- Agent reach: Plant workstations and shared servers report through a local collector or relay, not through direct paths into the OT zone.
- Boundary crossing: Use a reviewed relay or a one-way export for data that leaves the DMZ, and log each transfer as a change.
- Discovery: GLPI Agent discovery can run from a host in this segment against plant office and shared services ranges that the plant owner approves.
- Access control: Separate accounts for plant technicians, with authentication sources reviewed for the segment, reduce the reach of compromised credentials.
Confirm with your OT and security teams which flows are permitted, who owns each firewall rule and how the DMZ host is patched and backed up.
The isolated OT zone holds PLCs, SCADA servers, historians, HMIs and other industrial control systems. In most plants, no ITSM server or general inventory agent should be installed or allowed to scan inside this zone, because active discovery and agent traffic can disrupt fragile controllers. The OT asset list is therefore built passively or manually, then brought into the ITSM record through a controlled path. ISA/IEC 62443 and NIST SP 800-82 Rev. 3 both treat operational reliability as a primary requirement, so any discovery method must be agreed with the plant engineers before it is used.
- Server placement: Keep the authoritative OT records outside this zone, and do not expose the GLPI or iTop server to OT networks.
- Agent reach: Inventory is collected by the OT engineers, either from engineering workstations or from vendor documentation, and reviewed before import.
- Boundary crossing: Data moves out through a one-way export or a reviewed relay, and each file is checked for expected fields before it is loaded.
- Air-gapped plants: Where no network path exists, use manual import of exported files, with the file hash and the person who approved the import recorded on the ticket or asset.
- Discovery: Active network discovery is normally excluded from this zone, and any passive method should be confirmed by the plant engineers.
Confirm with the plant engineers which devices are safe to query, which transfers are permitted and how each import is verified and recorded.
GLPI or iTop for manufacturing: which fits which plant
Plants differ in how much of their estate is discovered automatically and how much of it must be modeled as lines, cells and control relationships. The cards below separate those needs, then cover the front desk for plant support and the commercial options that sit alongside the open-source releases.
GLPI for inventory-led plants
GLPI fits plants where the main problem is knowing which workstations, servers, thin clients and shop-floor PCs exist and what software they run. It covers tickets, assets, contracts and inventory in one application under GPL-3.0. GLPI 12.0.0 was published on October 7, 2026. Deploy GLPI Agent on Windows and Linux hosts to collect inventory and run network discovery, and confirm which OT-adjacent devices the agent can reach without touching control networks.
iTop for line and cell models
iTop fits plants that need the CMDB to reflect how production is built: sites, production lines, cells, PLCs, HMIs and the links between them. Its model is customizable and licensed under AGPL-3.0. Version 3.3.0 was published on September 15, 2026. Before choosing it, confirm the data model can hold your asset hierarchy and that your team can maintain the model after go-live.
Agent-based discovery and its limits
GLPI Agent is the successor to FusionInventory Agent and runs on Windows, macOS and Linux. It gathers hardware and software inventory and can perform network discovery and package deployment. On plant networks, agent rollout must be agreed with OT engineering, because scanning or agent traffic can disturb fragile controllers. Treat agentless discovery of PLCs and controllers as a question to validate in a test segment, not a default.
Zammad or FreeScout for plant support
A separate front desk makes sense only when plant staff, contractors or vendors submit requests outside the IT service desk, for example through email or a shared inbox. Zammad is licensed under AGPL-3.0 and FreeScout under AGPL-3.0 as well. Keep the ticket record in the ITSM platform and link it to the asset, so line and site context is not lost when a request is answered from the helpdesk.
GLPI Network subscriptions
The open-source release is free to run, but the work to install, configure, integrate and maintain it is not. GLPI Network publishes subscription options for managed and self-hosted use, including a public cloud tier at 19 euros per user per month and self-hosted tiers from 100 euros per month. Ask what each tier includes for support response, plugin coverage and upgrade help, and whether it covers the plant-specific configuration you need.
Confirm capabilities with vendors
Plant requirements such as linking incidents to a specific line, scheduling maintenance windows against production calendars, or enforcing change approval for controllers depend on configuration, plugins and custom development. Ask GLPI and Combodo, or your implementation partner, to demonstrate each requirement on a copy of your data model before committing. Record the answers in your requirements document.
Integration points between ITSM and plant systems
A manufacturing ITSM rarely sits on one network or serves one plant. Each integration below links the service desk to a plant system, and each one needs a decision about direction, data ownership and who approves changes, agreed with plant engineering at every site.
Monitoring and SCADA alarm feeds
Alarm and monitoring events from SCADA, historians and network monitoring can open incidents automatically, but a raw alarm stream floods the queue. Decide which alarm classes create tickets, which are only logged, and which page an on-call engineer. Confirm with plant engineering that the feed is one-way from the OT side and that no service desk action writes back to a controller. Test the mapping with a sample of real alarm types from each line before go-live.
Historian and MES asset reconciliation
Historian and MES systems hold the best record of which PLCs, HMIs, drives and line controllers are running and under which site or cell. Reconcile that data against the CMDB on a schedule, so each controller maps to a line, site and owner. Ask who owns the matching key, such as hostname, serial number or asset tag, and what happens when two sources disagree about a device. Keep the reconciled record read-only for OT systems until plant engineering signs off.
Directory and mail-based authentication
GLPI's user documentation describes authentication against the internal database, LDAP directories, IMAP mail servers and other external methods, tried in that order. For a plant, the order matters: a local fallback account protects administrators when the directory is unreachable, while shop-floor users should not gain console rights through a mail login. Confirm which accounts exist in each site, who approves privilege changes, and how service accounts are rotated. Plan this with the identity team before the first site rollout.
Procurement and vendor contracts
Many production systems are maintained by equipment vendors under separate support contracts, warranties and remote access agreements. Link each vendor contract, service level and renewal date to the assets it covers, so a fault on a line shows who must respond. Ask procurement to supply contract records in a format that imports cleanly, and confirm which vendors require change notices before any work on their equipment. Missing contract links are a common gap after an integration is first built.
Reviewed export path for OT data
Exports from ITSM into OT networks, or from OT into IT, should pass through a defined and reviewed path rather than an ad hoc file copy. Document the transfer method, the data fields allowed, the approver, and the retention of each transfer log. Relate the design to the ISA/IEC 62443 series, which organizes industrial security requirements into general, policy, system and component groups. Have plant engineering and the OT security owner review the path before it carries any production data.
How a plant ITSM rollout runs, phase by phase
The sequence moves from a site and zone survey to a tested CMDB, a pilot at one plant, controlled change and incident handling, and a cutover that stays current after go-live. Each phase produces a record that engineering, quality and security can check before the next one starts.
Survey sites, zones and asset classes
Plant engineering, controls staff and IT walk each site and map the zones and conduits that separate business networks from production networks. The team lists asset classes such as PLCs, HMIs, historians, robots, line PCs, network switches, label printers and vendor laptops, and records which ones can run an agent and which must be inventoried by hand. The output is a zone and asset class register signed off by the site engineering lead, which also sets the boundary for any discovery scan that touches control networks.
Model sites, lines and cells in the CMDB
The team builds the CMDB model around the hierarchy the plant actually runs: enterprise, site, area, line and cell, with each asset linked to the line it serves and to its owning team. Relationships to business services, such as the order system or the MES feed, are defined so an incident on one cell shows its downstream impact. Naming rules and mandatory fields are agreed with engineering. The output is a reviewed data model and a test set of records that the plant teams confirm reflects how their lines are organized.
Run a pilot at one plant
One plant is selected for a pilot that exercises the full path: inventory, ticket intake, a change record and an incident linked to a line. The pilot uses the same tooling planned for every site so that gaps surface early. Operations, maintenance and the security team review what the pilot produced, including whether asset records match what the floor walk found. The output is a documented list of defects, process changes and open decisions, with a go or no-go decision recorded by the steering group.
Roll out agent and manual inventory
Inventory agents are deployed to IT-managed endpoints such as office workstations, servers and supported line PCs, after the change process has approved the deployment method for each network zone. OT devices that cannot take an agent are recorded through a manual, supervised process, with the owning engineer confirming make, model, firmware and location. Passive discovery is used only where engineering has agreed it is safe for the device class. The output is an inventory coverage report per site listing agent-managed assets, manually recorded assets and known gaps with an owner for each.
Approve change and maintenance window process
Engineering and quality leads co-author the change workflow for production systems, defining which changes are standard, normal or emergency, who approves each type, and how a maintenance window is requested, booked and closed against a line. Quality confirms where a change to a validated system needs additional evidence. The team tests the workflow with real change records from the pilot. The output is an approved change procedure, an approval matrix and a maintenance calendar that the plant schedule and the ITSM queue both read from.
Configure incident routing and NIS2 timestamps
Incident categories are mapped to the affected site, line and cell, with routing rules that send OT-impacting tickets to the right on-call engineers and keep the corporate desk separate where the operating model requires it. Where the plant falls in scope of NIS2, the team defines which fields record the time of detection, early warning, incident notification and final report, and who owns each deadline. The output is a tested routing matrix and a reporting checklist that compliance has reviewed against the entity's own obligations.
Cut over and maintain after go-live
Remaining sites are migrated in an order agreed with operations, with frozen change windows and a rollback path documented for each step. Open tickets and legacy asset records are reconciled against the new CMDB before the old tools are retired. After go-live, owners review inventory drift, stale records and change outcomes on a set schedule, and the platform receives updates through a documented procedure. The output is a signed cutover record, a reconciled asset register and a post-go-live operating calendar that names the person responsible for each review.
Evidence auditors and regulators ask for from plant ITSM
This table maps the records a plant is likely to be asked for to the ITSM component that produces them. Read each row as a request from an auditor or regulator, then check whether your GLPI or iTop design can produce that record with timestamps, approvals and links to the asset it concerns. Confirm the exact obligations with counsel and your certification body, since applicability depends on your sector, products and jurisdiction.
| Evidence | What the regulator or auditor asks | Which ITSM component produces it |
|---|---|---|
| OT asset inventory | A current list of industrial control assets, their zones, owners and firmware, with proof it matches the network | CMDB asset classes for PLCs, HMIs and SCADA servers, fed by GLPI Agent or manual entry where agents cannot run |
| Change approvals for production systems | Who approved a change to a line controller, when, what was tested and how it could be backed out | Change records linked to the affected OT asset and a documented approval workflow with the maintenance window |
| Emergency change justification | Reason an out-of-window change was made on a running line, and the review that followed | Change record flagged as emergency with a retrospective approval step and a linked incident |
| NIS2 incident timeline | Timestamps for the early warning (24 hours), incident notification (72 hours) and final report (one month) | Incident tickets with detection, triage and notification timestamps, plus CMDB links to affected lines or sites |
| Vulnerability and supplier records under CRA Article 14 | Records of actively exploited vulnerabilities in products you make or operate, and the supplier components involved | Problem records linked to component and supplier entries in the CMDB, with dated status changes |
| Maintenance window history | Evidence that planned downtime was scheduled, approved and kept within agreed limits for each line | Planned changes or recurring maintenance tasks with start and end times, and completion notes |
| Electronic records and signatures (pharma-linked plants) | Under 21 CFR Part 11, electronic records must be trustworthy and signatures must be attributable and controlled | Confirm with your quality team whether ticket approvals and audit trails meet Part 11 controls before using them as GxP evidence |
How much does open source ITSM for a plant cost to implement?
What drives the cost of implementing open source ITSM in a plant?
The cost is driven by scope and effort more than by the software licence, because GLPI and iTop are open-source and there is no per-user licence fee for the core platform. The main cost components are the plant-specific configuration (asset classes, CMDB model, change and maintenance-window workflows, line and site relationships), discovery and inventory rollout across the estate, data migration from spreadsheets or an older desk, integrations with monitoring and identity, and administration after go-live. Ask any quote to break these out separately, and to state which items are one-time and which recur, such as support subscriptions, hosting, and ongoing administration. Costs rise with the number of sites, the number of OT assets that need manual or segmented-network handling, and the number of integrations.
How long does it take to reach a working pilot for plant ITSM?
The time to a working pilot depends on scope, and no fixed duration applies to every plant. A pilot usually needs an agreed list of in-scope lines or sites, a defined set of asset classes, the change and incident categories the plant will use, and a test instance that the plant team can review. Timing shifts with the number of sites, the state of existing asset data, and how quickly the plant can approve workflows and maintenance-window rules. Ask any implementation partner to state the pilot scope, its entry and exit criteria, and the dependencies on the plant side in writing before work starts, since most engagements are fixed-scope and timelines are agreed in writing.
What does the plant team need to supply before implementation starts?
The plant team typically supplies the knowledge that only it holds, and this is often the critical path. Expect to provide:
- A list of production lines, cells and sites, with their owners and shift patterns
- Existing asset registers, PLC and HMI lists, network diagrams and any spreadsheet inventories
- Current change approval rules, including who may approve changes to production systems and how emergency changes are handled
- Maintenance-window calendars and the production stop rules that govern them
- Named contacts from operations, maintenance, OT engineering and IT security
- Access to test or staging environments, and written decisions on which OT assets may be touched by discovery tools
Confirm these items with the plant before the scope is signed, because missing ownership data is a frequent cause of delay.
Can an internal IT team implement open source ITSM for a plant alone?
An internal team can implement GLPI or iTop alone if it has the skills and the time, and many teams do part of the work themselves. The platform is open source and you own the deployment in your own infrastructure. The harder parts are usually the plant-specific CMDB modeling, safe discovery on segmented OT networks, change workflows that match production governance, and keeping the configuration accurate as lines change. A split model is common: the internal team owns day-to-day administration and the business process, while an implementation partner handles the configuration, integrations, hardening and documentation. DeployOpen implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms in the client's own infrastructure, and most engagements are fixed-scope. Decide the split in writing before the quote.
How does GLPI Network pricing compare with self-hosting GLPI in a plant?
GLPI Network is a managed service from Teclib', and its published prices differ from self-hosting costs, which are mostly internal effort and infrastructure. According to the GLPI Network subscriptions page, the public cloud option costs 19 euros per user per month and the private cloud option costs 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. Self-hosting removes the per-user fee but moves hosting, patching, backups and upgrades to your team or partner. For plants with OT networks that cannot leave the site, the comparison usually favors self-hosting, but confirm data residency and segmentation requirements first. Check the current prices on the subscriptions page before comparing.
Can GLPI Agent inventory OT assets on a plant network?
GLPI Agent can inventory many IT assets on Windows, macOS and Linux, including network discovery and inventory, but OT assets need a case-by-case decision. The agent collects hardware and software inventory and can perform network discovery, and it is the successor of FusionInventory Agent. Many PLCs, HMIs, controllers and legacy systems cannot run a general-purpose agent, and active scanning can disrupt fragile industrial devices. For these assets, plan for passive or manual records, imports from engineering documentation, and discovery windows agreed with OT engineers. ISA/IEC 62443 and NIST SP 800-82 Rev. 3 both describe asset and zone handling for industrial systems, so align the inventory approach with those references and with your OT security owners before any scan runs.
How should a plant handle NIS2 incident reporting timelines in ITSM?
Manufacturing is a critical sector under NIS2 Annex II, so in-scope entities should design incident records to support the reporting clock from the start. Under Article 23(4), significant incidents require an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. Configure the ITSM tool so each incident records detection time, affected lines or sites, linked CMDB assets and classification fields, because timestamps and links become the evidence trail. Confirm with your legal and compliance team which entity category applies to your plant, since fines under Article 34(5) differ for essential and important entities. Build the reporting workflow with those teams, and test it with a tabletop exercise before go-live.
What ongoing costs should a plant budget for after go-live?
Recurring costs usually include hosting, backups, patching and upgrades, administration of the CMDB and workflows, support subscriptions if you choose them, and the time needed to keep asset records current as lines change. GLPI 12.0.0 was released on October 7, 2026, and upgrades require a database, file and configuration backup, followed by the update procedure documented by the project, so plan regular maintenance windows. Plugins are suspended after a new version is detected and must be reactivated after major updates, which adds testing effort. Ask any partner to separate one-time implementation fees from recurring retainers, and to state what the retainer covers, such as upgrades, security fixes and continuous testing.
What to ask an implementation partner before a plant pilot
Start with how the partner models OT zones. Ask them to show, in a test instance, how a cell, line, controller and site relate to one another and where a zone boundary is recorded, since the ISA/IEC 62443 series organizes the work around zones and conduits. Ask who in your organization approves zone assignments and whether the model can store the segment or VLAN for each asset without mixing it into the corporate network view. Ask how inventory is collected without touching PLCs: passive discovery, manual entry from engineering documents, or agent installation only on IT hosts such as engineering workstations and historians. A partner who proposes active scanning of controllers during a pilot should be asked to justify it against your plant safety rules and vendor warranties.
Next, test change control against production reality. Ask how a change record links to a maintenance window, who must sign off engineering impact, and what happens when a window is missed or moved. Request a sample change that touches a line controller, showing the approval chain, the back-out plan and the link to the incident record if the change fails. For NIS2 evidence, ask how timestamps are created, whether the server clock is synchronized, and how an early warning, notification and final report can be traced back to the original ticket, CMDB entry and asset history. Confirm that edits to closed records are logged. Under NIS2, the 24-hour, 72-hour and one-month reporting clocks depend on these times being trustworthy.
Finally, ask how upgrades will be tested. GLPI suspends plugins when it detects a new version and requires them to be reactivated after major updates, so a pilot should include a staging copy of the database, file and configuration backups, including the glpi.key and glpicrypt.key files, and a dated checklist for each plugin. Ask whether the partner's upgrade test covers your custom plant fields and inventory agents. Then ask what the support subscription covers: which GLPI Network tier is quoted, the level of vendor support, whether plugin compatibility is included, and who patches the underlying PHP and database versions. The written scope should state these responsibilities before the pilot starts.
How DeployOpen scopes and supports plant ITSM
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For plant ITSM, that means agreeing in writing which sites, lines and OT segments are in scope before any GLPI or iTop configuration begins.
How we scope
- Written scope lists the plants, production lines and asset classes that enter the inventory and CMDB.
- Scope records which OT segments are read through agents, which are documented manually, and which stay out of reach.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Configure GLPI or iTop asset classes, ticket categories and change templates around line and site relationships.
- Deploy inventory agents only where the plant owner approves network access and change windows for each segment.
- Test change and incident workflows against maintenance windows and the production change approval path agreed with operations.
How we hand over
- Deliver documentation covering the CMDB model, site and line hierarchy, agent configuration and escalation paths.
- Provide runbooks for backups, including the database, files and encryption keys, and for platform upgrades.
- Record evidence locations so your auditors and plant safety teams can trace changes and incidents to assets.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Support can cover periodic reconciliation of the OT inventory with plant records and procurement data.
- Confirm with us during scoping which vendor support subscription, if any, the plant environment requires.
