Regulatory Compliance and the IT Manager

There are a lot of legislative bodies that are requiring IT to protect information for different reasons. It would appear that IT Professionals now need to add paralegal to their repertoire as we address some of the new challenges to defending the enterprise from those that would do us harm. This should not actually be the case nor should IT bear the entire burden for regulatory compliance within an organization. Whether action needs to be take to address some new piece of legislation does not belong on the head of IT, this needs to be a business decision made by the business. This does not mean however, that IT should stick its head in the sand either.

 

Regulatory responsibility sits in several places within the business. In a perfect world each company would have its own regulatory committee, whose responsibility it is to determine what regulatory legislation the organization is responsible for and what regulatory measures are required to satisfy those needs. It is then that IT can identify how these regulatory requirements impact the protection of electronic assets associated with these regulations. My concern is that within many of the customers I work with, much of the regulatory compliance work is dumped on IT as IT becomes the place where these activities reside and because most organizations do not have a committee to evaluate the regulatory impact on the business. To any IT Professional who allows this to happen, I say “Shame on you!” The real problem is that IT Professionals are trained to be technically savvy and not business savvy.

 

Now, before you drag out your club to smack me out of frustration, lets looks some things that IT can do to alleviate the pain associated with being left to hold the regulatory compliance bag. For whatever part of regulatory compliance that IT is held accountable for should come from a conscious decision of the business that the risk of non-compliance is not acceptable and that there is an executive decision to allocate the resources to satisfy the mitigation of that risk. This cannot be where some IT Professional read Sarbanes-Oxley and decided that measures X, Y, and Z are appropriate. This is just wrong on so many levels.

 

While IT is where the preverbal rubber meets the road for many of these compliance activities, the responsibility should not reside solely within IT. This is where an operational framework can provide a lot of help. Instead of creating a whole new stratum of compliance management, it does make sense to leverage the management functions that are already defined in the organization that are tasked with risk management and auditing compliance management. After all, this is at the heart of regulatory compliance. Compliance is all about being able to prove that your organization has assessed the risks of and is meeting the caveats set forth in applicable legislation.

 

The first and foremost part of any regulatory compliance plan is executive commitment. The executive committee must consciously embrace the notion that regulatory compliance is a necessary part of daily business activities. They must also be aware that there is a cost associated with these activities. This will in turn spawn some sort of reporting process back to the executive committee which will require a focal point in the business for regulatory compliance. Most companies have already taken the first step which is creating a Chief Compliance Officer or at the very least a Chief Risk Officer or Chief Security Officer. Most of these positions are tied to the financial part of the business because financial officers have traditionally borne the burden of proving the authenticity of the financial statements that get submitted to the different regulatory bodies that scrutinizes proper business ethics. These are the people that IT should engage with to identify the risks for the business that are in any regulatory legislation. This should be easy as most companies are structured where the CIO reports to the CFO. The financial organization has traditionally been where risks to the business are assessed.

 

The establishment of this responsibility chain does several things for IT. It establishes a path to identify what risks should be mitigated. It establishes an approval process where mitigations to risk can be chosen in a way that fits the existing environment and satisfies the regulatory commitment. It defers responsibility for compliance out of IT and spreads the responsibility across the organization. It establishes a regulatory compliance process that fits into existing operational frameworks like ITIL and MOF. And lastly, it takes the IT Manager out of the hot seat for compliance.

 

Mark Eden