Does your Change Management Process Need a Conversion?

We are 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.

1. 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.

• 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 lessons learned session to understand what went well, what didn’t and how we can improve the process in the future.

• Business
• Technology
• Information Security
• 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!

4. 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.

5. 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 post-implementation review?

I hope this has helped to de-mystify and simply change management.  If you need help with your change management policy or understanding the process, please contact us at support@bedelsecurity.com.

Additional Resources:

The Virtual CISO Whitepaper
https://www.bedelsecurity.com/the-virtual-ciso-whitepaper

The Perfect Meeting Agenda to Improve IT & Cyber Governance
https://www.bedelsecurity.com/blog/the-perfect-meeting-agenda-to-improve-it-cyber-governance 

Your Information Security Program Needs Focus
https://www.bedelsecurity.com/blog/your-information-security-program-needs-focus 

Two Essential Ingredients to Improve Your Information Security Program
https://www.bedelsecurity.com/blog/two-essential-ingredients-to-improve-your-information-security-program 

The Gist of Governance
https://www.bedelsecurity.com/blog/the-gist-of-governance