Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
· Home
· Content
· Feedback
· News
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: deannewo60
New Today: 36
New Yesterday: 39
Overall: 230620

People Online:
Visitors: 116
Members: 0
Total: 116



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

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.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Change Triggered Incident??
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Change Triggered Incident??

Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message

Joined: Oct 18, 2006
Posts: 2

PostPosted: Fri Jul 23, 2010 4:57 pm    Post subject: Change Triggered Incident?? Reply with quote

Hi All,

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??

Back to top
View user's profile Send e-mail
Senior Itiler

Joined: Sep 16, 2006
Posts: 3596
Location: London, UK

PostPosted: Fri Jul 23, 2010 5:11 pm    Post subject: Reply with quote


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


bad luck
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile

Joined: Oct 18, 2006
Posts: 2

PostPosted: Fri Jul 23, 2010 5:46 pm    Post subject: Reply with quote

Hi John,

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!!..Smile

Back to top
View user's profile Send e-mail
Senior Itiler

Joined: Mar 04, 2008
Posts: 1894
Location: Helensburgh

PostPosted: Fri Jul 23, 2010 7:05 pm    Post subject: Reply with quote


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
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion All times are GMT + 10 Hours
Page 1 of 1

Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003

Forums ©


Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.