Change management

While there are people that enjoy change and embrace the new, it induces a lot of anxiety and uncertainty for most. It’s no surprise that Dr. Spencer Johnson’s 1988 book “Who Moved My Cheese?” is one of the best-selling business books of all time. Dr. Johnson’s book explains how to deal with unexpected change and how to turn that anxiety into opportunity. It is generally accepted as the guideline on how to manage change in your life.

When it comes to financial institutions, though, change management is a totally different story. In financial institutions, change management policies and procedures define how changes are made to critical technology systems, ensuring that changes are requested, approved, implemented and reviewed in a consistent manner. Until recently, only large and/or publicly traded institutions needed to think about formal change management processes. However, this has changed in the last few years. With the publication of the FFIEC’s Cybersecurity Assessment Tool (CAT) and the NCUA’s equivalent Automated Cybersecurity Examination Tool (ACET), it is now a baseline requirement for all institutions to have a formal change management process. This means that every financial institution, regardless of size, must have a program that explains how the institution defines and manages changes to its technology environment.  

If financial institutions are subject to Sarbanes-Oxley or enhanced FDICIA procedures, they are likely already familiar with the change management requirements. These institutions are required to have formal change management processes and must prove — through their annual financial statement audit — that any changes made to systems that affect financial reporting are performed properly and with the appropriate authorization. Tickets are pulled and reviewed as part of the audit to ensure that the changes were made appropriately. This is widely accepted as a key control for ensuring the integrity of financial reporting data.

More than likely, your institution is not subject to either of these regulations. You may not even have an annual audit. However, you still need to implement a change management program, and that program should include the following provisions:

• Define what is a change and what is not
• Define roles and responsibilities and specify who can request a change
• Include proper evaluation of risks of the change
• Require proper authorization and approval
• Require proper timing of implementation (i.e., timelines to meet)
• Test procedures for the change
• Have a post-project review (evaluate factors causing delay, measure completion and success)
• Include backout and recovery plans

Let’s look at these provisions in detail.

• Define a change. This is somewhat subjective, but the general rule is that if it’s a routine procedure, it is not a change, but if it has a broad effect or includes critical systems, it is a change. Unlocking a user who forgot their password is not a change. Adding a new user to the core system is a change. Replacing a computer because the hard drive went bad is not a change. Replacing all the computers because of Windows 10 is a change. Checking logs on your firewall is not a change. Replacing the firewall is a change.
• Define roles and responsibilities for change management. This is neatly summarized as defining who can request changes. Usually this is centralized with the person in your institution who handles technology, whether that’s your CIO, your IT Officer, or whoever handles your outsourced technology provider. In theory, anyone in your institution can make a request, but formal requests should be limited to two or three key players within the institution.
• Outline evaluation of risks of the change. This is probably the easiest one to decipher. Is it worth the money and the hassle? Often with technology changes, the issue is obsolete hardware and software, where your decision is driven not by “what do we gain by implementing this change?” but rather “what happens if we don’t?”
• Require proper authorization and approval. Who can approve the change? Ideally this should be your technology steering committee, but in smaller institutions, this might just be the CFO or President. Whoever the approver is, they should be independent of the requestor.
• Require proper timing of implementation. This is also fairly self-explanatory. You need to determine whether there is a hard deadline, like there was for Windows 7, or if there is some other hard deadline driven by business needs. Otherwise, it’s usually the vendor that tells you when they can get it done.
• Test procedures for the change. This is going to vary widely depending on the change, but you need to include some provisions for testing. Do the new firewalls work?  Can I still print now that I’m on Windows 10? Does my new employee have the right access to the core?
• Include a post-project review. Once the change is done, determine whether it went as planned. Document what worked and what didn’t so that you can replicate the successes and avoid the pitfalls.
• Include backout and recovery plans. Make sure every change has a process so that you can back out — or bail out — if the change does not go as intended.  

So now that we’ve gone through the details of all these pieces, I’m sure many of you are thinking, “Wait a minute. I’m at a $100 million community financial institution with 20 employees. How am I going to come up with all of this?” My answer to you is that you already have this process in place. Your IT support company isn’t just going to show up one day with new firewalls. Someone has to ask them to provide a quote for that service. It has to go to your technology committee (which might just be your CFO and CEO) to be discussed. Is it worth it? Why do you need it? Then the proposal has to be approved. A schedule has to be figured out. You have to make sure it works when it’s done. And you have to make sure you have a contingency plan in case it doesn’t work (by the way, this usually entails plugging the old one back in).  

That’s it. That is your change management plan. If you are large enough to justify a standalone change management policy, go ahead and write a standalone policy. If you don’t see the need for a separate policy, integrate this language into your overall IT security policy. A large institution might need a multi-page standalone change management policy. For the smallest institution, I often say, “Once you get to the top of the second page, stop typing.” Keep it as broad as you can and leave the details to the individual change requests. Once you have all of this in place, you’ll not only know exactly who moved the cheese, but why they moved it, when they moved it, and how they moved it.