How COBIT helps you achieve SOX Compliance

First released way back in 1996, COBIT has already been around for quite a while. One reason why it never took off was because companies were never compelled to use it ? until now. Today, many CEOs and CIOs are finding it to be a vital tool for achieving SOX compliance in IT.

Thanks to SOX, COBIT (Control Objectives for Information and related Technology) is now one of the most widely accepted source of guidance among companies who have IT integrated with their accounting/financial systems. It has also gained general acceptability with third parties and regulators. But how did this happen?

Role of control frameworks in SOX compliance

You see, the Sarbanes-Oxley Act, despite having clearly manifested the urgency of establishing effective internal controls, does not provide a road map for you to follow nor does it specify a yardstick to help you determine whether an acceptable mileage in the right direction has already been achieved.

In other words, if you were a CIO and you wanted to find guidance on what steps you had to take to achieve compliance, you wouldn’t be able to find the answers in the legislation itself.

That can be a big problem. Two of your main SOX compliance obligations as a CEO or CIO is to assume responsibility in establishing internal controls over financial reporting and to certify their effectiveness. After that, the external auditors are supposed to attest to your assertions. Obviously, there has to be a well-defined basis before you can make such assertions and auditors can attest to anything.

In the language of auditors, this ?well-defined basis? is known as a control framework. Simply put, once you certify the presence of adequate internal controls in your organisation, the external auditor will ask, ?What control framework did you use??

Knowing what control framework you employed will help external auditors determine how to proceed with their evaluations and tests. For your part, a control framework can serve as a guide to help you work towards specific objectives for achieving compliance. Both of you can use it as a common reference point before drawing any conclusions regarding your controls.

But there are many control frameworks out there. What should you use?

How SOX, COSO, and COBIT fit together

Fortunately, despite SOX?s silence regarding control frameworks, you aren’t left entirely to your own devices. You could actually take a hint from the SEC and PCAOB, two of the lead organisations responsible for implementing SOX. SEC and PCAOB point to the adoption of any widely accepted control framework.

In this regard, they both highly endorse COSO, a well-established internal control framework formulated by the Committee of Sponsoring Organisations of the Treadway Commission (COSO). Now, I must tell you, if you’re looking specifically for instructions pertaining to IT controls, you won’t find those in COSO either.

Although COSO is the most established control framework for enterprise governance and risk management you’ll ever find (and in fact, it’s what we recommend for your general accounting processes), it lacks many IT-related details. What is therefore needed for your IT processes is a framework that, in addition to being highly aligned with COSO, also provides more detailed considerations for IT.

This is where COBIT fits the bill.

How COBIT can contribute to your regulatory compliance endeavors

COBIT builds upon and adheres with COSO while providing a finer grain of detail focused on IT. You can even find a mapping between COBIT IT processes and COSO components within the COBIT document itself.

Designed with regulatory compliance in mind, COBIT lays down a clear path for developing policies and good practice for IT control, thus enabling you to bridge the gap between control requirements, technical issues, and business risks.

Some of the components you’ll find in COBIT include:

IT control objectives

These are statements defining specific desired results that, as a whole, characterise a well-managed IT process. They come in two forms for each COBIT-defined IT process: a high-level control objective and a number of detailed control objectives. These objectives will enable you to have a sense of direction by telling you exactly what you need to aim for.

Maturity models

These are used as benchmarks that give you a relative measurement stating where your level of management or control over an IT process or high-level control objective stands. It serves as a basis for setting as-is and to-be positions and enables support for gap analysis, which determines what needs to be done to achieve a chosen level. Basically, if a control objective points you to a direction, then its corresponding maturity model tells you how far in that direction you’ve gone.

RACI charts

These charts tell you who (e.g. CEO, CFO, Head of Operations, Head of IT Administration) should be Responsible, Accountable, Consulted, and Informed for each activity.

Goals and Metrics

These are sets of goals along with the corresponding metrics that allow you to measure against those goals. Goals and metrics are defined in three levels: IT goals and metrics, which define what business expects from IT; process goals and metrics, which define what the IT process should deliver to support It’s objectives; and activity goals and metrics, which measure how well the process is performing.

In addition to those, you’ll also find mappings of each process to the information criteria involved, IT resources that need to be leveraged, and the governance focus areas that are affected.

Everything is presented in a logical and manageable structure, so that you can easily draw connections between IT processes and business goals, which will in turn help you decide what appropriate governance and control is needed. Ultimately, COBIT can equip you with the right tools to maintain a cost-benefit balance as you work towards achieving SOX compliance.

Check our similar posts

Denizon’s Business Continuity Services

Disruptions to business operations can be as catastrophic as a Hurricane Katrina or a 9/11 or as relatively trivial as a minor power outage or a planned shutdown. What ever the gravity, scope and duration the disruption has, your company should be able to handle each situation so that you can declare “business as usual” and really mean it. (more…)

How Bouygues manages an Empire-Sized Footprint

Bouygues is into telecoms / media, and building and road construction. It also knows it has to watch its energy footprint closely. Owning 47% of energy giant Alstom keeps it constantly in the media spotlight. Shall we find out more about its facility management policies?

The journal Premises and Facilities Management interviewed MD Martin Bouygues on his personal opinions concerning managing energy consumption in facilities. He began by commenting that this was hardly a subject for the C-Suite in years gone by. Low-level clerks simply paid the bills following which the actual amounts were lost in the general expenses account. That of course has changed.

Early pressure came from soaring energy bills, which were pursued by a whole host of electricity-saving gadgets. However, it was only after the carbon crisis caught business by surprise that the link was forged to aerial pollution, and the social responsibilities of big business to help with the solution. The duty to have an energy strategy became an obligation eagerly policed by organisations such as Greenpeace.

Unsurprisingly, Martin Bouygues? advice begins with keeping energy consumption and its carbon footprint as high up on the agenda as health and safety. ?It needs bravery and a lot of hard work to get it there,? he says, ?so perseverance is the key?. 

The company has developed proprietary software that enables it to pull data from remote sensors in more than 80 countries every fifteen minutes. A single large building can contribute 50 million data items annually making data big business in the system. Every building has an allocated energy performance contract against which results are reported monthly, as a basis for reviewing progress.

The system is intelligent and able to incorporate low-occupancy periods such as weekends and public holidays. What is measured gets managed. We all know that, but how many of us apply the principle to our energy bills. With assistance from ecoVaro, the possible becomes real.

We offer a similar service to the Bouygues model with one notable exception. You don’t buy the software and you only pay when you use it. Our systems are simply designed for busy financial managers.

Becoming Nimble the Agile Project Management Way

In dictionary terms, ?agile? means ?able to move quickly and easily?. In project management terms, the definition is ?project management characterized by division of tasks into short work phases called ?sprints?, with frequent reassessments and adaptation of plans?. This technique is popular in software development but is also useful when rolling out other projects.

Managing the Seven Agile Development Phases

  • Stage 1: Vision. Define the software product in terms of how it will support the company vision and strategy, and what value it will provide the user. Customer satisfaction is of paramount value including accommodating user requirement changes.
  • Stage 2: Product Roadmap. Appoint a product owner responsible for liaising with the customer, business stakeholders and the development team. Task the owner with writing a high-level product description, creating a loose time frame and estimating effort for each phase.
  • Stage 3: Release Plan. Agile always looks ahead towards the benefits that will flow. Once agreed, the Product Road-map becomes the target deadline for delivery. With Vision, Road Map and Release Plan in place the next stage is to divide the project into manageable chunks, which may be parallel or serial.
  • Stage 4: Sprint Plans. Manage each of these phases as individual ?sprints?, with emphasis on speed and meeting targets. Before the development team starts working, make sure it agrees a common goal, identifies requirements and lists the tasks it will perform.
  • Stage 5: Daily Meetings. Meet with the development team each morning for a 15-minute review. Discuss what happened yesterday, identify and celebrate progress, and find a way to resolve or work around roadblocks. The goal is to get to alpha phase quickly. Nice-to-haves can be part of subsequent upgrades.
  • Stage 6: Sprint Review. When the phase of the project is complete, facilitate a sprint review with the team to confirm this. Invite the customer, business stakeholders and development team to a presentation where you demonstrate the project/ project phase that is implemented.
  • Stage 7: Sprint Retrospective. Call the team together again (the next day if possible) for a project review to discuss lessons learned. Focus on achievements and how to do even better next time. Document and implement process changes.

The Seven Agile Development Phases ? Conclusions and Thoughts

The Agile method is an excellent way of motivating project teams, achieving goals and building result-based communities. It is however, not a static system. The product owner must conduct regular, separate reviews with the customer too.

Ready to work with Denizon?