2.125.1 Change Management Policy

Manual Transmittal

September 19, 2018


(1) This transmits new IRM 2.125.1, Change Management, Change Management Policy.

Material Changes

(1) Separates the Configuration and Change Management policy and mandates from IRM 2.150.1 Configuration and Change Management Directive.

(2) Updates new process ownership to Demand Management & Project Governance under Enterprise Operations.

Effect on Other Documents

IRM 2.150.1 Configuration and Change Management Directive dated September 20, 2013 is superseded.


The Change Management Policy is applicable to all Information Technology (IT) organizations, contractors, and other stakeholders having responsibility for change, management, oversight, and successful day-to-day operations of the IRS IT enterprise hardware, software, and applicable documentation.

Effective Date


S. Gina Garza
Chief Information Officer

Program Scope and Objectives

  1. This document describes the formal Information Technology (IT) policy for implementing the requirements of the Change Management (ChM) process. It provides the purpose, scope, authority, and mandates for institutionalizing this process.

  2. The objective of Change Management is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to control the IT infrastructure, to minimize the impact of any related incidents upon the service. All changes must be recorded and managed in a controlled way. The scope of Change Management covers changes to all configuration items (CIs) across the whole service lifecycle.


  1. The IRS IT organization supports hundreds of servers, applications, software, databases, and services, in addition to various network configurations, resulting in a large and complex environment. A change to any of these configuration items may introduce risk to availability, capacity, reliability, and performance. Managing changes to these configuration items mitigates risk and improves operating efficiencies. A formalized IT Change Management Process is designed to ensure that changes are authorized and operate as intended.

  1. The purpose of this Policy is to establish formal requirements to manage changes to IT systems, infrastructure, and services, ensure that a consistent and systematic approach is used for implementing changes, and control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services. This includes establishing an IT-wide Change Management Program and to provide responsibilities, compliance requirements, and overall principles for the Change Management process to support information technology management across the IT organization.

  1. This Policy is applicable to any change that might affect the IT systems, infrastructure, and services in the IT environment. This should also include changes to all architectures, applications, software, tools, and documentation, as well as changes to all configuration items across the whole service lifecycle.


  1. Demand Management & Project Governance (DMPG) is responsible for the development, implementation, and maintenance, of this policy. Approval of this policy, including updates, rests with the Change Management Program Management Office (ChM PMO) under DMPG. All proposed changes to this directive must be submitted to the IT Service Transition Programs (ITSTP) Section under DMPG.


  1. All Changes to Configuration Items (CIs) will be registered. To maintain accurate information and status of CIs, any proposed change to CIs supporting any IRS system, e.g., Production, Development, Test, Disaster Recovery, etc., will be recorded as a Request for Change (RfC) in the approved Change Management system.

  2. All Changes must be approved prior to implementation. All changes to CIs supporting any IRS system, e.g., Production, Development, Test, Disaster Recovery, etc., must be approved prior to their implementation.

  3. All Changes must be deployed in an approved window. All changes shall be scheduled for deployment in an approved window, and can only be deployed outside that window if there is an accompanying Priority 1 or Priority 2 Incident Ticket that justifies the exception.

  4. Risk, Technical, Security, and Business Impact Assessment. All changes will be assessed for risk and categorized based on risk. All RfCs must include an assessment of the risk and business impact of the change, as well as applicable technical and security assessments of the planned work. Changes impacting the forecast business results, documented in a work request, business case, or equivalent justification will be presented to the appropriate IT Executive Steering Committee (ESC) or Governance Board (if low risk and or low cost) for acceptance of the impact prior to approval of the RfC. This ensures a comprehensive review of proposed changes before they are authorized and approved for release into production.

  5. Review of Unsuccessful Changes and Incidents Caused by Change. When changes are implemented, the success or failure of the implementation must be recorded on the RfC. Changes considered not successful include changes not implemented as planned; changes backed out, all or in part; changes not implemented per schedule; and changes causing incidents. These unsuccessful changes will be reviewed by Change Management staff to determine the cause of the failure and plan remediation actions for the future.