RFC Number:

Request for Change Form

RFC Status:
To be completed by the Change Initiator:
Name: Status Options: New, Awaiting
Assessment, Assessed, Rejected by CM,
Date RFC Raised: Authorised, Rejected by CAB, In Build, In
Test, Awaiting Implementation, Implemented,
Awaiting Review, Closed
Date Change is Required By:

System or Configuration Item to be changed:

Reason/Business Justification for the Change:

To be completed by the Change Manager

Date Change Assessed by CM: If Rejected:

Reason for Rejection at Initial Assessment:
(if appropriate)
Priority Assigned:

Priority Information
E Emergency, needs doing immediately (Emergency Change
Process)
H High, needs doing within 48 hours
M M Medium, needs doing within 5 days
Date Change Initiator Informed of Change Rejection:
(if appropriate)
L Low, needs doing by indicated date

Category Assigned: Risk of Change to the Business:

(H/M/L)
Category Information
Standard Change (via Heat) – Using a Procedure
IT Change Model – Using a Procedure
Minor Change – Authorised by Change Manager Alone Impact of Change to the Business:
Significant Change – Authorised by a CAB (H/M/L)
Major Change – Authorised by a CAB (Senior Level)
Emergency – Authorised by the ECAB

Change Authorised by (include all CAB members):

To be completed by the Change Builder

Does the Change Implementation Require Third Name of the Third Party/Supplier:
Party/Supplier Involvement: Y/N

Additional Information Full Name IT Team

Change Builder Identified

Type of Testing Identified
Change Tester Identified

Page 1
To be completed by the Change Builder
Date Change Building Completed: Details of Change Backout Plan:

Change Dependencies Identified:

To be completed by the Change Tester

Date Change Testing Completed: Details of Testing Carried Out:

Change Dependencies Identified:

Backout Plan Tested: Y/N

If Change Failed Testing Date Returned to Change Builder for Re-building:

Reason for Test Failure: (if appropriate)
(if appropriate)

To be completed by the Change Implementer

Change Communicated to:

Date of Change Communication:

Scheduled Implementation Date :

Date Change Actually Implemented:

Issues Encountered:

Backout Plan Implemented: Y/N Backout Authorised By:

Date Backout Communicated to the Change Manager:

Page 2
To be completed by the Change Manger – Change Review Post Implementation

Review Information

Date Change Reviewed:

Change Reviewed by:
Change Successful: (Y/N)
Backout Plan Successful Deployed (if required): (Y/N)
If Backout Deployed – date Initiator Informed:
Date RFC returned to Start of the Process for Re-
assessment:

Review Details:

Change to become a Procedure: (Y/N)

CAB Meeting Information - To be completed by the Change Manager

Date CAB Meeting Held: High Level CAB Considerations/Decisions:

• Appropriate Priority/Category
CAB Attendees: • Cost of Change
• Resource required for Change
• Business Risk of Change Implementation
• Business Impact of Change Implementation
• Technical Capability
• Required Communication
• Suitability of the Change Implementation
Date

CAB Comments/Issues/Decisions

RFC Authorisation to be completed at the top of the

RFC by the Change Manager Escalation of Change Authorisation Required: Y/N

If Rejected: Date Escalation Made:

Reason for Rejection by the CAB:
Final Decision Made: (Whom/What):

AnChange
Date example Request
Initiator forofChange
Informed Change Form
Rejection: Page 3
Completing the Request for Change Form
Part One – Completed by the Change Initiator

RFC Number
On commencing the raising of a Request for Change the RFC Number will generate a
unique number.

RFC Status
On raising a Request for Change Status will be set as NEW.

Date RFC Raised

The date the member of ISS raised the Request for Change.

Name
The full name of the Change Initiator.

Date the Change is Required By

The date by which the Change needs to be implemented.

System or Configuration Item to be Changed

The system, application, piece of hardware to which the change will be carried out. This
must be uniquely identified to ensure that the change is carried out to the correct part of
the infrastructure. For example if a change is required to a Switch – the unique
information for that exact Switch must be identified.

Reason/ Business Justification for the Change

The Reason/Business Justification for the Change must be completed in detail by the
Change Initiator.

The following should be included:

• Why the change is needed – in particular giving detailed information on

implications of not implementing the change – i.e. security risks etc.
• Known risks or impact to the Business of implementing the Change -
consideration should also be given to the risk and impact to the Business of not
implementing the Change.
• Required resources – including people, time and investment.

RFC Status
As the Change Initiator saves the Request for Change the status will automatically
change to AWAITING ASSESSMENT.

Page 4
Part Two – Completed by the Change Manager
Date Change Assessed by the Change Manager
The date the Change Manager completed the initial Change assessment.

If Rejected/Reasons for Rejection at Initial Assessment

If the Change is rejected at the Initial Assessment stage the Change Manager must
document in full the reasons for rejection and ensure that decision is communicated to
the Change Initiator.

RFC Status
The Change Manager will change the RFC status to either ASSESSED (which indicates
that the RFC will be progressed and that a Priority and Category have been assigned) or
REJECTED BY THE CHANGE MANAGER (which indicated that the RFC has been
rejected at Initial Assessment and will be returned to the Change Initiator).

Date Change Initiator Informed of Change Rejection

The date the Change Manager informed the Change Initiator of the Change Rejection
and the reasons.

Priority Assigned (examples!)

The Change Manager assigns the Change a Priority based on the following information:

E - Emergency, needs doing immediately (Emergency Change Process)

H - High, needs doing within 48 hours
M - Medium, needs doing within 5 days
L - Low, needs doing by indicated date

Category Assigned

Category is based on the required level of authorisation.

The Change Manager assigns the Change Category based on the following information:
• Standard Change – Using a Procedure – Pre-authorised
• IT Change Model – Using a Procedure – May need some level of Authorisation
• Minor Change – Authorised by Change Manager Alone
• Significant Change – Authorised by a CAB
• Major Change – Authorised by a CAB (Senior Level)

Risk of Change to the Business

Priority is based on how quickly the Change needs to be implemented.

The Change Manager assigns a Risk rating based on the following:

• H – High Risk to the Business
• M – Medium Risk to the Business
• L – Low Risk to the Business

Page 5
Impact of Change to the Business

The Change Manager assigns an Impact rating based on the following:

• H – High Impact to the Business
• M – Medium Impact to the Business
• L – Low Impact to the Business

Change Authorised By
The Change Manager needs to document all those who authorised the Change based
on the following:
• Standard Change (via Heat) – Using a Procedure – Pre-authorised
• IT Change Model – Using a Procedure – May need some level of Authorisation
• Minor Change – Authorised by Change Manager Alone
• Significant Change – Authorised by a CAB
• Major Change – Authorised by a CAB (Senior Level)
• Emergency – Authorised by the CAB/EC

If the Request for Change has to be authorised by a CAB then the Change Manager
cannot complete this section until the CAB meeting has been held and the appropriate
authorisation given.

RFC Status
Once the Request for Change has been authorised either by the Change Manager (for
Minor Changes) or the CAB (for Significant or Major Changes) or the CAB/EC for
Emergency Changes the Change Manager will change the status of the RFC to –
AUTHORISED.

If the CAB rejects the Request for Change the Change Manager will change the status
of the RFC to REJECTED BY THE CAB.

Additional Change Information

The Change Manager identifies the following with input from other Service Leaders to
ensure that the appropriate resources are allocated to the Change.

Change Builder Identified – Full Name and Department.

Type of Testing Identified – What type of testing (if any) needs to be completed prior to
the Change being implemented. If no testing is to be carried out – NO Testing needs to
be documented in the Request for Change and any potential risks identified.

Change Tester Identified - Full Name and Department.

Page 6
Part Three – Completed by the Change Builder

RFC Status
The Change Builder will change the status of the RFC to IN BUILD.

Date Change Building Completed

The date by which the Change Build has been completed.

Change Dependencies Identified

The Change Builder needs to consider any Change Dependencies that may have an
impact on this Change being built and implemented. This may include the consideration
of order in which any dependent changes need to take place – and potential risk and
resource implications. The Change Builder will need to check all Changes that have been
authorised and are potentially being built by other teams and also any changes that are
currently being assessed to ensure that no dependencies exist. If there are dependencies
they need to be document in this section of the Request for Change.

Details of the Change Backout Plan

The Change Builder needs to document a Change Backout Plan in detail, which can be
used in the event that the implementation of the Change is not successful. This plan
needs to document the timing at which the Backout Plan should be invoked – i.e. at what
stage is the Change implementation considered unsuccessful. The plan also needs to
include who can authorise the implementation of the backout plan.

Page 7
Part Four – Completed by the Change Tester

RFC Status
The Change Tester will change the status of the RFC to IN TEST.

Date Change Testing Completed

The date by which the Change Testing has been completed.

Change Dependencies Identified

The Change Tester needs to consider any Change Dependencies that may have an
impact on this Change being built as a result of the testing. This may include the
consideration of order in which any dependent changes need to take place – and potential
risk and resource implications. The Change Tester will need to check all Changes that
have been authorised and are potentially being built by other teams and also any changes
that are currently being assessed to ensure that no dependencies exist. If there are
dependencies they need to be document in this section of the Request for Change.

Details of the Testing Carried Out

The Change Tester needs to document all Testing carried out.

Backout Plan Tested

The Change Tester needs to ensure that the Backout Plan is tested and that this is
documented in the Request for Change.

If Change Failed Testing – Reason for Test Failure

The Change Tester needs to document if the Change Failed testing and the reasons for
this failure. They may also make any observations or recommendations that they feel
would be useful for the Change Builder as part of the re-build of the Change.

Date Returned to Change Builder for Re-building

The date the Request for Change was returned to the Change Builder for re-building
following a Change Test failure.

Page 8
Part Five – Completed by the Change Implementer

RFC Status
The Change Implementer will change the status of the RFC to AWAITING
IMPLEMENTATION.

Change Communicated To
To ensure that the appropriate parts of the Business, other IT Groups and the User are
aware of Changes that will impact them the Change Implementer needs to ensure that
Change is communicated at an appropriate time BEFORE the Change is implemented.

Date of Change Communication

The date the Change Communication was sent.

Scheduled Implementation Date

The date the Change Implemented has been scheduled to take place.

Date Change Actually Implemented

The date the Change was actually implemented – if this is differently from the
Implementation date that was agreed reasons for this change need to be documented
here in the Request for Change. Details of who authorised the bringing forward or delay
of a change also need to be documented.

Issues Encountered
Issues encountered during the Change Implementation need to be documented. Even if
issues are encountered that do not lead to the use of the Backout plan they must be
documented to ensure that they are known and discussed at the Change Review.

Backout Plan Implemented Y/N

If the Backout Plan was implemented this need to be documented.

Backout Authorised By
The Name of who authorised the Backout of the Change needs to be documented, if the
backout plan was implemented.

Date Backout Communicated to the Change Manager

The date the Change Manager was informed that the Change was not successful and
that the Backout Plan was implemented.

RFC Status
The Change Implementer will change the status of the RFC to IMPLEMENTED if the
implementation was successful – if the Change was backed out the Change
Implementer will change the status of the RFC to CHANGE BACKED OUT.

Page 9
Part Six – Completed by the Change Manager
Change Review Post Implementation - Review Information

RFC Status
The Change Implementer will change the status of the RFC to AWAITING REVIEW.

Date Change Reviewed

The date the Request for Change was reviewed prior to Closure.

Change Reviewed By
The Change Manager needs to document all those who attended the Change Review.

Change Successful
The Change Review team needs to decide the criteria on which they base a successful
change this will vary according to the Change being reviewed. The Change Manager
needs to be documented the final decision made.

Backout Plan Successfully Deployed (if appropriate)

If the Backout Plan was deployed – the success of the back out deployed needs to be
documented. If for any reason the Backout Plan was deployed and it was not successful
this also needs to be documented with details as to why it failed.

If Backout Deployed – Date Initiator Informed

If the Change was Backed Out the Change Manager need to communicate to the
Change Initiator that the Change has not been successful and return the RFC to the
start of the process for re-assessment.

Date RFC returned to the Start of the Process for Re-Assessment

The date the Change Manager returned the RFC to the start of the process for re-
assessment.

Review Details
The Change Manager needs to document any other discussion points that were part of
the Change Review – as a Lesson Learned.

Change to become a Procedure

If the Change is one that has been repeated on a number of occasions the Change Review
team need to assess it in line with the option to make it a Standard Change (implemented
through the Service Desk or Change Model). If it is to become a Procedure it needs to be
allocated to a team member for writing and a review and implementation timescale agreed.

Change Closed
The Change Manager need to ensure that the Status of the Request for Change needs
to be changed to CLOSED to completed the process.

RFC Status
The Change Manager will change the status of the RFC to CLOSED. However, if the
Backout plan was implemented and the Change was not successful the RFC will not
have a status of CLOSED but the Change Manager will return the RFC to the start of the
Process for Re-Assessment, the status, therefore, will be AWAITING RE-
ASSESSMENT.

Page 10
Part Seven – Completed by the Change Manager
Change Advisory Board Meeting Information

Date Change Advisory Board Meeting Held

The date the Change Advisory Board was held.

CAB Attendees
The Change Manager needs to document all those who attended the Change Review.

CAB Comments/Issues/Decisions
The CAB need to review the Change against a number of pre-defined criteria – the
attendees comments, issues and decisions need to be documented.

If Rejected – Reasons for Rejection by the CAB

If the Change is rejected at the CAB stage the Change Manager must document in full
the reasons for rejection and ensure that decision is communicated to the Change
Initiator.

Date Change Initiator Informed of Change Rejection

The date the Change Manager informed the Change Initiator of the Change Rejection
and the reasons.

Escalation of Change Authorisation Required

If the CAB cannot make a final decision on the Authorisation of a Change then the
Change Escalation needs to be initiated by the Change Manager to ensure that
Authorisation is given (via escalation) at a higher level. The Escalation of Change
Authorisation is documented in the ISS Change Procedure.

Date Escalation Made

The date the Change Manager escalated Authorisation of the Change to a higher level
than the CAB.

Final Decision Made

The date and the Authorisation Decision made via the Escalation Process as outlined in
the Change Procedure, and the Name of the Decision maker.

Page 11