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 doesnt 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 arent 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.
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 doesnt 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 isnt another option.
You see, there isnt a straight grade overall. One company doesnt get an A and another a D based on the number of controls they implement. What really matters is to understand your companys 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. Its the age-old plan-do-check-act cycle. If you can do that, the A doesnt really matter because youve won.