Blog post

Two Inconvenient Truths about IT Compliance

By Erik Heidt | May 17, 2013 | 0 Comments


I am very pleased to announce that my first document Achieving IT GRC Sucess has published this week and is now available to Gartner for Technical Professionals subscribers. The research and writing process led to many interesting conversations about governance, risk management and compliance with clients and colleagues. Let’s examine two “inconvenient truths” about IT compliance…

IT Compliance Doesn’t Exist!

IT clearly has a significant amount of compliance work that it performs – no doubt about it, especially in highly regulated industries. IT, of course, exists solely to support business objectives. The compliance requirements that IT fulfills are derived from those business objectives. Here are a few quick examples:

  • PCI compliance results from a business desire to accept payment via credit cards.
  • IT and Information Security have a role in achieving overall SOX compliance, which results from an organizations status as a US based public corporation (and desire to remain so).
  • IT requirements for HIPAA result directly from an enterprise need to process confidential healthcare data.

Yet, it seems that in many enterprises IT compliance is seen as separate from and in conflict with “meeting business requirements”. This is in spite of the fact that none of the examples above can be achieved without significant efforts from business partners themselves.

So, why is this interesting? In a word: “Resources” – time and money. In most organizations, funding and prioritization of compliance activities is very hard to come by. Much of this may be a perspective problem, as IT organizations often do not include compliance efforts in project prioritization processes side-by-side with other initiatives – that may be a lost opportunity.

Compliance is Risk Management – Just NOT YOUR Risk Management!

Compliance is not a substitute for risk management. Compliance requirements are the result of an external group’s anxiety regarding risk. Usually the external group is either a government body or large commercial concern. Let’s take a second look at the three examples from above:

  • SOX is the result of anxiety over the risks of financial reporting errors and a response to a number of major corporate accounting scandals.
  • PCI is the result of the payment card industry’s desire to ensure minimum standards for the safeguarding of payment card information and transactions.
  • The HIPAA Privacy Rule is a direct result of concerns regarding the use (or misuse) of individual healthcare records by the general public.

In all of these cases, the compliance requirements are designed to address issues to reduce risk to a level that is tolerable by the government or commercial group. The fact that compliance requirements are designed to provide broad and general coverage often results in cases where enterprises could more effectively manage the risk using controls specific to their environment and situation. The fact that this is often not acceptable to examiners is a significant source of frustration.

The last decade has seen compliance mandates become more risk oriented and begin to include risk assessments and control design as a part of the compliance process. Regrettably, all too often new compliance requirements continue to come in the form a checklist.

There are few options available to us to improve the situation. Participation in regulatory rule making is a time consuming process that rarely contributes to success in our “day jobs”. Improving compliance and regulatory rule making is a long game, and the best thing for many enterprises to do is to share their risk management and control design approaches with examiners. Educating the examiners who often have significant influence over the rule making process make be the most productive approach.

Cheers, Erik


Comments are closed