SOX insanity takes hold in the IT department

I've gotten quite a bit of feedback on my post last week, "Sarbanes-Oxley: Stop the Insanity." Everyone has a story.

Here's one from a reader whose company shall remain unnamed, and I've disguised some significant details in the interest of confidentiality.

Frank, here is a stupidity that I am personally acquainted with at [major Fortune 500 Company.] Prior to the implementation of our current SOX project, we had some software mods implemented in our [well-known ERP system.]. Embedded way down in one of the frames, one of the programmers had misspelled the word "Inventory" as "Invetory".

One would think this a fairly simple fix for a programmer, but no. Now that we have implemented internal controls for Sarbanes-Oxley, we had to follow the SOX-compliant process.

1. First, we needed to answer a 50-item questionnaire and submit to the Program Management Office.



2. Two people then had to review the request and approve it.



3. The request was then assigned to a functional IT specialist to prepare a functional specification, which consisted of 18 sections.



4. The functional spec was then reviewed by a "key user," who approved it and submitted it back to the program office.



5. A programmer had to be "formally" assigned to go into the code and fix the problem. Of course, this was the quickest part of the process, as one would expect. The program code then had to promoted to a "Test Environment."



6. The functional IT specialist then had to prepare a user acceptance protocol (UAP) with test instructions, which she had to give to five users at our five facilities for testing. This step took five days and numerous phone calls.



7. The functional IT specialist then had to compile the completed UAP forms from the five users into a Test Report and copy them to a secure server and notify the programmer.



8. The programmer then had to go through a series of steps to promote the code from the test environment to the production environment. This is a step that the Company has been doing for years as part of basic configuration management.



9. Finally the misspelling error was corrected.

In the past, such a minor change request would have taken less than an hour for two people. Now, under Sarbanes-Oxley, it has turned into three-week process involving many, many people and has increased the cost to the organization probably 100-fold.

All to correct the misspelling of a single word.

To be fair, I'm not sure that the Sarbanes-Oxley Act is totally to blame here. It sounds to me like this company has designed internal controls with no consideration whatsoever of risk.

No organization has unlimited resources. Industries that are accustomed to doing business in a regulated environment, such as medical device manufacturers, are increasingly using risk management as a way of focusing limited resources on business processes and functions where there is genuine risk. Unfortunately, it appears that companies like the one described above have no understanding of risk management.

Companies implementing internal controls under SOX should apply the 80/20 rule: 80% of the risk is in 20% of the processes. If you try to control everything to the same level of concern, you over-control most processes and you under-control the 20% of the processes that genuinely represent a financial risk to the organization.

Every hour that the IT group spends planning and testing cosmetic changes to applications is an hour that it is not working on improving and automating internal controls for the 20% of business processes or functions that represent real risks. Shareholders of companies like this are not well served by such mindless compliance.

Related posts
Sarbanes-Oxley: stop the insanity
Making SOX compliance a meaningful exercise
Sarbanes-Oxley compliance: too often a wasted effort