SHARE

Control Framework Misconceptions

A tremendous number of articles have been written about ISO 17799, ITIL and COBIT. Unfortunately, a number of these articles inaccurately identify these three bodies as control frameworks, and I am repeatedly encountering IT people who are confused about this. Let’s take a moment to reset perspectives, both about controls and which of these three […]

Written By

George Spafford

Nov 23, 2004

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

A tremendous number of articles have been written about ISO 17799, ITIL and COBIT. Unfortunately, a number of these articles inaccurately identify these three bodies as control frameworks, and I am repeatedly encountering IT people who are confused about this. Let’s take a moment to reset perspectives, both about controls and which of these three bodies of knowledge really is an overall IT control framework.

First, let’s make sure we understand what controls are. Think of controls as mechanisms that keep IT in check in terms of delivering value and managing risk. To put it another way, think of them as safeties that allow for better preservation of value through the management of risks. Or as Stephen Katz, former CISO of Citibank, puts it, IT controls are like the brakes on a car. Not only do they serve to stop the car and keep it under control, they enable the driver to actually go faster and still remain safe.

This is the perspective that IT and management must have these days. Controls aren’t a necessary evil mandated by regulation. They not only are a necessity, but also can generate positive results when done correctly. For example, people reject adopting a formal change management process because they fear it will slow down implementation of changes — yet they don’t stop and look at the delusion of speed. Yes, the changes are getting slammed in. However, how many of those changes fail during installation or go on to create incidents and problems?

We can demonstrate repeatedly that change management is a foundation control for security and availability, yet we still run into arguments from people who don’t understand the causal link between their actions, human error and that 80% of problems arise from their own actions if left unmanaged.

Next, let’s look at the concept of a control framework. Essentially, a framework is a collection of controls organized to highlight what needs to be done at various levels of the organization. It’s an outline, if you will, that tells what but not how, because that level of detail is something you must fill in.

Never forget that because organizations differ, their control needs also will differ. For example, all groups need change management, but how it’s implemented will depend on the enterprise. Delving into the work instruction level, access controls are needed, but how they are handled on a mainframe vs. a Windows network will vary. The point is that you will need to tune your policies, procedures and work instructions not only to meet the spirit of the controls but also to be feasible in the context of your organization.

Now, let’s turn our attention to the three bodies of knowledge — ISO 17799, ITIL and COBIT. Only COBIT is an overall control framework for IT. The others simply are not.

ISO 17799 (the International Organization for Standardization’s code of practice for information security management) is an excellent standard for IT security. ITIL (the IT Infrastructure Library), on the other hand, is an authoritative source of descriptive IT best practices, notably in operations and service management. Neither of these standards, however, is intended to create a sound overall foundation of control — only COBIT is.

Control Objectives for Information and related Technologies (COBIT) was borne out of the efforts of dedicated experienced practitioners who recognized the need to have a series of controls to manage IT. In fact, numerous standards and practices were reviewed to identify the controls that it covers, and it is still evolving.

COBIT actually predates Sarbanes-Oxley (SOX), which is why they had to release their very well-done “Control Objectives for Sarbanes-Oxley” document to help give guidance about what elements of the COBIT framework were needed and how to view the controls needed. If you haven’t read the COBIT SOX document, you should. I recommend it and the full-blown COBIT framework documentation to IT pros who need to learn about controls in-depth and, certainly, it has relevance far beyond Sarbanes-Oxley to include any group who wishes to understand and improve controls inside of IT.

For those looking at COBIT for the first time, remember that there are no detailed tasks and instructions about what to do. As mentioned earlier, this is precisely where ITIL and ISO 17799 come into play. They can fill in the blanks about how to structure processes. For example, ITIL’s Service Support book has a definitive example of Change Management. The trick for practitioners is to select what to do on the basis of your organization’s needs/risks, resources, timeframe, etc.

In summary, people must realize that only COBIT is a true framework. ITIL and ISO 17799 are excellent sources of practice information, but they are not control frameworks. Implementing these controls shouldn’t be viewed as a necessary evil. Use COBIT as your control framework reference and then leverage ITIL and ISO 17799 for process improvement. It is very realistic to expect both compliance and process improvement through your efforts.