After drafting an IT change request, the next step is for an organization's IT change management professionals to complete their review. For projects large and small, this is a vital gatekeeping step within the change management workflow, one that goes far beyond a simple yes or no. 

Who Reviews an IT Change Request?

When reviewing requests, it is important to have representation from operations, technical, and functional decision-makers (product owners and stakeholders) within the organization. The team itself is usually comprised of one or more of the following “change authorities,” sometimes organized into a more formal Change Authorization Board (CAB) or Change Control Board (CCB): 

  • IT Change Manager
  • Subject Matter Expert (SME)
  • Release Manager
  • Technical Application Manager
  • IT Operations Manager
  • Information Security Manager
  • Communication Manager
  • Business Representative
  • Representation from 3rd Parties

What are the Parts of an IT Change Request Review?

The first step in the process is to review the completeness and accuracy of a request, to send back incomplete requests for more information, and to prioritize any requests that are accepted for formal review. From there, the review team is in charge of evaluating a change request from a couple of points of view, including: 

  • Business and security impact
  • Risk and benefits assessment
  • Contingency plans for backing out
  • Contingency plans for accommodating changes midstream

Business Impact Analysis

Above all else, what is the anticipated impact of the change request? Answering this question is the central role of a business impact analysis (BIA). This is the time to thoroughly consider how any disruption resulting from the change request might impact employee productivity, cost, revenue, and even brand reputation. Is there a risk of an outage? Delays in the shipment? Regulatory fines or damage to company assets?

What happens if employees cannot work effectively because of an outage? How much is that expected to cost?

Understanding the potential risks that might arise from a proposed change is the best way to minimize them. All of this information is usually documented in a BIA report, which is then reviewed during the approval process. These reports can be quite comprehensive for changes to critical systems, and more straightforward for simple or recurrent change.

  • Business or Department Name: Billing
  • Application Name: Invoicing Application
  • Technical Application Manager: Jane Smith
  • Business Owner or Sponsor: Joe Cook
  • Description of Application: Invoice customers on a recurring basis
  • The number of Internal Users (approximate)? 100
  • The number of External Users (approximate)? 10000
  • What are the peak usage times? 9 am-5 pm Eastern Time
  • Acceptable downtime for application (hours): 4
  • Impact to the business if outage exceeds acceptable limit: Billing will be delayed, revenue loss
  • Where is the application hosted? East Coast Data Center
  • What applications are dependent on this? Reporting
  • What other applications are required for this to function? Credit Card processing
  • When was a security assessment completed? January 1st
  • What is the backup plan? Nightly, Weekly Off-site
  • What is the disaster recovery plan? Switch to West-Coast Data Center within 1 hour of outage
  • List the IT team members/teams required to support the application: Billing Operations, Billing Dev


Security Impact Analysis

In a similar fashion, a security impact analysis (SIA) details the security impact of a proposed IT change request. What’s the risk for data loss or the breach, malicious hacks, or vulnerabilities to building and employee security? What about malware or theft? Again, the depth of this report will depend on the nature of infrastructural change. As such, an SIA can be either a standalone report or part of a broader BIA.

  • Are there changes to application roles/permissions or password policies? 
  • If so, is training required for admins?
  • Are there changes to how the application logs or audits?
  • Has the infrastructure or hosting arrangements changed?
  • Are there changes to data storage?
  • Are there changes to encryption methods?
  • Are there changes to authentication methods?
  • Any new personally identifiable (PII) data introduced?
  • When was the last vulnerability scan conducted?
  • When was the last penetration test conducted?
  • Does this change require a new vulnerability scan or penetration test?


Backout Procedures

Sometimes, IT changes fail to deliver expected results or fail completely. Consider backout procedures the contingency plan, created and documented in case things go awry after a change request is deployed. 

Backout procedures (aka Rollback procedures) are the approved steps that an organization can follow to revert back to the state of things before the new technology was rolled out, software integrated, or update carried out. It automatically sets in motion the who and the who-does-what. For larger-scale change requests, it is essential that backout procedures are put in place before the approval and implementation phases commence.

  • What specific steps are required to revert the change?
  • Does the change require immediate fix during the deployment window?
  • What will be the impact on users during the backout process?
  • What will be the impact on users if the data application is reverted to the prior version?
  • What will be the impact on users if the data is reverted to the last backup?
  • What technical resources are required for the procedure?
  • Who will confirm the application is working properly after the rollback?
  • Who is required to approve the backout?
  • What is the communication plan?


Significant change procedures require even more detail or scrutiny. Typically, significant change procedures are needed for high-risk change requests, such as updates to critical IT infrastructure. These changes typically involve multiple decision-makers from across the organization, elevated approval requirement workflows. They usually necessitate updates and approvals for various diagrams and order-of-operations documentation.

Automate for Better Efficiency and Risk Control

The amount of time required for an IT change request review will vary. As with most parts of the review itself, the scope, impact, and risk of a change request will be the determining factor. Yet companies can use IT change management software to help automate workflows, limit human error and other variabilities, and complete the review in the most resource-efficient way possible.

Process Manager is more than a rigid workflow – it’s a step-by-step guide to proper change management. By providing requirements and guidance on processes like risk analysis your users can react to, Myndbend Process Manager makes it easy for them to document the proper considerations every step of the way.




Once an IT change request review process is complete, it is time to move on to approval. For a detailed look at this next step, read more here: A Guide to the IT Change Requests Approval Process.