Making the SOX Grade

Sarbanes-Oxley compliance has caused a lot of pain and suffering in IT organizations. The controls put in place to mitigate risks to financial reporting were adopted for unknown reasons, obtusely defined and onerous. A recurring theme over the past year has been one of “I don’t want an ‘A’ -- I just want to pass.” While the desire to avoid undo stress is understood, there is an approach that can yield not only an excellent grade, but avoid many stresses.

If we truly go to the heart of SOX, we are concerned with protecting the integrity of financial reporting. That means, in IT, we must focus on unacceptable risks to the services we provide to the business. Despite what a myriad of vendors may claim, if it doesn’t affect financial reporting then it is not part of SOX. What matters the most are the services that materially contribute to the financial reporting process and, if those systems are compromised, then the reports released to the public risk being in error.

When we talk about controls for SOX compliance then, we are really talking about putting in place controls that specifically reduce risks to financial reporting to an acceptable level to management. We aren’t talking about eliminating risks -- but about taking actions to reduce them to a tolerable level such that functional area objectives and the goals of the organization are attained. To be specific from a terminology perspective, the remaining risk is known as “residual risk,” and the amount of risk that management and the board are willing to accept is known as the “risk appetite” of the entity. Shaped by this, the “risk tolerance” is the level of acceptable variation around objectives.

This is very, very important. Every organization is unique. It has its own culture, resources, goals and so on. The levels of risk appetite and risk tolerance will vary. As a result, so too will the controls and processes that are put in place.

https://o1.qnsr.com/log/p.gif?;n=203;c=204657336;s=9478;x=7936;f=201808231619130;u=j;z=TIMESTAMP;a=20403940;e=i There are two sources of control guidance that I recommend -- Control Objectives for Information and related Technologies (COBIT) version four and IT Control Objectives for Sarbanes Oxley (ITCO). COBIT version four is an excellent piece of control guidance. In my opinion, it is the best control framework released to date globally. The ITCO guidance now has a second edition draft released for guidance. My recommendation for firms facing multiple regulations is to use COBIT to have a greater breadth of controls to review and draw from. On the other hand, for small or medium-sized companies only worried about SOX compliance, the ITCO document can help.

The controls that are most important for ensuring the integrity of financial reporting are known as “key controls,” and those are what will be tested by the internal and external auditors. For most organizations, each of the control documents previously mentioned will identify controls that are not key. There are controls that could help to some extent but are not key. What you need to focus on are the risks that matter most to the organization and then the identification of key controls that reduce those risks to an acceptable level. Again, do not go for perfection. Trying to implement every control to the fullest extent possible will only result in high costs, frustration and will not be sustainable.

Finally, to actually enact the controls, you need to “wrap” them with processes. For example, if COBIT control AI6.1 says that the firm should have change standards and procedures, then you must still figure out how to best implement that. This is where best practice references come into play. The IT Infrastructure Library (ITIL) has, in my opinion, the best guidance on the change management process in the Service Support volume. It doesn’t mean you exactly follow ITIL, but you refer to it and start as best you can given the resources and constraints that you are confronted with.

Another way to think of this is that COBIT and ITCO tell you “what” to do but you still need to figure out “how” to implement processes that use the controls in your particular situation. For everything, design your processes such that you can start, learn and evolve through continuous process improvement. Your risks will change over time, your controls will change over time, your processes will change over time … in short, everything will change and you need to be prepared to deal with this change such that your risks are properly managed at all times. Remember some sage advise from Dr. Deming -- there are only two outcomes with processes. You either follow them or you formally change them. There isn’t another option.

You see, there isn’t a straight grade overall. One company doesn’t get an “A” and another a “D” based on the number of controls they implement. What really matters is to understand your company’s unique risks, identify the controls you need to reduce those risks, and then implement processes that leverage the controls. First thing is to start in a realistic and simple manner. Second, observe what you have done, learn, and then evolve via process improvement over time. It’s the age-old plan-do-check-act cycle. If you can do that, the “A” doesn’t really matter because you’ve won.