Change Management Procedure

Bryan Stow
April 10, 2024

Overview

The Change Management Procedure, as part of the Change Management Program, controls any additions, deletions, or modifications to the configuration of information technology systems and software as well as a new vendor, product or services. 

Information technology system changes as well as new vendors, products or services could have an adverse impact on the security or reliability of the system, especially on critical information technology systems as well as risk to the bank. Therefore, all requests for changes must first be evaluated and approved to provide a controlled operating environment and to preserve security and reliability. A change / project request and approval process will be used that can document submission, investigation, review, and approval for all changes. All requests must be documented, and their status tracked through completion.

Evaluated Requests are subsequently classified as either:

Requests are the starting point as noted before. These are break fixes, permission change requests, marketing requests, supply orders, compliance requests, deposit group inquiries, loan group inquiries or branch requests for assisting either the loan or deposit group to remedy something for a customer.

Changes are the next step up which require more details to be documented and approval before they can be moved forward. Some things that fall under this level of escalation are Rate Changes, Process, Product, or Service Changes, Software Upgrades, Equipment Replacement, New Vendors or Software, Disclosure language changes, Security changes and much more.

           o Note: Software updates where a detailed, accepted test procedure is in place at the bank do not require a secondary approval by the IT Committee. Once the initial approval is complete without any concerns the Change can be escalated.  

Projects are the highest level of escalation and require even more level of detail documented than Changes, these are major things that are happening at the bank that are above and beyond a Change in either time and/or resources and/or monetary expense. A few examples would be upgrades to a building, new branches openings, purchasing another bank, closing a branch, and major vendor changes such as replacing i-banking vendors. If this project is related to a new third-party service or a new third party replacing an existing service, determine if a "Bank Service Company Act" notification is required (FDIC FIL-49-99). See the Bank Service Company Act Reporting Procedure in SharePoint.

Process to enter a Request:

1. Support request is entered for evaluation through Onbase.

2. Request Review Team evaluates the request and classifies it as Break/ Fix Request or one to be escalated to a Change or Project.

     a. The Request Review Team are the staff who regularly review and assign tickets (Wes, Bryan, Todd, Tina, Adam)

     b. If the request is denied a note in the completion section will be filled out by the person denying the request.

3. A Break/ Fix is Assigned to the appropriate Department and Staff and completed based on priorities and available resources.

4. If the request is to be escalated, a person will be assigned the Primary Assignment Role. A member of the Request Review Team will then Escalate the Request (they         can close the form at this time). The person who initially entered the request (the requestor) will be notified via email with a link to the form and will fill out the         required documentation.

5. The requestor will be responsible for completing the documentation and impact areas. All the sections should be filled out in detail and if necessary, the requestor          should reach out to a member of the request review team for assistance.

       a. The impact areas should include any department that will be directly or indirectly impacted or that will be a resource for the request. If you are not sure, please                  reach out to one of the reviewers to guide you through this step.

       b. The Reason for Change should detail WHY this request is needed.

       c. The Proposed Change should detail WHAT this request covers.

       d. The Backout Process, if needed, should cover how to revert the change if it becomes necessary.

       e. The Security Concerns should list any and all areas of security that may be concerns. If you are unsure of this, please reach out to the IT Director or the Security Office for assistance.

        f. The Training and Documentation should include anything required to make the request fully operational and supported by staff. This also must be completed                 prior to the request being closed.

6. When the form is completely filled out the Ready for Approval button is selected by the change / project manager which sends this to the approvers for the first review.

7. The approvers receive an email with a link to the request for change so they can review the documentation and either approve or deny the request. The approvers can also add comments to the decision.

8. Once all the approvers have made there comments the request will be approved or denied by each member of the IT committee. The members of the IT committee will receive an email with the subject “Approval's Completed Escalation Decision Needed” stating the requested change is ready for Final approval. This is done by selecting the “Change – IT Committee Only” button on the change request. In general, this approval is made following the review at the monthly IT Committee Meeting.

     a. If a Change request is denied by any member of the approval team the reason must be documented in the comments section. The IT Committee will still review the request and determine if it can move forward or if it is denied.

9. Once approved and escalated to a change, roles are automatically created for some specific tasks. Additional roles can be assigned out to help complete work or provide information needed to ensure a successful implementation.

PROJECT – If, at the Approval level, the request meets the defined Project criteria it will have additional Phases created in the Schedule & Tasks section to assist in planning and tracking of the project. Additional Phases can be created as needed for specific projects. Projects also have an area to track vendors who may be involved and their roles in project. Similar to the Change request, the roles will automatically be created for some specific tasks, and additional roles can be assigned out to help complete work or provide information needed to ensure a successful implementation. The Final approval will also follow the same process as the Change request listed above through the IT Committee.

Related articles