Can GLPI support NIS2 asset and incident management evidence?
If you are an essential or important entity preparing for the risk management measures in Article 21 of NIS2, GLPI can supply asset records, tickets, problem records and change records that serve as evidence for asset management and incident handling. NIS2 creates no certificate of compliance, and the entity owns its risk management. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, so the question is not whether GLPI can hold the data but whether your records show that the measures run in practice. DeployOpen prepares systems, controls and evidence for that review. It does not issue audit reports, attestations or certifications, and independent assessment remains the job of your authorities and auditors.
Start by deciding which obligations the evidence must answer, then map each one to a GLPI object. Asset inventory evidence comes from the asset types, locations, statuses, owners and the links between them. Incident evidence comes from ticket categories, SLAs, escalation records and the history log. Problem and change records show how recurring weaknesses are addressed and how changes are approved. Ask your national authority or legal counsel which measures apply to your sector and size, and confirm the transposition law in your Member State, since NIS2 reaches entities through national law. The Commission's NIS2 Directive overview is a sound starting point for that conversation.
Then check where GLPI records stop. Reporting duties for significant incidents depend on timelines set by your national rules and on the criteria in Commission Implementing Regulation (EU) 2024/2690, which applies to specific sectors such as cloud, data center and managed service providers. GLPI ticket timestamps do not replace the notification workflow or the separate records your competent authority expects, and the process for what happens after an incident sits with your security and legal teams. Confirm these boundaries early, because gaps found during an assessment are costly to close under time pressure.
Mapping NIS2 requirements to GLPI capabilities and configuration
This table compares the NIS2 Article 21 asset management and incident handling measures, the Article 23 reporting duty, and the Implementing Regulation 2024/2690 areas with the GLPI capability that can produce evidence for each and the configuration it needs. Read each row as a starting point for your own mapping, since the article-level alignment should be confirmed against ENISA's technical guidance. The main takeaway is that GLPI can hold the records, but the policy, the reporting decision and the sign-off remain with your organization.
| Requirement | GLPI capability | Configuration needed |
|---|---|---|
| Article 21 asset management (inventory of systems and devices) | Asset records for computers, network equipment and software, populated by GLPI Agent inventory | Agent deployment coverage across endpoints, mandatory asset fields, locations and statuses, and a process for assets that GLPI Agent cannot see |
| Article 21 asset ownership and accountability | Assets linked to users, groups and technicians in charge | Defined owner per asset class, groups aligned with your org chart, and a rule for reassigning ownership when staff leave |
| Article 21 incident handling (detection, triage and response) | Tickets with categories, urgency and impact, routed by rules to the right team | Incident ticket categories that match your reporting taxonomy, routing rules, and mandatory fields for affected assets |
| Article 21 incident handling (time to respond and resolve) | SLAs and OLAs tracking time to own and time to resolve, with escalation levels before or after a deadline | SLA and OLA definitions agreed with business owners, escalation recipients named, and calendars set for working hours |
| Article 21 root cause and recurring incidents | Problem records linked to incident tickets | A rule for when a problem record is opened, and links between related incidents and the affected assets |
| Article 21 change control on affected systems | Change records with approval steps and linked assets and tickets | Approval workflow for significant changes, and a link between each change and the asset it modifies |
| Article 23 reporting (early warning, notification and final report timelines) | Ticket history and timestamps that show when an incident was logged, assessed and escalated | Ticket fields for detection time and severity, and a documented decision step for the national CSIRT or competent authority. GLPI does not submit reports for you. |
| Implementing Regulation 2024/2690 (technical and methodological requirements and significant incident criteria) | Asset, change and incident records as supporting evidence where a measure depends on inventory or change control | Confirm which requirements apply to your sector and service type, and map them to ENISA's non-binding guidance before relying on GLPI records |
| Evidence retention and traceability | History logs on tickets, assets and changes | Retention settings and backup procedures agreed with your records policy, and access limited to staff who must review evidence |
How GLPI records fit the asset and incident workflow by role
The security or compliance lead owns the rules that GLPI records have to meet, not the daily entries. This role decides which assets, software and suppliers are in scope, which fields are mandatory, and which incident and change categories feed the reporting process. In GLPI, that means defining asset types, required fields and ticket categories so the records support the risk-management measures under Article 21 of NIS2.
- Asset scope definition: Decide which assets, software and suppliers must appear in the inventory, and set the owner and location fields that every record must carry.
- Ticket categories for security incidents: Set categories and priorities so that significant incidents can be filtered, counted and traced when the reporting obligations in Article 23 apply.
- SLA and OLA review: Check the time to own and time to resolve settings and the escalation levels against the internal response commitments the organization has made.
- Evidence package: Prepare inventory reports, ticket histories and problem and change records for competent authorities or auditors, and note which fields came from automatic inventory and which were entered by hand.
Check that the scope rules are written down, approved and dated, because a reviewer will ask how the inventory was defined as well as what it contains.
IT operations owns the inventory data and the change records that keep it accurate. GLPI Agent is commonly used to collect hardware and software inventory, and the operations team decides how often agents report, how discovered devices are reconciled with the register, and how changes to monitored assets are recorded.
- Inventory data: Keep assets, software installations and network devices current, and move decommissioned assets to a retired status so their history remains available.
- Problem records: Link recurring incidents to a problem record so that root cause work is visible in the ticket and problem history.
- Change records: Open a change for each planned modification to a monitored asset, and route approvals through the change process before work begins.
- SLA timers: Track OLAs assigned to internal support groups, since these timers depend on the operations team meeting its own time to own and time to resolve targets.
Check that agent coverage and discovery scope match the asset list the security lead has approved, because coverage gaps are what a reviewer is most likely to test first.
The service desk owns the first record of each incident. Tickets opened by users, by email or from monitoring carry the times that SLA and OLA calculations use, so the quality of the initial entry determines whether the timers can be relied on later. The GLPI service levels documentation describes how these timers and escalation levels are configured.
- Ticket intake: Record the affected assets on each ticket so that every incident links back to the inventory record.
- Time to own and time to resolve: Confirm that the correct SLA is applied at ticket creation, and that the status changes which stop or start the clock are used consistently.
- Escalation: Follow the escalation levels that act before or after a deadline, and record who was notified and when.
- Handover to security: Flag tickets that may be significant incidents so the compliance lead can assess them against NIS2 reporting deadlines.
Check that SLA rules and status workflows have been tested with sample tickets, because timers that run incorrectly produce records that look complete but cannot be used as evidence.
Which GLPI records serve as NIS2 evidence and how to keep them
NIS2 Article 21 asks for risk management measures that you can show in operation, so the records you keep in GLPI need to be complete, dated and protected. The cards below cover the GLPI data that most often supports asset management and incident handling, and the practices that keep that data usable as evidence. Their value depends on the team using GLPI consistently, not on the feature set alone.
Asset register and inventory history
The asset register is the list of hardware and related items in scope, with owner, location, status and the user or group responsible. Inventory history shows when an asset appeared, changed or disappeared, which is what you need when asked how you know your register is current. Check that GLPI Agent or network discovery runs on a schedule, that manual edits are logged, and that retired assets are marked rather than deleted so their history survives.
Software records
Software records tie installed applications to a publisher, version and the assets they run on. They help you show which systems carry vulnerable or unsupported components and how quickly you act on them. Confirm that inventory captures software on managed endpoints, that versions are normalized so reports group correctly, and that software no longer in use is reviewed on a set cadence.
Ticket and incident history with timestamps
Tickets record what happened, who handled it and when each step occurred, which is the core of incident handling evidence. Timestamps on opening, assignment, updates and closure let you reconstruct the response sequence for a competent authority. Check that technicians log actions in the ticket instead of in email or chat, that ticket categories match your incident classification, and that closed tickets cannot be silently edited.
SLA and escalation logs
GLPI tracks time to own and time to resolve for SLAs and OLAs, and escalation levels act before or after a deadline. The resulting log shows whether incidents were acknowledged and resolved within targets you set and whether escalation happened when it should. Confirm that your SLA definitions reflect the response expectations you can actually defend, and review breaches periodically so the log reflects real handling rather than unused settings.
Change approvals linked to affected assets
Change records link a planned modification to the assets it touches and to the approvals that authorized it. Under NIS2, this supports the change and configuration control expected in risk management, and it connects incidents to recent changes during investigation. Verify that changes are raised for significant modifications, that approvers are recorded, and that emergency changes are documented after the fact with a reason.
Backups of the database and glpi.key
The database holds tickets, inventory and history, and the configuration directory holds the glpi.key and glpicrypt.key files that GLPI needs to read encrypted data. Without both, restored records may be unusable or incomplete. Keep backups of the database, application files and config directory on a schedule, store copies outside the production host, store the key files with restricted access, and test restoration on a separate system before you rely on it.
Configuring GLPI for NIS2 evidence in order
This sequence sets up GLPI so that its inventory, ticket, problem and change records can serve as evidence for NIS2 Article 21 measures on asset management and incident handling. Each step produces a record or check that a reviewer can inspect later.
Confirm scope and entity category
Before any configuration, confirm with legal and compliance counsel whether your organization is in scope of the national NIS2 transposition law and whether it is classified as essential or important. That classification affects how supervision is applied, though the risk-management obligations under Article 21 are the same for both. Record the sector, the in-scope services and the systems that support them, because these define which assets and incident categories GLPI must cover. Done when a signed scope note names the entity category, the in-scope systems and the owner of the NIS2 evidence file.
Deploy GLPI on infrastructure you control
Your infrastructure or platform team installs GLPI on servers, virtual machines or containers you operate, using the PHP and database versions in the GLPI installation prerequisites for your target release. Confirm the web server document root points to GLPI's public directory with URL rewriting in place, and use MySQL or MariaDB because those are the only supported database engines. Keep the instance in a segment your security team can monitor, and document the hostname, version and hosting location. Done when the installation completes, the version is recorded in the evidence file, and a test ticket can be created and closed.
Deploy GLPI Agent across endpoints
Deploy GLPI Agent to Windows, macOS and Linux endpoints through your existing software distribution or configuration management tooling, so hardware and software inventory flows into GLPI automatically. Agree with the endpoint team which device classes must report, and check that servers, network devices and mobile devices not covered by the agent are listed as manual or discovered assets. Note the coverage gap at this stage, since NIS2 evidence depends on knowing what is missing. Done when a reconciliation report compares the endpoint inventory from your directory or management tool against GLPI and the gaps are assigned to owners.
Configure SLAs, OLAs and escalation
Define service levels for security incident tickets in GLPI, using the time-to-own and time-to-resolve settings and escalation levels that act before or after a deadline. Set operational level agreements for the internal teams that must act on each incident, such as the security operations group, infrastructure and the service desk. Review the thresholds with the incident response lead, since the values are organization-specific and should match your own response procedures. Done when a test incident triggers the expected escalation notice and the configuration is exported or screenshotted for the evidence file.
Define ticket categories for security incidents
Create ticket categories and types for security incidents, separating suspected compromise, service disruption, data exposure and supplier-related events so that each class carries its own workflow and assignment rules. Map each category to the incident handling steps your procedures require, including who classifies significance and who decides whether a report to the national authority is needed. Keep the classification fields consistent so that reports can be filtered later. Done when a sample set of tickets across categories can be filtered and each one shows an owner, a status history and a classification.
Link problems and changes to assets
Require that every security incident ticket that touches an asset is linked to the affected item in the inventory, and that root cause analysis is recorded as a problem linked to the same assets. Link remediation work to change records so that the approval, implementation and rollback steps are traceable from the incident to the affected asset. Make the asset owner field mandatory where your process requires it, since ownership is central to asset management evidence. Done when a sample incident can be followed from the ticket to the linked asset, the problem and the change, without manual reconstruction.
Set backup and key handling
Plan backups of the GLPI database, application files and the configuration directory, including the encryption key files glpi.key and glpicrypt.key, and store them in a location with restricted access. The GLPI update procedure depends on these files, so test that a restore produces a working instance before relying on it. Document who holds the keys, how they are rotated or recovered, and how long backups are kept, since the retention period must follow your own policy and any legal requirements you confirm. Done when a test restore is completed, the restore record is kept and the key custody procedure is approved.
Run an evidence review
Assemble a review pack from the GLPI exports, reports, SLA configuration, sample tickets, linked problems and changes, and the agent coverage reconciliation, then have someone outside the operating team check it against your NIS2 measures. The reviewer should confirm that each record can be traced to a control, that gaps are logged with owners, and that nothing depends on undocumented manual steps. Record what GLPI cannot show, such as risk assessments, supplier security reviews and reporting decisions that happen outside the tool. Done when the review produces a dated list of findings and remediation actions that the accountable manager signs off.
Questions buyers ask before using a partner for NIS2 GLPI work
Does running GLPI make an organization NIS2 compliant?
No. GLPI is a tool that can hold inventory, tickets, problems and changes, which are records you can use as evidence for some Article 21 measures. NIS2 creates no certificate of compliance, and national competent authorities oversee compliance through inspections, audits, scans, information requests and fines. Compliance depends on your risk analysis, policies, roles, supplier controls, incident reporting process and how people actually follow them. GLPI supports part of that picture, and the rest must be designed and run by your organization.
What drives the cost and effort of a NIS2 GLPI project?
The main drivers are the number of in-scope entities and sites, how many agents and assets must be inventoried, how much of your existing ITSM and monitoring must be integrated, and how much policy and process work is needed. Costs fall into one-time items such as design, configuration, integration and documentation, and recurring items such as licensing, hosting, patching and reviews. Ask any partner for a quote built from a written scope that lists these drivers separately, so you can see what each part covers.
What does the work need from our own team?
Expect to supply people who know your asset owners, network segments, identity sources, incident process and supplier landscape. Your team will need to approve classifications, confirm ownership of assets and services, provide access to systems for inventory and integration, and review documentation before it is accepted. Named decision makers for policy and risk acceptance must be available, because those choices cannot be delegated to an implementation partner. Agree these responsibilities in the written scope before work starts.
Can an internal team do this without a partner?
Often yes, if it has people with GLPI administration skills, time for configuration and documentation, and clear authority over NIS2 governance. The harder parts are usually the policy work, the mapping of GLPI records to the measures in Commission Implementing Regulation (EU) 2024/2690, and the operational discipline to keep records current. Test your own team against those skills honestly. A partner can cover gaps in configuration, integration or evidence design, while your staff keep ownership of decisions.
How long does a NIS2 GLPI engagement take?
Duration depends on scope: the number of sites, the number of agents and assets, whether you are starting from an existing GLPI instance or a new one, and how many integrations and policy documents are involved. Implementing Regulation (EU) 2024/2690 applies from 18 October 2024, so most organizations already have a compliance gap to close. Ask for a timeline tied to specific deliverables and dependencies, and confirm which steps depend on your decisions or access approvals.
Do GLPI Network subscriptions change the approach?
They can change the hosting and support model, but not the compliance work. GLPI Network public cloud is listed at 19 euros per user per month and private cloud at 21 euros per user per month with a 25-user minimum, 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). Check where the data is hosted, who operates the service and what support level you receive, because NIS2 obligations on supply chain and hosting still apply to you.
What does a fixed-scope engagement cover?
A fixed-scope engagement covers the deliverables, scope boundaries, timelines and responsibilities written into an agreed document before work starts. For this topic that can include GLPI configuration for asset and incident records, integration with agreed sources, documentation of how records map to the measures you choose, and handover to your team. It does not include issuing audit reports or certificates, which independent auditors and certification bodies provide, and it does not replace your legal analysis of NIS2 obligations. Ask for the exclusions in writing as well as the inclusions.
What DeployOpen delivers and what it does not
DeployOpen implements GLPI inside infrastructure you control and configures it so that its records can support your NIS2 Article 21 measures on asset management and incident handling. The work covers the GLPI deployment itself, rollout of GLPI Agent to the device estate, configuration of SLAs and OLAs with escalation levels, ticket, problem and change workflows that match how your incident response team actually operates, and the evidence procedures that tell your staff what to export, when and from where. It ends with a gap list: a written record of which Article 21 expectations your GLPI configuration covers, which it covers partly, and which depend on processes, tools or owners outside GLPI. Scope, deliverables and timelines are agreed in writing before work starts, so you know what you are paying for and what you will receive.
DeployOpen does not issue audit reports, attestations or certifications. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, and the way your organization is assessed depends on your national transposition law. DeployOpen also does not act as your legal adviser, so questions about whether your entity is essential or important, which sector annex applies, how your national law implements Article 23 reporting, or how the proposed amendments in COM(2026) 13 would affect you belong with your counsel and your national authority. Confirm the current status of those amendments with counsel, since they were still a proposal in the Commission pages available at the time of writing. Ask any partner, including DeployOpen, to state this boundary in the statement of work.
How DeployOpen scopes and delivers GLPI compliance evidence
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted GLPI inside infrastructure you control. For NIS2 asset and incident management, we scope the evidence trail together with your security and compliance leads, so that inventory, tickets, problems and changes produce records a national authority or auditor can follow.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope lists which asset classes, locations, entities and incident workflows GLPI must cover for NIS2 evidence.
- We map each Article 21 measure you claim to the GLPI record that supports it, and name the gaps that stay outside GLPI.
How we build
- We deploy GLPI on your infrastructure, then configure asset types, statuses, owners, locations and inventory sources to match the scope.
- We set up SLAs, OLAs, escalation levels, problem and change workflows so incident handling leaves timestamped history.
- We test the evidence path end to end, from a sample asset or incident through to the report a reviewer would request.
How we hand over
- You receive the configured instance, the written configuration record, and documentation of the workflows your staff will run.
- We document the evidence map, the report definitions and the recurring review tasks, so your team can reproduce them without us.
- We set out what GLPI does not record, such as detection tooling, supplier notification steps and decisions made outside tickets, and who owns each.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, including planning for GLPI 11 and 12 upgrades.
- Before any GLPI upgrade, we review backups of the database, files and config keys, and plan plugin reactivation after major updates.
- We confirm with your compliance lead whether any NIS2 transposition rules in your Member State add requirements to the evidence set.
