IT Policies & Procedures: Change Management Policy

The following sample outlines a set of policies and procedures for change management.

Prepared By: ______________

Approved By: ______________
Revision Date: ______________
Effective Date: ______________

PURPOSE:
The objective of this document is to provide policy and procedure guidance for implementation of
change management within the network/infrastructure for Company X.

SCOPE:
The major activities included in the Change Management: Network/Infrastructure Management
area are Requests for Changes, Review, Prioritization and Approval of Changes, Development,
Testing, Update of Records (Migration), and Emergency Changes.

These policies and procedures, along with department roles and responsibilities are reviewed by
the Managers of 1st and 2nd Line Support on an annual basis and signed-off by the Director of
Technical Operations. All metrics used to guide and monitor the activities of the Technical
Operations department including tasks to be performed, time frames for completion, and
segregation of duties guidelines will be reviewed annually.

POLICY:
All requests, including those for changes to the IT infrastructure and applications are initiated and
tracked in the automated logging, response, and archiving incident log system. Approved
program changes, approvals, testing, and pre- and post- migration notes are stored in the system
as well. Personnel are instructed to submit change requests directly into the system.

DEFINITIONS:
 DTO - Director of Technical Operations
 BRD - Business Requirements Document

PROCEDURES:

1 Requests for Changes

On a daily basis the log system is monitored by Tech Ops 1st Line Support Technicians for new
incidents, including requests for changes. The 1st Line Support technician opening the incident
report will either accept assignment of the change request, or, forward it to another technician. If
the change request does not provide sufficient information to begin processing, it is returned to
the requestor asking for more detail.

All change request work orders are allocated to the change management category. The requestor
of the change is identified as the business owner. All change requests to the production
environment are reviewed and approved prior to development. Approvals are attached to the
individual work orders and filed in the log system.

2 Review, Prioritization, and Approval of Change Requests

All changes to the network infrastructure and host environment are reviewed and prioritized
based on their significance (either ‘Major’ or ‘Normal’) and their processing priority: P1 (most
severe) to P5 (least severe). The significance category will impact the level of review/sign-off,
testing and controls that will be required for the change request from initiation through to
production release, whereas, the priority level will impact the time period in which the change
request needs to be processed and implemented.

1
Source: www.knowledgeleader.com
The ‘Major’ category will be applied to all change requests that either pose a significant risk for
creating a system outage, or, provide the ability to modify any data used for financial reporting.
This level of change request will require the maximum level of review/sign-off, testing and pre-
production release controls. All other change requests will be considered ‘Normal’ and will require
a baseline level of review/sign-off, testing and pre-production release controls.

Change requests categorized as ‘Major’, are reviewed by executive management and prioritized
according to their urgency (P1, most severe to P5, least severe). The work orders on these
changes are updated as to their scheduled priority of P1 to P5, most severe to least severe.

All significant changes to the IT Infrastructure and host environment including server, network
configuration changes, upgrades, service packs, and network operating software are evaluated
jointly by the CEO and the DTO before deciding upon implementation.

3 Development, Testing and Update of Records (Migration)

All ‘Major’ changes are tested in a test environment before being moved to production. The IT
project owner of the change conducts a test and forwards the test results to the Manager of 1st or
2nd Line Support for review and approval. The DTO reviews and approves all Major changes to
the production environment and documents approval in the incident record.

Testing of development work (in Development environment) is approved by the requesting

business owner and then pushed into QA. The PDM will then approve all appropriate testing in
QA before reviewing with the System Release Engineer and IT Management before migration
into production. Testing is documented within the log system.

Once the change has been tested and reviewed by the Manager of 1st or 2nd Line Support and
approved by the DTO, it is released to the requesting Business Owner for review and approval in
a test environment. All testing, review and approval documentation are maintained in electronic
format and attached to the individual log system work order.

Company X utilizes version control software to allow for potential rollbacks. Version control of the
transactional system is used to facilitate potential rollbacks to any of Company X’s environments.
Upon development of a change, the code is checked out of the version control system and
checked back post-development.

Company X maintains Development, QA, Test, and Production environments for the transaction
systems as well as a Test and Production environment for all other principal applications. All
Company X environments are segregated to restrict development activity within production
environments.

Company X has a dedicated Production Release Engineer who migrates all changes to the
Production environment. Application Developers are restricted from having access to the
Production Environment. Application Development personnel may only access the code for which
they are responsible in the appropriate environments (i.e. Development). QA and test are utilized
by the business owners and QA groups for system, unit, UAT, and regression testing. All
development and testing activity is documented within the log system change request.

Access to Company X production database must be initiated and authenticated through

authorized userids and password. IT personnel may use utility programs for access; however, all
users must authenticate to the production database using userids & password.

All user reference, support manuals and network diagrams are updated as part of every
development project, modification and significant infrastructure change. These updates occur as
part of the development, modification and infrastructure change project.

2
Source: www.knowledgeleader.com
4 System Development Life Cycle (SDLC) Changes
Business requirements are documented prior to the in-house development of an application or
application change, or before a new application is considered for purchase. All "Major" change
requests require the generation of a BRD before the project will be fully considered for
implementation. The BRD is documented and included within the log system request.

TechOps approves all transitions while Executive owners provide final project approval. Upon
review and approval of a high-impact change by Company X Management (pre-planning & kick-
off phase), an SDLC policy is utilized to supplement the change management policies and
procedures when making application, infrastructure or other system changes to the IT
environment. This policy also covers new program and infrastructure developments and
acquisitions.

Post-Implementation review is performed immediately after changes are pushed to production.

Upon the migration of a change, the Systems Release Engineer and the PDM will test the change
in production to ensure functionality and operating effectiveness. Notes and test results are
captured within the log system.

Data Conversion testing is performed by appropriate IT & business personnel to ensure the
completeness and accuracy of data migrations. Test results are approved by the PDM and
maintained within the log system. Company X tests data migration on new or updated
systems/applications as specified within the Change Management policy.

5 Emergency Changes
Guidelines for emergency changes (changes that bypass the normal process for requesting and
implementing changes, for example, changes needing immediate implementation with approvals
following after the fact) are covered in the Data Center Operations & Problem Management
policy. They are stated again here for clarification within Change Management:

Any critical, non-standard operational event, such as a system failure that has or could pose a
significant service delivery interruption, is coded as a P1 (highest severity) incident in the log
system for prioritizing, monitoring, escalation, resolution and archiving. These are events that
have been detected either from monitoring of the network, event log monitoring by in-house IT
staff, or by detection on the part of any IT employee and/or user:

 The IT department staff monitors the server, network environment and log system daily for
non-standard events. This occurs through several processes:
 Internal event log monitoring;
 External monitoring;
 User reporting through the Helpdesk function.

 Emergency events are logged once identified, either by regular IT monitoring, or through user
requests.
 After being identified and logged in the log system, all emergency priority events are
escalated to the DTO and a notification is sent via email. Distribution is to the CEO and the
executive management team.

3
Source: www.knowledgeleader.com