Being A Security Bully Does Not Make You Compliant

Working with large organizations that have large IT staffs, we often encounter who I call “Security Bullies.” These people use compliance as a weapon against everyone, building a bureaucratic infrastructure that is their own private kingdom. While the Security Bully might be an individual, it is more common that the entire IT staff has taken on this behavior.

One easy sign to tell whether you have a Security Bully is the use of compliance as a way to deny most requests for support or changes (or sometimes even help). Even worse, Bullies use compliance as a means to say “no” without having to develop meaningful solutions.

For example, my team developed and supports the software used to operate one specialized department of a large medical center. The software is used for both business and logistical purposes. Some patient data is involved, so HIPAA is applicable. Citing security and compliance requirements, the medical center’s IT staff now exclusively manages the server where the application and database resides.

Recently there was a problem we traced to be a likely issue on the database server. (I say likely, of course, because even though we reproduced the problem and solution on our test server, one only proves a theory by actually solving the problem.)

While it was somewhat obscure, we found a documented database server issue that matched our problem. A hot patch for the server was available to address the problem. Without clearance to work directly on the server, we gave the client’s IT staff our suggested solution and how we arrived at it.

The response back was a detailed list of reasons why the hot patch could not be installed on the server, many of them being security, department, and regulatory rules, without any alternate plan, option, or offer of assistance for the department.

On closer examination, this reply turned out to be a list of excuses to avoid dealing with the department’s problem, since some of their arguments against the hot patch were within their ability and authority to address.

Once I politely reminded the IT staff that their rules prohibited us from direct work on this server and that ultimately it was their responsibility to keep the system working, their rules quickly became more flexible. They installed the patch quickly -- and without even running it on a test server first.

I found the omission of a test server step particularly interesting. When they thought we would have to do all of the work, their list of requirements prior to hot patch installation included setup of another test server (in addition to the one we had in our office). Apparently "the rules" changed once it became their work.

I share this story not to complain, but as a reminder. It is easy to become so focused on compliance and security that we forget the purpose of the organization or the support role of IT. Compliance is important, but it is not a tool for dodging inquiries or work, particularly when the requests are important to an organization's ability to function well.

Glenn S. Phillips, the president of Forte' Incorporated, works with business leaders who want to leverage technology and understand risks within.