Should unauthorized changes have their own process
By ITIL® from Experience©
Unauthorized changes are mentioned numerous times throughout the Change Management section1
of ITIL® version 3. Even though ITIL® states that one of the aims of Configuration auditing is to identify unauthorized changes2
it clearly makes unauthorized changes the responsibility of Change Management like making a responsibility of CAB members to review them3
.
For example, the value of Change Management to the business is in “Reducing the number of unauthorized changes, leading to reduced service disruption and reduced time to resolve change-related incidents.”4
ITIL® also mentions that a Key Performance Indicator (KPI) for Change Management is the “Reduction in risks due to early identification of unauthorized change”5
and that policies6
have the aim of “Creating a culture of change management across the organization where there is zero tolerance for unauthorized change.”7
That being said, ITIL® proposes three types of changes: Normal, Standard and emergency changes (see People are confused between a normal and a standard change. What is another name for it).
From experience, the normal change process is fit for purpose8
to handle unauthorized changes, especially while early in its maturity (see What are the stages of maturity for the ITIL Change Management Process).
The Normal change process makes unauthorized changes visible by exposing the lack of process compliance and puts peer pressure on people who are not following the rules. As mentioned in Why approve a change that was already made, reviewing and approving unauthorized changes ensures that it was technically sound (e.g. meets the standard architecture) and that it does not introduce risks (e.g. redundancy). It also provides a method to continuously improve the Change Management process (See How to continuously improve the ITIL Change Management Process).
The Normal change process also has activities to advise (i.e. communicate) to technical teams that a change was made, even though it would be after the fact (see What is a change). Thus, owners of related Configuration Items (CI) can adjust their items to prevent additional incidents. It also enables the Configuration Management Database (CMDB) to be updated to reflect the live/production the state of CIs to avoid discrepancies and inaccuracies (see Why is the CMDB inaccurate). Moreover, it can ensure that changes are back propagated to all code base(s) to avoid future incidents from occurring because it was not included in the dev code. The process can also ensure that the Disaster Recovery site(s) remain current.
The number of changes submitted after they were done should be minimized and like an emergency change additional justifications and authorizations to avoid bad habits to develop should be implemented. For example, the individual who made the unauthorized change should explain and justify why a change was made without authorization (see Are changes approved or authorized). Their manager can also be tasked to review this justification and apply the appropriate reprimand the organization has instituted (e.g. warning, dismal). Once these two tasked are completed, the RFC can follow the normal change process however, communication by the Service Desk announcing an interruption of service can be skipped.
The amount of customization of the Normal Change process to accommodate unauthorized changes depends on the level of rigor required by the size, industry and controls required. However, implement just enough process that is necessary; not more. Moreover, be careful in the amount of effort invested to customize the Normal change process as there should be very little unauthorized changes.
The best approach is to focus the effort in making the Change Management process as efficient as possible rather than building a separate process, since a good and efficient change process makes the need for people to make unauthorized change process unnecessary.
Finally, another approach to handle unauthorized changes is to deal with them from a Configuration Management perspective by addressing the discrepancy identified through audits. However, this approach may not foster a culture of zero tolerance for unauthorized changes.
Published on: 2017-10-03
"Implementing Change Management is like driving from New Hampshire where you "Live Free or Die" to Missouri, "The Show Me State."
Related:
- Should RFCs be logged when an undocumented or unauthorized change is discovered
- Why approve a change that was already made
- What level should the Change Manager position be to have the authority to reject RFCs
- Do we need to log an RFC for a Standard Change
From Around the Web:
Category:
ITIL Process > Change Management
Implementation > Process
Copyright 2017 - ITIL® from Experience© - D.Matte