An auditor asks: "Show me every change to production systems in the last twelve months, who approved each one, and why." The answer is either in a system — structured, timestamped, searchable — or it is scattered across email threads, Teams messages, and someone’s memory. GLPI’s Change module can be that system. Not because it was designed as a compliance tool, but because its structured fields and timestamped lifecycle happen to produce exactly the documentation auditors look for.
What auditors actually ask for
ISO 27001 control A.8.32 (change management) requires documented change requests, risk assessment before implementation, approval records, testing evidence, rollback plans, and post-implementation review. NIS2 — which EU member states are transposing into national law — requires documented security measures including change management processes, incident traceability to recent changes, and evidence of risk management.
The common thread across both frameworks is not a specific tool or format. It is evidence that changes were planned before execution, reviewed by someone other than the requester, approved with a recorded decision, and tracked through implementation to closure. If you can show that chain for every production change, you pass. If you cannot, the auditor keeps digging.
How GLPI’s Change module produces this evidence
The Change object moves through New, Evaluation, Approval, Testing, Implementation, Review, and Closed. Each transition is timestamped and attributed to the user who performed it. This is the audit trail — not a report you generate after the fact, but a record that writes itself as people work.
The structured fields do the rest. Impact assessment, risk level, rollback plan, and test plan live as form fields on the change record, not as free-text notes in a wiki. You can make any of these mandatory, which means the change cannot be submitted without them — a control that auditors value more than any policy document.
Approval records show who was asked, when they responded, and whether they approved or refused. Asset linking records which servers, applications, and network devices were affected — the scope of change that auditors need to verify against incident reports. For a detailed walkthrough of designing approval workflows with risk tiers, see our guide to multi-level approval in GLPI.
Where GLPI falls short for compliance
Honesty matters here, because overpromising costs more than the gap itself.
GLPI records who clicked "approve" and when, but there is no cryptographic signature or e-signature integration. For SOC 2 Type II or HIPAA, where auditors may require signed artifacts, this is a gap. For ISO 27001 and NIS2, the timestamped approval record is typically sufficient.
There is no built-in retention policy engine. GLPI stores change records indefinitely, but it does not enforce "retain for seven years, then purge" — you need external tooling or database-level policies for that.
Compliance reporting is limited out of the box. You can query the database, but there is no "compliance dashboard" button. Our GLPI reporting service with Metabase builds the dashboards auditors expect — change volume by category, approval turnaround times, changes without completed reviews.
The native approval system is single-round, which may not satisfy multi-level approval requirements in regulated environments where the security team and the CAB must both sign off sequentially.
Closing the gaps with Cascade
We built Cascade to handle the approval complexity that stock GLPI cannot. Multi-stage steps with configurable quorum, conditional branching (route to the security architect only if the change is classified high-risk), and a full audit trail written to GLPI’s follow-up log. For ISO 27001, this means: step one technical review, step two security sign-off, step three CAB with quorum — each step logged with timestamp, approver, decision, and comment.
For organizations in NIS2 scope, our NIS2 compliance service covers change management as part of the broader security measures implementation.
A practical compliance configuration
If you are configuring GLPI to produce audit-ready change documentation, six steps cover most of the ground:
- Make impact, risk, and rollback plan fields mandatory on the Change form. A change that can be submitted without a risk assessment is a change that will be submitted without one.
- Define change categories that map to your risk classification. Standard, normal, and emergency per ITIL — each with different approval requirements.
- Configure approval chains. Standard changes auto-approve. Normal changes require the service owner. High-risk changes require the CAB.
- Link assets to every change record. This is what makes incident-to-change correlation possible during an audit — "Incident X occurred on Server Y, which was touched by Change Z three days earlier."
- Use the Review phase. Most teams skip it. Auditors do not. The post-implementation review is where you record whether the change was successful, what unexpected effects occurred, and whether the rollback plan was adequate.
- Export change data quarterly. Even if you trust the database, having a dated export demonstrates proactive record-keeping.
For coordinating maintenance windows and avoiding change collisions during audit-sensitive periods, see our guide to the GLPI change calendar.
GLPI is not a GRC platform. It does not replace a dedicated compliance tool for SOC 2 or HIPAA. But for ISO 27001 and NIS2 change management evidence, it produces the majority of what auditors need out of the box — and with the right configuration and Cascade on top, it closes most of the remaining gap. If you need help configuring GLPI for audit readiness, that is a standard part of our GLPI implementation.