Puzzle Pieces: The Relationship Between SOX, COSO, and COBIT
November 20, 2008
The Sarbanes-Oxley Act is one of the more unusual animals in the IT compliance menagerie. Unlike more clearly-defined laws such as HIPAA, or standards such as PCI and ISO27002, SOX’s applicability to IT is very vague – Sections 302 and 404 of SOX, collectively known as the “IT sections”, don’t talk about technology, and don’t even describe specific controls. Instead, SOX basically says, “ensure that your financial reporting process has integrity, or very bad things will happen to you.” While this is a nice sentiment to have, it also means that the hands-on process of building a SOX compliance program is open to wildly varied interpretation. Fortunately, the SEC (one of the lead driving organizations behind SOX) has issued guidance to help organizations better comply with the law. The SEC recommends the use of a controls framework to help achieve compliance with SOX, and they have specifically mentioned two well-known frameworks, one general in nature (COSO), and the other specific to IT processes (COBIT).
First up is COSO. Several years before widespread adoption of the Internet, and before IT security became a concern to most organizations (and by definition, the confidentiality, integrity, and availability of IT data, infrastructure, and processes), COSO established a framework for how organizations could control and manage their own internal processes (financial, operational, or otherwise). Originally authored by Coopers & Lybrand under the review of the Treadway Commission (itself a product of corporate malfeasance in the 1970’s), COSO establishes a way that organizations can organize and manage almost any business process (although it was specifically designed for financial accounting functions). COSO also established the concept of a “maturity model” for organizations to measure the depth (think “degree of evolution”) of how they implemented these processes. While COSO is a general framework (i.e., its governance model, risk model and controls are not specific to finance, IT, or any other business area), it can be (and often is) applied specifically to IT, especially those IT processes and controls that are governed by SOX. First and foremost, COSO is focused on processes, and then associates information and controls with those processes.
COBIT, an IT-specific framework first published in 1994, is loosely based on COSO; that is, it a framework for processes, specific to IT. In addition, COBIT provides hundreds of specific controls for each of these processes; in this way, COBIT describes high-level processes related to planning, implementing, and maintaining IT systems, while also giving them specific statements of how this should be done. COBIT is, in some ways, analogous to the ISO27002 standard: it provides a recommendation of how to implement stuff that needs to get done for IT to function. Unlike ISO27002, however, COBIT is not solely focused on information security – it addresses things like review and acquisition of technology and performance measurement, which are outside the traditional scope of security. Also, unlike COSO, COBIT is focused first and foremost on information, and then associates processes and controls with this information.
From an implementation perspective, then, how do SOX, COSO, and COBIT relate to each other? Much like the pieces of a puzzle, each connects with the other, while still providing something unique. First off, it’s important to remember that no public company must use either COSO or COBIT; as long as an organization can demonstrate to an auditor that their controls and processes are reasonable, they should pass an audit – however, Big-4 firms have seized on these two frameworks as their own benchmark to determine whether their clients’ controls are adequate. Second, although there are some points of connection between COSO and COBIT, they are not really competitive with each other. Because COSO is a general framework, and COBIT is specific to IT, they can be – and often are – used simultaneously together: COSO as the criteria to audit general accounting processes, and COBIT to audit against IT-specific processes. Regardless of whether an organization chooses to adopt COSO, COBIT, or a combination of the two in order to meet SOX compliance the fact that they are using a known, accepted framework for managing processes and controls puts that organization on the path to compliance.
November 20, 2008 at 4:10 PM
What percentage of organizations under SOX use COSO over COBIT for IT processes and what are the dominant reasons for doing so? Why would an organization use COSO instead of COBIT? Is this a cultural thing?
Don’t most organizations under SOX utilize internal auditors to do both “general accounting” and “IT-specific” processes? Why would an organization separate the two? Wouldn’t that add unnecessary overhead to the audit process? Isn’t this where the idea of COSO vs. COBIT (as competitive frameworks) comes from?
AFAIK, internal auditors use COSO in the United States, especially for SOX. COBIT is just for the academic and research literature. Correct me if I’m wrong.
November 20, 2008 at 5:53 PM
Typically, I don’t see COSO and COBIT as competing with each other, at least with respect to SOX; rather, they’re complimentary. Therefore, it’s probably not easy to quantify “COSO vs. COBIT” users, since there will be a lot of overlap. Most often, I see organizations use a combination of both: COSO for auditing the appropriateness of internal financial reporting processes, and COBIT for the components of IT that support these financial processes. As far as cultural aspects go, I do find that, outside the U.S., companies tend to prefer ISO27001/27002 for IT-level process auditing, but COSO is still the preferred framework for non-IT auditing.
SOX-scoped organizations generally do have internal auditors, but they are also required to utilize external auditors. In a perfect world, it would be great for organizations to have a single internal audit capability, that was educated well enough in both accounting processes and IT operations to support a seamless audit function between the two. Pragmatically, however, most organizations just aren’t there. In most cases, IT functions are still discrete from accounting functions, and as a result, most organizations split up their auditing into different efforts; IT SOX audits become a subset of the overall SOX compliance audit. While it’s true that this does add overhead compared to a single, end-to-end audit function, the reality is that very few organizations are politically structured in a manner that supports this. Practically speaking, the vast majority of SOX companies have separate groups (both internally and externally): one to address SOX audits for financial reporting, and one to address the IT operations that support that financial reporting process.
From an IT auditing perspective, COBIT is well established (at least in the U.S.) All major accounting firms base their own IT SOX auditing on the COBIT framework, and even if they have their own audit criteria, they map this criteria into COBIT. There are also a large number of projects out there to align the myriad of best practices and standards for IT (e.g., ITIL, PCI, ISO27002, etc.) to COBIT’s broad set of IT processes and controls; this points to the increasing popularity of COBIT as an IT-specific controls framework.
November 22, 2008 at 7:47 AM
“As far as cultural aspects go, I do find that, outside the U.S., companies tend to prefer ISO27001/27002 for IT-level process auditing, but COSO is still the preferred framework for non-IT auditing”
I prefer control/principle-rich frameworks such as ISO27k myself, but many organizations are at such an ground-level stage of maturity. For these organizations, Visible Ops / Visible Ops Security (or even ITIL, as you mentioned) might be better frameworks than COBIT or ISO27k. This may also explain why COSO simplifies the IT audit. The best tool is the best tool, and for many organizations it’s better to have something than to try and do everything.
“There are also a large number of projects out there to align the myriad of best practices and standards for IT (e.g., ITIL, PCI, ISO27002, etc.) to COBIT’s broad set of IT processes and controls”
You must be referring to ISACA’s “Guidance on Aligning COBIT, ITIL and ISO 17799″ document or possibly the V3WP document from the BITS Shared Assessments program, although I have seen others that are similar in approach. Both are very useful documents for mapping controls. I would question, “what are the right controls for any given organization”? Visible Ops / Visible Ops Security makes this more clear, which is why I prefer them as starting points, especially for SOX pre-audits / internal IT audits. Note that BITS Shared Assessments SIG is more and more often used to replace a SysTrust or SAS 70 Type II audit (the baby sister of a SOX audit) and it is very rich in IT and security controls.
I have always found the relationship between frameworks, regulations, standards, and best practices (such as specific assessment methodologies, risk analysis & risk management frameworks, etc) to be the most interesting part of compliance. Since most public companies are also technology companies, it would stand reason that SOX would inherit IT-specific frameworks strong in IT/security controls, as well as IT/security best practices. In other words, I think that COBIT or ISO27k are where these technology companies need to be (instead of just ITIL or COSO), but I think they also need to look at NSA IAM/IEM/RTM, DIACAP, OSSTMM, FAIR, CSA, OCTAVE, etc.
ISO/IEC 38500 includes ISO27k along with ISO9k and ISO20k as the global IT governance framework. It’s an interesting document that speaks stronger to an all-encompassing framework for IT that doesn’t leave out security, quality, or service delivery – but rather makes each an issue to be dealt with separately and equally. This is great because over the years I’ve heard too many complaints about how e.g. ITIL (probably referring to v2) doesn’t say anything about security, or how PCI-DSS is overly concerned about specific security requirements. ISO 38500 is the best alignment I’ve seen to date on all IT issues, and it’s clarity also speaks volumes.
The problem with COSO is that it was developed along with SAC over 14 years ago and has never really changed. COBIT was also developed around this time, but has been through many revisions. ITGI (the makers of COBIT, who also developed the CISA certification for ISACA) has always planned to update COBIT every 3 years. The problem with COBIT is that it’s not staying up-to-date. If COBIT was flawless, then PCI-DSS wouldn’t be in the place it is today, and ISO27k wouldn’t be considered so much more mature in comparison. The problem with SOX+COBIT is that not every public company is also a technology company (although at least a third of them are, which is why there is a lot of overlap between SOX and PCI).
With CICA (i.e. Canada) following CoCo (instead of COSO) and ITCG (instead of COBIT) for many years (and Australia and New Zealand having their own standards and associated regulations), it’s no wonder that the ISO/IEC standards are becoming more popular from a global perspective. I really think that the overlapping aspects of compliance are outrageously excessive and unnecessary. I can’t wait for ISO to replace PCI-DSS with a ISO27k-like standard, especially before PCI becomes law.
Sure, we have SOX, GLB, HIPAA, and PCI here in the US. One single company may have to do all 4 audits, and as you stated, there could be multiple internal and external auditors for even the same regulation. Then they might also have to do the ISO audits. Does anyone have a problem with this besides me? Do you see the overlap? Isn’t that a bit too much overhead?