For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
We recently had a asituation in our organaisation and a debate around it. I have described both below. Please have a look and provide your inputs/thoughts.
What Happened
==========
A change was raised to implement a security policy (policy:ABC), this change was duly assessed and approved for implementation. During the Implementation process the implementer wrongly implemented another security policy (policy:XYZ) inplace of what was mentioned in the change.
As a result of this unauthroised policy being implpemented a security related incident occurred.
The debate
=======
Some people are of the view that the incident was caused by the change and is therefore a change triggered incident.
Some others are of the opinion that it is not a chanage triggered incident, because the change has not authorised or approved the implementation of the wrong faulty policy (policy:XYZ). The incident was triggered due to a human error in implementation and not due to the change.
This is the situation and the debate. Please provide your valuable inpust on the above. Is this a Change Triggered Incident or a Human error triggered incident??
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Fri Jul 23, 2010 5:11 pm Post subject:
Rishab
It is both. In fact it is actually 3 distinct items
failed change - they did not deploy the approved change
unauthorized change - they implemented the wrong change
incidents - any activity where the service was impacted by the unauthorized change
The real question is - what is going to be done ?
Is the individual going to be fired, reprimanded, cheered, congratulated ?
Is the implementation process for changes going to be reviewed and addressed so this does not happen again
etc . etc.. etc...
In all seriousness, the fact that this happened is more important than trying to figure out what it is
It show a lack of attention to detail
Failure to follow instructions
no verification / confirmation of changes - 2 man rule
and
bad luck _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Thanks for your inputs. The corrective action suggested by was that the individual shold be asked to provide an explanation for his error and a process put in place to control such errors.
But what is more worrisome is that the senior management is bent upon tagging the incident as a chanage triggered one. Doing so will shift the focus of the corrective actions from the individual to the process, and in my opinion it is not a process failure.
The process has duly assesssed the impact and approved the change based on those analysis. The individual has circumvented the process by implementing something which has not been authorised. This led to the incident.
The arguement from the senior management is that if there was no change authorised in the first place then there wouold have been no opportunity for this incident to occur, therefore it is a change triggered incident!!
It is similar to saying, if there was no examination I wouldnt have failed, therefore I failed because there was an examination and not due to my lack of knowledge!!..
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Fri Jul 23, 2010 7:05 pm Post subject:
Rishab,
asking for an explanation is not a corrective action! Until you understand how and why it happened you are not in a position to devise a corrective action.
It is very simple. The change led to an incident. Here are the reasons:
1. Someone enacted an approved change.
2. It turned out that the approved change was wrongly implemented.
3. The verification process failed to spot the fault.
The third is the key - your change procedure either was not followed at this point or is inadequate.
Review of this change and what went wrong has to focus on:
1. Why was the error not spotted as part of confirming the change?
2. How did the error come about?
You then consider whether each of these questions requires a corrective action.
For the first that may take the form of a change to improve your change procedure or better training for your change manager or other staff, improved control of identification information within your CMDB, or something else, depending on what you ascertain.
For the second it may take the form of tightening the rules as to who is authorised to perform the activity, improved training for that (or several) staff, improved supervision, or something else.
Disciplinary action is not a corrective action and reasonable human error would not necessarily require a corrective action. However if the underlying cause was to do with people being required to multi-task under pressure then their could be a corrective action of redistributing workloads or increasing staff resources.
You may derive from my comments that your concern as to focus is misplaced as a proper review will investigate all aspects of the issue. A focus on just the process would be no more incorrect than a focus on just the person and either will result in a loss of opportunity for improvement. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum