Does Your Change Management Process Need a Conversion?

By Stephanie Goetz, Bedel Security

We have been seeing findings related to change management cropping up in several audit reports this year. Appropriately scoping change management can be tricky in smaller financial institutions which do not code their own applications. In such cases, pointing to a third party or managed IT provider may cover many of the controls needed, such as coding, testing, back out plans, etc.

However, the trick here, as always, is understanding the roles in the bank vs. third party. We all know very well that while we outsource the responsibility of performing the task the bank is still ultimately responsible for risk.

For each step below ensure it is covered in a policy and understand who is responsible for which step as well as the communication points between your bank and the third party to ensure your bank has the oversight needed to understand and manage the risk.

Risk rate your changes

This is where efficiency can really kick in. Low risk and standard changes can fast track through the process with appropriate documentation and approval. Significant rated changes, though, require the full gamut of the process because they are high risk prior to implementation. Also considered as high-risk changes are emergency changes, but due to the emergency at hand we ask forgiveness so to speak, by creating the documentation and testing on the backend.

Here’s a breakdown of the change types:

- Standard – (moderate risk) A simple and common change with a process and procedures in place to mitigate impact, such as implementation and testing procedures. Example: Firewall changes or patching.

- Low – (low risk) Defined as having limited potential impact to Bank and Customers. Example: A minor software configuration change.

- Significant – (high risk) We define those as having significant impacts customers or bank operations to a considerable degree or considerable resource requirements and difficulty of the change make it a significant risk to the bank. Example: This would typically be a new system implementation, addition of a module, or major upgrade.

- Emergency – (high risk) This change requires quick action due to an outage or high impact to customers and operations. Example: A network outage bringing all systems down.

Create your process path for changes

Based on your risk assessment above, your changes should go through the steps below. Some of these steps will take more time for higher risk changes, but the low can breeze through with documentation of the authorization and the significant changes will require more time to understand the impacts, create a test plan and get authorization and coordination needed to successfully implement the change.

- Authorization – Approval to make the change by the system owner and if necessary, the Change Advisory Board (CAB), discussed below.

- Test – Document the test plan for the change. How will we know it’s working as intended? Low changes may only require the technician to test, however new implementations may need testing from one or more departments in the bank. Also, don’t forget to test the security controls both new and existing. You may even consider a penetration test for critical internet facing systems prior to moving the change into production processing.

- Backout plan – If the change doesn’t go as planned how to we revert back to the previous version? Do we have adequate backups available to do so? Who needs notified of this so that operations are not disrupted?

- Timing – When is the best time to make the change? Monday morning may be a great time or a bad time depending on who is involved.

- Post-Implementation Review – This is a lessonslearned session to understand what went well, what didn’t and how we can improve the process in the future.

Have a CAB

For those high-risk changes, the Change Advisory Board (CAB) should review them in the authorization stage. This is the governing body for the changes as well as the process (explained in #2 above) and should include representation from the following roles: Business, Technology, Information Security, and Internal Audit

This doesn’t have to be a newly formed group, rather you may be able to leverage a current management level committee for this, such as an IT Steering Committee, just add an agenda item and voila, we have a CAB!

Train users on the changes, if significant.

Don’t forget as we identify the changes to the system, and perhaps business processes that the users of the system may need training to execute their jobs. This should be discussed, planned where needed and approved by the CAB.

Document the changes

Since we’ve been doing all this great work, let’s take credit by documenting and showing the auditors and examiners how well we are doing! Documentation can be in a ticketing type system or documented and saved in files for a simpler environment. Documentation should include at least the following for each change:

- Requirements – What changes are required? Why are these needed? How did we risk rate this change?

- Authorization – CAB or other approver if a low or standard change.

- Changes made – What changes were actually made when all was completed?

- Results – What did we learn from the postimplementation review?

Hopefully this helps to de-mystify and simply change management process!

About the author: Stephanie Goetz, CPA, CISA, CISSP, is the VP COO as well as a Virtual CISO Senior Advisor for Bedel Security. She began her career as a financial and information technology auditor, before getting her CISSP and pivoting into the world of information security for financial institutions. IBA Associate Member