Forget About IT Compliance

By Scott Blake, SVP & CIO, Bangor Savings Bank

Scott Blake, SVP & CIO, Bangor Savings Bank

If there is one thing all bankers agree on, it is that our regulatory burden is a heavy weight to bear. For IT, some shops spend a lot of their time just on compliance. Should compliance be the main driver for our work? Are our resources best spent on being compliant? Does compliance accomplish anything useful? Some regulations around disclosures and retention, among others, can seem very arbitrary, perhaps even capricious in a few cases. Auditors and examiners who take a very rigid interpretation of the rules can amplify this perception. Most of us have more than one story of a seemingly ludicrous finding, mandate, regulation, or law that we got hit with requiring an over-the-top or expensive response that added nothing to our security.

“Balanced against the risk of system disruptions caused by bleeding-edge software, it makes sense to stay with the most current stable versions available.”

As much as the facts themselves, we often struggle with what appears to be inconsistency. Most of us know a peer who was compelled to do something that we were not required to do. Sometimes, we have been told to change a practice we have had for a long time, but seemingly all of a sudden becomes unacceptable. A situation that was fine last year becomes a problem this year.

Although I have my share of these stories, too, I find that a bit of perspective is helpful. I saw a bumper sticker recently that read, “Everything happens for a reason. Sometimes the reason is that you make bad choices.” Similarly, every banking regulation exists for a reason. In almost every case the reason is that a bank (or perhaps many banks) behaved poorly. It wasn’t our bank (of course), but we now have to make up for the bad apples. Like so many things in life and law, an incident or pattern created a perceived need to, “do something about it,” on the part of our lawmakers or regulators. We may not like it and we may not agree with it, but it is always possible to find the reason for the rule.

A recent example might be the push to convert off Windows XP when support ended for that platform a couple years ago. We were all asked by the powers that be to have a plan and demonstrate execution of the plan to be converted to a supported platform on time. Most of us even accomplished the task (at least mostly) before the deadline. The hardest part for many of us was converting the ATM fleet. What was the reason for this rule? Is end of support such a big deal when the platform still works and all our applications run on it? When is the last time you needed support on a desktop operating system issue?

The return on investment for operating system upgrades is generally zero (or worse). It is disruptive to our regular projects, to our end users, and, sometimes, to our customers. It is true that the day after support ends, nothing untoward happens – there’s nothing magic about the date. However arbitrary the end-of-support date is, it serves an important function of being a line in the sand. On one side of the line, we know the vendor is doing what they can to keep the technology current and safe. On the other side, the vendor is doing nothing at all. With 6,419 new vulnerabilities published in 2015, it is a very good bet that there were also a large number discovered that were not published. Staying current with versions and patches is just good risk management. The more time the bad guys have with a system, the more likely they are to find vulnerabilities. Balanced against the risk of system disruptions caused by bleeding-edge software, it makes sense to stay with the most current stable versions available.

Even though simple risk calculations tell us to stay current, there are plenty of organizations that choose to stick with older versions. Many years ago, I was with a group of security executives getting briefed on the new security features in Windows Vista (which were pretty impressive at the time). When asked what we thought about this and when we might start to convert, one of my colleagues said, “This looks great and we like what you’ve done with security here, but there’s nothing here that will help my company sell more of our products so we will upgrade when you put a gun to our heads and pull the trigger.” That attitude, which is perfectly justified and completely reasonable in context, is the reason we are asked to demonstrate our record of keeping things patched and to show that we have completed our upgrades.

If, on the other hand, we started planning now for our conversion to Windows 10, if we were proactive about patching, if we used our innovative energies to find new ways to protect our customers, we might find ourselves in a very different environment.

The headline on this piece is intended to be provocative, but the idea is very straightforward. Focusing on the mandates is less productive than focusing on doing the right thing. Sure, there will likely always be the one-off item that needs to be done so you can check a box, but the vast majority of “compliance” is really just doing a good job of managing the resources we are entrusted with. Should you have a change management regime because the auditors and examiners say you should have one? I submit that we should have a strong change management regime because we will have less downtime, smoother upgrades, greater collaboration between departments, and increased visibility into our organization’s needs. It is possible you might need to tweak something to satisfy an outside evaluator, but more likely they will spend their energy elsewhere.

Vendor management came into vogue a few years ago; following some high profile incidents where corporate networks were breached because of insecurity at vendors that had access (remember the reason for the rule). Banks that recognized the potential for this threat vector long ago were well-positioned to meet the new requirements and may not have had to change anything. Other institutions that did not recognize the risk had to implement new and expensive programs to introduce monitoring. Those who waited to be told they had to do it also had the pleasure of having time pressures to respond. Plenty of consultants made good money helping banks respond to the “new” requirements.

For too long, our industry has been reactive to the demands of auditors and regulators. The time has come for us to take proactive steps to ensure the safety and soundness of our institutions’ IT. In the long run, it will be cheaper and more effective for our industry than continually playing catch up.