Reports from the Sarbanes-Oxley Front Lines

In "Sarbanes-Oxley: Accountants Setting IT Policy" ( http://www.windowsitpro.com/article/articleid/43825/43825.html ), I talked about how the U.S. Public Company Accounting Reform and Investor Protection Act of 2002, aka the Sarbanes-Oxley Act, might affect SQL Server DBAs and developers. Sarbanes-Oxley is a sweeping set of new laws passed in the wake of Enron, WorldCom, and other accounting scandals that have roiled financial markets in recent years. In principle, the law is primarily targeted at publicly traded companies and is designed to make corporate accounting procedures more transparent to investors. In my original article, I said, "That's a noble goal. However, I start to worry when the bean counters end up with an authoritative and final decision on who can have access to an administrator password." I received some interesting responses to that first commentary. Here's what one reader had to say:

"Our auditors appear to be on the extreme side. Effective September 20, DBAs aren't allowed to hold administration rights in production because we're also considered developers. If a DBA needs access to the production environment, they have to wait for the Help desk to generate a work order, then request the ID from the network administrators (hopefully they're not busy at 2 a.m. when a job fails). And then there's all the logging we have to do now. At this point, we have over 20 logs that must be checked and acknowledged daily; by month end, it's likely to exceed 50. The joke around here is that we are going to have to start a new department with the sole purpose of reviewing the logs each day. The 'separation of duties' isn't a bad thing if you're fortunate to have a large IT department. But with seven people supporting offices in six states, there aren't enough heads for all the new hats."

The Sarbanes-Oxley auditors for this reader's firm have decided that they simply won't let production DBAs have the sa password. I wish this was a crazy, silly, extreme example, but I suspect that Dilbertian episodes like this one will become more common as more companies begin comprehensive Sarbanes-Oxley compliance activities. Another reader shared this scenario:

"We were just wrung through the Sarbanes-Oxley wringer here. And in my opinion, the effort was a total waste of time. The auditors didn't know what they were supposed to do, and they missed a lot of things that would have benefited from a closer audit scrutiny. Important concerns were either given a cursory look or totally ignored, while auditors focused on 'important' financial bottom-line stuff like "How often do you change passwords?" and "Where do you store your backup drives?" Those are certainly valid IT audit concerns, but I kept asking them "How does this affect our corporate financial statements?" It seems to me that auditors with lots of axes to grind went way overboard in using Sarbanes-Oxley as a big stick to get their way on certain things."

I raised this red flag weeks ago in my original article. Ensuring data security is a great idea. However, it's unrealistic to think that the accounting auditors will know what the important data security and privacy concerns are. I suspect that this type of heavy-handed approach will lead to situations in which the trained IT staff won't bother to point out potential issues to auditors for fear that the auditors will demand even more stringent changes that make the IT staff's jobs harder. Maybe I'm making a mountain out of a few molehills, but I suspect that episodes such as these will become the norm rather than the exception for DBAs working at companies governed by Sarbanes-Oxley.