It is 3 AM. A critical vulnerability in your VPN concentrator is being actively exploited. The normal change process requires CAB approval, and the CAB meets on Tuesdays. You cannot wait until Tuesday. If your change management process cannot handle this gracefully, people will bypass it entirely — and then you have no documentation, no approval record, and no post-implementation review. GLPI handles emergency changes as a first-class concept, not an exception you have to work around.
Emergency changes in GLPI
GLPI supports three change types that map directly to ITIL classification: Standard (pre-approved, routine), Normal (full lifecycle with CAB or single-approver), and Emergency (abbreviated approval, implemented immediately, reviewed retrospectively). These are configurable categories, not hardcoded labels — you can adjust the names and rules to match your organization’s terminology.
An emergency change bypasses the full approval chain. Instead of the CAB, a single authorized approver — typically the on-call manager or CISO — can approve. But the change record still requires the same structured fields: description, impact assessment, and rollback plan. These fields take five minutes to fill at 3 AM and save hours of forensics the following week. The shortcut is in the approval chain, not in the documentation.
Pre-define an emergency change template in GLPI: auto-assign the on-call approver group, pre-fill the category as Emergency, and set an aggressive SLA for response — thirty minutes is reasonable for critical security events.
Designing the emergency approval shortcut
The practical configuration in GLPI:
- Create an "Emergency" change category with a business rule that auto-assigns a single approver — the on-call group, not the full CAB.
- Set an aggressive approval SLA. Thirty minutes to respond. If the approver does not respond, the escalation notification fires immediately.
- Keep the impact and rollback fields mandatory. Use a change template with these fields pre-configured. The template makes it faster to fill in under pressure, not optional to skip.
- Advance manually from Approval to Implementation. GLPI does not auto-skip lifecycle phases — the operator moves the change forward as an operational decision. For emergency changes, this means going from Approval straight to Implementation, bypassing Testing when the risk of not patching outweighs the risk of not testing.
If your emergency process still needs two approvers in parallel — for example, the technical lead and the security architect must both sign off before a critical patch can be deployed — that is where Cascade helps. It supports parallel approval steps with configurable timeout, so both approvers are notified simultaneously and the change proceeds as soon as both respond.
Post-implementation review: the step everyone skips
The GLPI Change lifecycle includes a Review phase between Implementation and Closed. In our experience, most teams jump straight from Implementation to Closed. The change worked, the ticket is old, nobody wants to reopen it. This is a mistake — especially for emergency changes.
The Review phase is where you answer four questions:
- Was the change successful? Did the expected outcome match reality? If you patched the VPN vulnerability, is the vulnerability actually closed?
- Were there unexpected side effects? If yes, link the resulting incidents to this change record. That linkage is what makes incident-to-change correlation possible months later.
- Was the rollback plan adequate? Would you use the same plan next time, or does it need revision?
- How long did implementation take vs the estimate? Calibration data for future changes.
For emergency changes, the PIR carries extra weight. The CAB did not review the plan beforehand — the post-implementation review is the retrospective approval, the point where the organization validates that the emergency shortcut was justified and the implementation was sound.
GLPI does not natively gate the Closed status on Review phase completion — you can close a change without reviewing it. This is a process discipline problem, not a system limitation. Configure your process to enforce it: make a "Review outcome" field mandatory before closure, or use a Cascade step that blocks the transition to Closed until the review is recorded.
Connecting emergency changes to incident management
Emergency changes almost always stem from critical incidents. GLPI’s native linking lets you close the loop:
- Link the emergency change to the triggering incident — "Emergency Change #312 was created because of Critical Incident #891."
- Link the change to the affected assets — every server, application, and network device touched.
- After implementation, check whether the incident resolution rate improved — did the change actually fix the underlying problem?
This linking creates the traceability chain that auditors want: Incident X triggered Emergency Change Y, which was approved by Z at time T, implemented at T+2 hours, and reviewed at T+7 days. For how asset linking and the change calendar prevent collisions during emergency maintenance windows, see our guide to scheduling and collision detection in GLPI. For a broader assessment of what GLPI’s Change module handles natively and where it needs reinforcement, see our overview of GLPI change management capabilities.
Emergency changes test your change management process harder than normal changes do. If the process cannot handle them gracefully, people bypass it — and then you have no records when the auditor asks what happened at 3 AM on a Saturday. GLPI supports the emergency workflow natively. The configuration takes an afternoon. The habit takes a few months. But once it sticks, your 3 AM firefights produce the same quality of documentation as your Tuesday CAB meetings. If you need help setting this up, approval workflow configuration is a standard part of a GLPI deployment.