GLPI for IT compliance: audit trails, controls, and reporting

GLPI for IT compliance: audit trails, controls, and reporting

Compliance audits run on evidence. The auditor asks a question, you produce a record. If the record exists and has a timestamp and a responsible person attached, you pass. If it does not, you have a finding. GLPI logs a surprising amount of the data that compliance frameworks require — the challenge is knowing where to find it and how to extract it.

What GLPI logs by default

GLPI maintains a detailed history for most object types. Every ticket records its full lifecycle: creation timestamp, every status change (New → Assigned → Planned → Solved → Closed), every assignment and reassignment, every followup and task, the solution text, and who approved or rejected the solution. Each entry carries a timestamp and a user ID.

Asset records track changes too — when a computer was added, when its software inventory changed, when it was moved to a different entity or location, when a component was added or removed. User accounts log login timestamps, profile changes, and entity assignments.

This is not a separate audit module. It is the History tab that exists on virtually every GLPI object. The data is there by default; you do not need to enable it.

Compliance questions GLPI can answer

Different frameworks ask different questions, but many of them map directly to data GLPI already stores.

ISO 27001

  • "Do you maintain an inventory of information assets?" — the GLPI CMDB is your asset register.
  • "Who approved this change?" — the Change Management module records approval workflows with timestamps.
  • "How do you track access rights?" — user profile assignments and entity authorizations are recorded and auditable.
  • "What is your incident response process?" — ticket lifecycle data shows how incidents move from detection to resolution.

NIS2

  • "Can you report significant incidents within the required timeframe?" — ticket timestamps prove when an incident was detected, escalated, and reported.
  • "Do you perform risk assessments on your IT assets?" — if risk data is tracked per asset (via custom fields or linked documents), GLPI serves as the evidence repository.
  • "How do you manage supply chain security?" — contracts and supplier records in GLPI can track vendor assessments and SLA compliance.

Internal audits

  • "What was the resolution time for P1 incidents last quarter?" — a saved search filtered by priority and date range gives you the answer in seconds.
  • "When was this asset last updated?" — the History tab on any asset shows the last inventory sync or manual update.
  • "Who modified this configuration item?" — GLPI logs the user and timestamp for every change.

Extracting audit data

GLPI offers several ways to get audit data out of the system.

Built-in reports and saved searches

GLPI's search engine lets you filter tickets by any combination of criteria — date range, priority, category, entity, status, assigned group. Save these searches and export them to CSV or PDF. For recurring audits, build the search once and reuse it each cycle.

The Statistics module

Administration > Statistics provides pre-built reports on ticket metrics: average resolution time, tickets by priority, by category, by technician. These numbers feed directly into SLA compliance reporting.

REST API exports

For automated or large-scale extraction, the GLPI REST API gives access to tickets, assets, logs, and history records. A script can pull all P1 tickets from the last quarter, extract their lifecycle timestamps, calculate resolution times, and format the result for an audit report — without anyone manually clicking through the UI.

Database queries

For organizations comfortable with direct database access, the glpi_logs table contains the raw history data. Each row records the object type, object ID, field changed, old value, new value, user who made the change, and timestamp. This table is the definitive audit trail.

Making the audit trail work for you

The data exists. The question is whether your processes are structured so that the data is meaningful. If technicians close tickets without entering a solution, the audit trail shows a closure but not what was done. If changes are implemented without using the Change Management module, there is no approval record.

The configuration effort is less about GLPI setup and more about process discipline: use the right ticket types, require solution text before closure, enforce approval workflows for changes, and keep the asset inventory current. When those habits are in place, GLPI becomes a compliance evidence engine that requires zero additional effort to maintain.

Need help with this topic?

Get in touch