Loading...
 

Should RFCs be logged when an undocumented or unauthorized change is discovered

By ITIL® from Experience©


A reader asked if an RFC should be logged when an undocumented change is discovered?


The answer is yes. A Request For Change (RFC) should be logged for all undocumented changes when they are found (see What is a change). They should also follow the Change Management process to be authorized in order to realize the majority of the benefits of the Change Management process (see Are changes approved or authorized). Moreover, logging RFCs supports other ITIL® processes that rely on the change management’s output and data.

ITIL® does not specifically mention that undocumented changes should be logged1. Nevertheless, ITIL® states that Service Asset and Configuration Management should investigate and take corrective actions to address unregistered and unauthorized items are discovered during configuration audits and to log and report all exceptions2. In addition, it also clearly affirms that the scope of the Change Management process is to “Ensure that changes must be recorded and managed in a controlled way.”3 .

ITIL® also states that two objectives of change management are to:

  • “Ensure that changes are recorded and evaluated, and that authorized changes are prioritized, planned, tested, implemented, documented and reviewed in a controlled manner.”
  • Ensure that all changes to configuration items are recorded in the configuration management system.”4


Given that sometimes it takes months for incidents caused by a change to surface, a historical record of the change in the ITSM Tool helps to resolve incidents faster since their cause can be identified more quickly. The historical records also helps Problem Management to identify fragile configuration items.

These are only few of the benefits of logging RFCs for undocumented and unauthorized changes once they have been discovered. Moreover, it enables the process to be measured and to report on a Key Performance Indicator (KPI) of the Change Management process like the “Reduction in risks due to early identification of unauthorized change.”5 (see Is there a book to help us develop Key Performance Indicators (KPI))

The only time RFCs should not be logged is when an organization automatically rolls back changes by overwriting Configuration Items (CI) with the approved image/authorized state (e.g. gold/production). Even then, logging unauthorized changes should be considered to measure people’s discipline at following the process. Moreover, logging unauthorized changes enables the Change Management process to deliver on its value to the business by “reducing the number of unauthorized changes, leading to the reduced service disruption and reduced time to resolve change-related incidents.”6

Now that we have seen that all changes must be logged, even the ones that have been discovered after they have been made, the question that arises is: Should undocumented changes be approved once logged?

This question is answered in: Why approve a change that was already made.


Last updated on: 2017-12-06
Published on: 2017-04-06

Quote:
"There is nothing wrong with change, if it is in the right direction." Winston Churchill.

More Quotes



Related:

More on Change Management


From Around the Web:



Category:
ITIL Process > Change Management


1. Even though unauthorized changes are mentioned in 12 different sections of the ITIL® Service Transition (2011 Edition) book, it does not specifically mention that undocumented and unauthorized changes should be logged. The same can be said for ITIL® v2 Service Support (2000) where unauthorized changes are mentioned in 4 sections.
2. ITIL® Service Transition (2011 Edition), Section 4.3 Service assest and configuration Management, p.111
3. ITIL® Service Transition (2011 Edition), Section 4.2 Change Management, Section 4.2.2. Scope (p.61)
4. Ibid, Section 4.2 Change Management, 4.2.1 Purpose and objectives (p.61)
5. Ibid, Section 4.3.8 Critical success factors and key performance indicators, p. 113
6. Ibid, Section 4.2.3 Value to business (p.63)



Disclaimer


Copyright 2017 - ITIL® from Experience© - D.Matte