An introduction to COBIT

by John Borwick In COBIT, IT components, IT governance, IT management, IT processes

Many IT and IT-related frameworks and standards exist, such as ITIL, the PMBOK, TOGAF (for enterprise architecture), and ISO 27001 (for IT security). In my mind COBIT is the most comprehensive, and one of the least understood. COBIT can feel overwhelming, but it’s a great framework to help you integrate other frameworks and approaches… and it’s a superior framework if you have to respond to IT audit.

COBIT, which originally stood for “Control Objectives for Information and related Technology,” is written and maintained by ISACA. ISACA is most famous for the CISA (Certified Information Systems Auditor) certification. The word “control” plus the CISA certificate should give you a sense that COBIT can be used for IT audit. To that end, you can expect that COBIT will have a mechanism to assess IT capabilities.

However, the most recent version of COBIT (COBIT 5) also pulled together ISACA’s other projects: “RiskIT,” “ValIT,” and large parts of the IT governance institute content. Thus COBIT has expanded to support IT governance, which is a very natural add-on from IT audit.

Here’s the major components of COBIT, at least from my point of view:

  • COBIT’s 37 “enabling processes:” COBIT calls out 37 IT processes that could exist, and information about each process including possible metrics, RACI charts, subprocesses, process inputs/outputs, and lots of other good information. These enabling processes have some detail, but COBIT also references other frameworks that provide more help for each process.
  • Process evaluation criteria to help you see your process maturity for a given enabling process. (In my personal opinion COBIT 5’s evaluation criteria are more difficult to use)
  • A “business goals” to “IT goals” to “enabling processes” map. If your cabinet is most interested in “Managed business risk” then COBIT can help you walk that through to the IT processes that you most need to investigate.
  • Mappings to other frameworks, for example the COBIT 5 to COSO (a common IT financial audit framework) mapping, the COBIT 4 to ITIL v3 mapping document, and a COBIT/NIST mapping document.
  • There are many, many other components to COBIT. To that end there is a whole COBIT 5 training/certification process including COBIT foundation, implementer, and assessor training.

Since the enabling processes are so key, I’m going to talk about them a bit more.

Enabling processes

COBIT’s 37 enabling processes are grouped into five areas: Evaluate, Direct, and Monitor; Align, Plan, and Organize; Build, Acquire, and Implement; Deliver, Service, and Support; and Monitor, Evaluate, and Assess. (Oxford comma added by me.) You do not need to implement all 37 processes–that is a sure road to madness.

These 37 processes have assigned identifiers; for example “Ensure Risk Optimisation” is called “EDM03.” There are write-ups for each process that lay out the process name; the process description; the process’s purpose; supported IT goals; supported process goals; a RACI chart; subprocesses with their own inputs, outputs, and activities; and related guidance and frameworks e.g. ISO 38500 for IT governance.

The processes have many cross-dependencies. For example, “Ensure Risk Optimisation” is going to need information from project management (BAI01) about how project risk management is going.

All that said, if you are willing to think about it and you’re OK with a fair level of ambiguity, COBIT an excellent framework to tie together other processes. For example ITIL’s Service Operation content is seen in COBIT’s “Manage Operations,” “Manage Service Requests and Incidents,” and “Manage Problems” processes.

COBIT’s role supporting IT governance

I said earlier that support for IT governance is a natural extension of support for IT audit. COBIT 5 framed itself around five “Evaluate, Direct, and Monitor” processes.

Here’s the idea: Boards of Trustees and cabinets need assurance that IT is doing its job and managing institutional risks. That’s a traditional role of IT audit. However, Boards probably also want some say over what IT is doing, and some way to have conversations about balancing IT’s value vs. its cost and risk.

In order for Boards to have these conversations, IT processes need to exist. Boards need to know about potential upcoming IT projects. They need to understand IT costs in a way that is manageable. They need to fund IT appropriately for their IT strategy; IT salaries are affected by whether IT is seen as a cost center, for example. To that end, COBIT presents the five “Evaluate, Direct, and Monitor” processes and then shows the input that these processes need from other areas.

This is a core challenge for IT governance and why it’s so difficult to see good IT governance: IT governance needs other processes to function, and the specific processes needed will vary based on the institution’s business goals.

That’s a large part of why COBIT 5 is structured the way that it is. You can use the business goals to IT goals to IT processes mapping to identify the most important processes, and then you can use the EDM processes to build appropriate IT governance structures that allow Boards to direct IT as well as provide input to IT audit for the processes that most need to be in control.

Related Posts: