Recently, I wrote that Sarbanes-Oxley compliance efforts are too often a wasted effort. Now I’ve got some confirmation from a reader on the front lines.
“Richard” (not his real name) works for a large well-known company that is proudly claiming its compliance with SOX Section 404 (internal controls). But according to Richard, the benefits do not justify the cost:
Frank, yes, Sarbanes-Oxley is a LOT of work—too much! And no, it doesn’t give any additional protection, if you ask me. The internal controls that we’ve implemented in IT really don’t mean much. Let me illustrate with one example:
“Our company has implemented an internal control that says a developer cannot directly modify production data. So now we stand next to the user administrator’s desk while he runs the SQL we gave him. He has no idea what he is running, but since it is done under his login it is “SOX compliant!
This is a big productivity drain. Two people are now needed to do something that one person could have done before, it is sometimes difficult to coordinate schedules, and frequently the production data mods are time critical. So now everyone is running around like chickens with their heads cut off trying get some simple UPDATE statement executed.
Well, Congress is full of lawyers and accountants and constantly is lobbied by them as well. So we know who is making money from SOX compliance—the lawyers and the accountants!â€
The situation that Richard describes is typical of compliance efforts that focus on the appearance of compliance but not the intent of the regulation. In this case, one must ask, what risk to the business is this internal control intended to mitigate? Apparently, Richard’s firm thinks that IT personnel may inadvertently (or deliberately!) corrupt the firm’s electronic records. The company has therefore implemented a policy that forbids programmers from running special programs to directly alter live files. However, the procedure allows a user with proper access rights to run the exact same program. But since the user doesn’t understand the program, he or she has no way to verify that the program will not corrupt the database. Therefore, this internal control might look good on the surface to an auditor that is not familiar with IT security. But it doesn’t mitigate any risk to the firm. Rather, it just creates inconvenience.
What would be more effective is in this case would be a meaningful combination of protective measures. First, there should be access controls to prevent programmers from updating live files, plus a procedure that requires programmers to submit all update programs to a database administrator. The procedure should call for the programmer to submit documentation as to the need for the update along with test results. There should also be a database audit trail produced to record the results of the live update, and a contingency plan in the event that errors are found after the update (e.g. a backup/restore procedure, or other way to back out the changes).
These measures would greatly mitigate the risk of data corruption with three types of controls: preventive controls (limiting the update rights of the programmer, separating the duties of the programmer vs. the DBA, and requiring testing of update programs), a detective control (the audit trail), and a corrective control (the contingency plan). Putting a user in the middle of the process adds nothing.
The trend toward meaningless compliance is not limited to Sarbanes-Oxley. I have written previously about the same problem with FDA regulatory compliance in software validation, where companies spend long hours and generate reams of test results to demonstrate that they have “validated” computer systems that support regulated functions, such as drug manufacturing. Yet the systems are not more trustworthy and reliable when they are finished with their “validation.”
Government is increasing and will continue to increase regulation of business functions in general, and computer systems specifically. Sarbanes-Oxley, HIPAA, and FDA regulations, to name just three, have enormous impact on IT departments. It is tempting to treat compliance as a formality—what is the minimum I need to do to pass an audit? But if we don’t focus on the risk to the business and the intent of the regulation, we will just continue to add to the cost of doing business without any meaningful protection.
December 2004