What is Change in It Infrastructure and its types :

Change: The ITIL definition of a change is ‘the addition, modification or removal of anything that could have an effect on IT services’.

Change Management is involved in 3 different activities –

1. Approving a Change submitted is one – more of a routine work as there are frequent changes to CI’s

2. Another one is granting approval to a New Service or a Package even before it is built based on the Project Charter Submitted by Service Portfolio Management – Basically Change Management Reviews a Critical output of Service Portfolio Management and gives a Go or No Go based on the inputs provided

3. Last one if approving the Permanent Fixes projected as an input from Problem Management Process

Change Management supports the three types of service changes ITIL describes —

Standard, emergency and normal. The change type determines which state model is invoked and the change process that must be followed.

Standard change
A standard change is a pre-authorized change that is low risk, relatively common and follows a specified procedure or work instruction.

A standard change is one that is frequently implemented, has repeatable implementation steps, and has a proven history of success. As Standard changes are pre-approved, they follow a stream lined process in which group level or peer approval and CAB authorization steps are not required.

Approved standard change requests can be predefined in a catalog of templates to make accessing and requesting a standard change more efficient. This ability also enables the Change Management team to control the changes that are authorized as standard.

Emergency change
A change that must be implemented as soon as possible, for example to resolve a major incident or implement a security patch. It is of such a high priority that it bypasses group and peer review and approval and goes straight to the Authorization state for approval by the CAB approval group.

Emergency changes cover the following types of emergencies:

1. Fix on fail or retroactive situations where the impact to service has already been experienced.
2. Fail or fail situations where the impact to service is imminent if action is not taken.

These changes do not follow the complete life cycle of a normal change due to the speed with which they must be authorized. Therefore, they progress directly to the Authorize state for approval from the CAB Approval group.

Normal change

Any service change that is not a standard change or an emergency change.

Normal change requests follow a prescriptive process which requires two levels of approval before being implemented, reviewed, and closed. These changes require a full range of assessments and authorizations such as peer or technical approval, change management, and Change Advisory Board (CAB) authorization, to ensure completeness, accuracy, and the least possible disruption to service. These changes are most often scheduled outside of defined change blackout windows or during defined maintenance windows. The normal type is used to implement beneficial change for any change to a service that is not a standard or emergency change.

Incident, Problem, Change, Event and Release- IT Infrastructure

Event: An event can be defined as any change of state that has significance for the management of a configuration item (CI) or IT service.

Incident: An ‘incident’ is defined as an unplanned interruption to an IT service or reduction in the quality of an IT service or a failure of a CI that has not yet impacted an IT service.

Problem: A ‘problem’ as the underlying cause of one or more incidents.

Change: The ITIL definition of a change is ‘the addition, modification or removal of anything that could have an effect on IT services’.

Release: A ‘release unit’ describes the portion of a service or IT infrastructure that is normally released as a single entity according to the organization’s release policy. The unit may vary, depending on the type(s) or item(s) of service asset or service component such as software and hardware. The actual components to be released on a specific occasion may include one or more release units, or exceptionally may include only part of a release unit. These components are grouped together into a release package for that specific release.

Now will see in Deep meaning:

Incident Management is almost firefighting, it addresses each degraded service occurrence by a quick fix. The focus is on making the service work like the way it should by all means at the shortest time possible. The Incident Management works best when it has best possible inputs from Release and Deployment Management when the actual service or the package was pushed into operations – More accurate the information is more best can the Incident Management Perform.



Event Management is the First point to look for or is the primary resource which gives first-hand information of what can be a possible degraded service or a service interruption. Events that has been analysed as a possible degraded service or has a negative impact to service gets converted to an incident.



The Service Asset and Configuration Management plays a Critical and Major Role across all the processes, In fact it serves as the base of all these processes the more robust and strong the SACM is the more output can be expected from above mentioned processes.



Change Management is involved in 3 different activities –

1. Approving a Change submitted is one – more of a routine work as there are frequent changes to CI’s

2. Another one is granting approval to a New Service or a Package even before it is built based on the Project Charter Submitted by Service Portfolio Management – Basically Change Management Reviews a Critical output of Service Portfolio Management and gives a Go or No Go based on the inputs provided

3. Last one if approving the Permanent Fixes projected as an input from Problem Management Process