30. 06. 2026
Mirko Morandini
Asset Management, GLPI, Service Management
What GLPI Can Really Add to NIS2 Compliance
With NIS2, the focus moves toward how security is actually managed in day-to-day operations. An important part of NIS2 is operational discipline: knowing which assets exist, who is responsible for them, how incidents are handled, how changes are controlled, and whether the necessary records are already available in the system. The question is whether existing tools support that work in a credible and auditable way. This is where GLPI can make a real contribution.
What NIS2 Means in Practice
In practical terms, NIS2 requires organizations to manage cybersecurity risk in a structured and demonstrable way. That usually translates into a set of recurring operational requirements:
- maintaining a reliable inventory of assets and software
- assigning ownership and responsibility
- documenting relevant changes and maintaining a reviewable history
- tracking suppliers, contracts, and dependencies
- showing that security-related processes are repeatable rather than informal
Many of these depend on day-to-day IT operations. If the organization has no reliable inventory, no structured ticketing, no change history, and no usable reporting, compliance remains weak even if policy documentation exists.
Where GLPI Fits NIS2
The open source asset management and ITSM tool GLPI can cover an important part of the operational foundation that NIS2 expects organizations to have in place. Its practical value lies in centralizing information that is otherwise dispersed across spreadsheets, emails, local notes, and disconnected tools. It also provides accurate automated inventory and integration points for other tools.
Together, these capabilities help an organization show that:
- critical assets are identified and maintained,
- a current hardware and software inventory supports operational decisions,
- incidents are registered, classified, assigned, and tracked,
- changes are tracked, approved, and documented,
- suppliers and contracts are linked to hardware and applications, and
- the necessary reports can be extracted from a centralized data source.
This makes GLPI relevant for asset inventory, ownership, incident records, change requests, contract management, and reporting. It is not, however, a complete NIS2 compliance platform: it does not replace legal interpretation, governance processes, SIEM capabilities, or specialized risk tools.
Asset Inventory: The Most Immediate Contribution
If there is one area where GLPI can contribute immediately, it is asset management. The inventory guidance provided is close to what many NIS2-related assessments expect in practice: a maintained inventory of physical systems, network devices, security appliances, endpoints, mobile devices, software platforms, data flows, responsible persons, authorization records, licenses, warranties, and version information.
A useful GLPI setup should cover at least the following:
- a hardware inventory for servers, workstations, laptops, network devices, printers, mobile devices, and security systems (most of them automatically collected through GLPI Agent functionalities),
- a software inventory with versions, installation relationships, and licensing information,
- ownership fields for business owner, technical owner, and support team,
- a classification of criticality, business relevance, and operational status,
- links between assets, contracts, tickets and changes,
- the lifecycle status, warranty dates, and maintenance information.
A common mistake is to stop at technical discovery. For NIS2 purposes, a simple list of machines is not enough. Inventory becomes useful only when it also shows context: who owns the asset, what service it supports, whether it is critical, whether it is authorized, and what depends on it. GLPI therefore needs to be configured carefully. It should not be used only as a storage location for technical records. Asset records need to be completed with their ownership, contracts, responsibility and the operational context (backup, maintenance, monitoring configs) as well.
Without this enrichment, the inventory may still be useful operationally, but it remains weak from a compliance perspective.
Incident Handling: Process and Traceability
Incident handling is another area where GLPI fits naturally.
NIS2 expects incidents to be handled through defined responsibilities, escalation paths, and documentation. GLPI can support this well if security-related incidents are treated as a structured workflow rather than as generic tickets.
A practical setup usually includes:
- dedicated categories for cybersecurity events and security incidents
- mandatory fields such as detection time, impacted asset, business service, severity, suspected cause, and containment status
- automatic assignment to the correct response group based various parameters
- SLA or OLA targets for triage, containment, and escalation
- required supporting attachments or investigation references
- links between the incident ticket and the affected assets, changes, and problems
- tracking of the communication and activities in the ticket, preserving the handling timeline
GLPI provides structure and is a clear improvement over fragmented handling through email threads and informal notes.
Change Management: Important for Security, Not Just Operations
In many environments, security incidents and operational changes are still handled separately, even when they are clearly connected. Security-related patches, firewall changes, configuration adjustments, software deployments, and emergency fixes should not disappear into routine administration. They need to be visible, documented, and reviewable.
GLPI can support this well if the change process is actually used. For NIS2-related use, changes should normally include:
- a distinction between standard, normal, and emergency changes
- the reason for the change, including the security driver where relevant
- impacted assets and services
- the necessary approval workflow
- implementation date and responsible implementer
- rollback considerations
- references to related incidents, problems, vulnerabilities, or maintenance windows
The value here is practical: fewer undocumented security-relevant changes and a clearer history showing that operational risk is not managed in an ad hoc way.
Reporting and Records
One of the strongest reasons to use GLPI in a NIS2 context is reporting. Dashboards, reports, linked records, timestamps, and status histories can give a centralized overview of security-relevant information, such as:
- the current inventory of critical assets and software versions
- unresolved security-related tickets
- lists of (emergency) changes in a given period
- assets without assigned owners
- contracts approaching expiration
- systems without recent inventory updates
- recurring issues linked to known assets or services
This gives IT managers better oversight, helps compliance teams with traceability, and makes audits less dependent on reconstructing information afterward. The obvious limitation is that record quality depends on process quality. GLPI can only report on what is actually maintained.
Supplier and Contract Visibility
NIS2 gives clear attention to supply chain security. GLPI is not a supplier risk platform, but it can still provide useful operational transparency if suppliers, contracts, support relationships, and maintenance responsibilities are linked to assets and services.
That makes it easier to answer practical questions such as:
- which contract covers this service?
- which systems depend on a third party?
- when does support expire?
- who is the external contact in case of an incident or urgent change?
This does not solve the full supplier risk problem, but it creates a baseline that many organizations are still missing.
Limits That Should Be Acknowledged
GLPI supports a NIS2-related implementation, but it does not cover all areas equally well.
First, GLPI can store risk-relevant information, but it is not a dedicated Governance / Risk / Compliance platform. Second, GLPI can track affected assets, remediation tickets, and linked changes, but security monitoring itself usually comes from SIEM and EDR tools. Third, data flow mapping is possible only to a limited extent. GLPI can capture relationships and dependencies, but it is not designed for detailed data-flow modeling.
Finally the most important: a poorly implemented GLPI setup wit outdated data will not help with NIS2. If inventory is incomplete, ownership unclear, classification inconsistent, and change workflows unused, the results will of course remain weak.
Final Consideration
GLPI can be the operational backbone in a NIS2 program. GLPI connects assets, incidents, changes, contracts, responsibilities, and reporting in a way that is directly useful for compliance work. For IT managers and compliance teams, that is its real value. GLPI helps turn operational activity into traceable records, and this is a substantial part of the whole compliance effort.
If GLPI is configured with care and used with process discipline, it can support several of the areas that matter most in practice: asset management, accountability, incident handling, controlled change, supplier traceability, and record availability. Its certainly also has its limits, but within the operational layer of NIS2, GLPI can do much more than many teams currently assume.
Würth IT Italy, based in Bolzano/Bozen, is a GOLD Partner of the GLPI editor TecLib for the Italian and the German speaking market. Refer to us for GLPI Network subscriptions and cloud services (https://www.glpi-project.org/en/pricing/) and for specialized consulting.
Mirko Morandini
Mirko Morandini, PhD, is a senior consultant in IT Service Management and Asset Management, with over a decade of experience and numerous successful projects in Germany, Austria and Italy. As the GLPI advocate at Würth IT Italy, Mirko is passionate about open source solutions - and when he’s not optimizing IT processes, he enjoys spending time with his family and playing and conducting wind band music.
Author
Latest posts by Mirko Morandini
31. 03. 2026
Asset Management, GLPI, Service Management
GROUP-based Asset Permissions in GLPI 11: GLPI Rights Management Redefined
29. 09. 2025
Asset Management, GLPI, Knowledge Management, Service Management
Getting the M(u)st out of GLPI
30. 06. 2025
Asset Management, Unified Monitoring
Das neue GLPI 11 – offizielle deutsche Vorstellung [DE]
31. 03. 2025
Asset Management, GLPI, Knowledge Management, NetEye
GLPI: Automated Inventory Without Using GLPI Agents