Skip to content

What is COBIT all about?

July 30, 2008

COBIT stands for Control Objectives for Information and Related Technology. While the COBIT guidelines have been around since 1996, the guidelines and best practices have almost become the de facto standard for auditors and SOX compliance, mostly because the COBIT standards are platform independent. There are approximately 300 generic COBIT objectives, grouped under six COBIT Components. When reviewing and applying the COBIT guidelines and best practices, keep in mind that they will need to be tailored to your particular environment.

The Six COBIT Components

COBIT consists of six components:

  • Executive Summary Explains the key concepts and principles.

  • Framework Foundation for approach and COBIT elements. Organizes the process model into four domains:

    • Plan and organize

    • Acquire and implement

    • Deliver and support

    • Monitor and evaluate

  • Control Objective Foundation for approach and COBIT elements. Organizes the process model into the four domains (discussed in a moment).

  • Control Practices Identifies best practices and describes requirements for specific controls.

  • Management Guidelines Links business and IT objectives and provides tools to improve IT performance.

  • Audit Guidelines Provides guidance on how to evaluate controls, assess compliance, and document risk with these characteristics:

    • Define “internal controls” over financial reporting

    • Internally test and assess these controls

    • Support external audits of controls

    • Document compliance efforts

    • Report any significant deficiencies or material weaknesses

In conclusion, although an IT organization is free to select any predefined standards, or even one they develop to assist them in obtaining Sarbanes-Oxley compliance, the mostly widely accepted standard is COBIT. Subsequently, you may find that selecting COBIT will be the path of least resistance to Sarbanes-Oxley compliance.


COBIT guidelines and best practices will need to be tailored to your environment. Although the enormity of the COBIT guidelines and best practices may appear daunting, it can and should be distilled down to what is pertinent to your environment.

Entity Level Controls versus Control Objectives

Entity level controls consist of the policies, procedures, practices, and organizational structures intended to assure the use of IT will enable the accomplishments of business objectives, and that planned events will be prevented, or detected and corrected.

Control objective is a statement of the desired result or purpose to be achieved by implementing control procedures for a particular IT activity. When developing and documenting your controls, you will want to keep in mind several characteristics so your controls will be as effective as possible:

Key control characteristics include:

  • Employees are aware of their responsibilities for the control activities.

  • The control is clearly understood.

  • The control is effective in preventing, detecting, or correcting risk.

  • The operating effectiveness of the control activity is adequately evaluated on a regular basis.

  • The standards and assertions required to execute the control are clearly understood.

  • Deficiencies are identified and remedied in a timely manner.

  • The performance of the control can be documented.

  • The controls, policies, and procedures are documented.


    Although the goal is to implement a control that will be 100-percent effective, it is not realistic. Therefore, the objective should be to implement the most effective control within your environment. Be prepared to explain to your auditors how your environment works and why a particular control is effective in your environment.

What Are the Four COBIT Domains?

We’ll now briefly describe each COBIT domain.

Planning and Organization

Planning is about developing strategic IT plans that support the business objectives. These plans should be forward looking and in alignment with the company’s planning intervals; that is, a two-, three-, or five-year projection.

Acquisition and Implementation

Once the plans are developed and approved, you may need to acquire new applications, or even acquire or develop a new staff skill set to execute the plans. Upon completion of the Acquisition phase, the plans now need to be enacted in the Implementation phase, which should include maintenance, testing, certifying, and identification of any changes needed to ensure continued availability of both existing and new systems.

Delivery and Support

This phase ensures that systems perform as expected upon implementation, and continue to perform in accordance with expectations over time, usually managed via service level agreements (SLAs). In this regard, systems can be related to infrastructure components or third-party services.


The monitoring phase uses the SLAs or baseline established in subsequent phases to allow an IT organization to gauge how they are performing against expectation, and provides them with an opportunity to be proactive.

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: