What Does the Sarbanes-Oxley Act Mean to Developers?

(System Architect ) Posted 6/19/2004
Comments (12) | Trackbacks (0)

Enron and Worldcom will live in infamy for various reasons, but as software developers we shall forever be burdened with new requirements and potentially career stunting procedures imposed by that Sarbanes-Oxley Act. For software developers the corporate accounting scandals of the post-9/11 recession will have negative ramifications on our careers that exceed the possibility of our jobs being outsourced.

At face value, Sarbanes-Oxley (SarbOx for short) seems like a good idea. Make the CEO responsible for the behavior of his Finance and IT departments. The SarbOx Act defines hundreds and hundreds of controls and activities that must be performed on any system or process that can affect the financial reporting of any public corporation.

Some of the positive effects of SarbOx are the increased documentation for projects, imposition of processes for changes to systems, and culpability of the head man.

For software developers, the big problem comes in Separation of Duties. Basically, SarbOx says that a software developer should not have ANY kind of write access to production systems that can affect the financial reporting of the corporation. For many software developers, this is a career altering legal requirement; it precludes software developers from participating in the administration of systems they write code for.

Now, for big companies this isn't really a problem, they have plenty of administrators and plenty of developers. For small and mid-size companies it's a total disaster. Many IT groups in these smaller shops have 2 people that do everything from end user help desk to writing accounting reports to administering the accounting system's database and the distribution of the software they write. If this gap cannot be overcome by the company by hiring more people, then the developer must log every activity they perform on every production system (and end user desktops running software count as production systems), and a manager has to validate it's authenticity, or the corporate auditors must declare the company to not be in compliance with the SarbOx Act! Failure to comply can result in jail time for the CEO. You can read between the lines and infer the career implications for software developers on your own.

SarbOx doesn't affect only the public corporations. Small companies thinking about going public will have to make sure their ducks are in a row before that IPO, which could take years depending on the state of their Accounting and IT departments. If you took stock options as reimbursement with a small company, then SarbOx is going to hit you in the wallet!

To me, SarbOx is going to have a dramatic impact on software developers' career opportunities. In the past we've learned systems administration as a side job to our primary duties. To get a promotion to a management position in IT often requires experience in the administration of production systems. SarbOx will make that even more important as the manager will have to understand thoroughly what all of his minions do to be able to deal with the required audits. Developers are going to get shut out of this career path unless they quite coding all-together and start doing systems administration sooner rather than later.

Another side effect will be the merging of teams within companies. Instead of hiring more people to fill the gaps in the Separation of Duties requirements, corporations will bring teams together and reallocate responsibilities. For some people, this will have a positive effect on their careers, perhaps opening opportunities that never would have existed before. For the people left as software developers in these new teams, they will be painted into a corner of little opportunity for advancement beyond development and with more varied code bases to both maintain and extend.

One final possibility is that corporations will completely stop internal software development and retain contractors or software firms full time to perform software development duties. In a lot of ways, it helps the corporation achieve Separation of Duties requirements quickly and cheaply because they don't have to hire new people as company employees. If these corporations follow the GE 70/70/70 rule, then about 47% of those outsourced programming jobs are headed to India.

Conclusion

As if the recession hadn't hurt US software developers enough, our own government is inadvertently hitting us upside the head with a really big sledgehammer. The next time you read about Enron or Worldcom executives getting off on technicalities, be sure to thank them for the new world order of corporate software development.

I would really like to hear how SarbOx has affected you in your current job. I plan to write a small paper on the subject and more input makes better reading. Please send your story to blog@paytonbyrd.com

Did you like this entry? Please give it a Digg!

The opinions expressed in this blog are those of Payton Byrd and may not reflect the opinion of his employer or any customer of said employer. If you would like to contact Payton directly, please comment here or use the Send Message feature of ITtoolbox.

Digg

del.icio.us

Blog

more...

Related White Papers and Webcasts

Search, Sort and Filter Windows Event Logs Quick and Easy

Controlling Access to Critical Enterprise Resources

Controlling Privileged Access to Corporate Resources: Introduction to Symark PowerKeeper

Lead Warehouse Engineer, ELT - Gap Inc. Direct (Dice)

Reporting Architect - Gap Inc. Direct (Dice)

12 Comments

RSS for Comments

Glenn Miller writes:

4/6/2005 #

Help me out. I've word-searched through the Sarbanes-Oxley Act document and can't find any reference to "software", "developers", "separation of duties", etc.

What is the basis for your statement "Basically, SarbOx says that a software developer should not have ANY kind of write access to production systems that can affect the financial reporting of the corporation." ?

Thanks,
Glenn

Donavan McDonough writes:

4/11/2005 #

Glenn

I've read through what Payton has said and interpreted in terms of the SOX act. I tend to agree with him. The words you highlighted are not contained in the actual verbiage of the act.

Payton has tried to fathom the spirit of the act and move it into the concret realm. Thus the divison of system administrtion and system developer.

Payton

How are doing on getting you small paper together on the subject?

Donavan McDonough
Spreadsheet Risks Researcher

Scott Peterson writes:

8/23/2005 #

Your statement that "Small companies thinking about going public will have to make sure their ducks are in a row before that IPO, which could take years depending on the state of their Accounting and IT departments." makes it sound like having your ducks in a row before going public is a bad thing. In reality, no company should go public before having its financial systems in compliance with reporting requirements. Otherwise potential investors will have no way to know whether the numbers that they are looking at make any sense.

A start up or small company should be able to set up financial processes that meet regulatory requirements much more easily than existing medium to large public companies simply due to the fact that they have much less baggage as far as existing systems and policies are concerned.

Jonathan Chalker writes:

10/24/2005 #

Donavan said:

"Payton has tried to fathom the spirit of the act and move it into the concret realm."

This sounds like a cop-out to me.

There is a tremendous amount of control and power being handed over to various groups in the name of SOX compliance. Each time we as a group (IT professionals) challenge applicability of the act to overreaching and sweeping (often counterproductive and overly expensive) policy changes within the IT industry and internally to one's corporate employer, our challenges are met with obscure responses such as yours above. How can someone claim be acting in the 'spirit' of SOX without still connecting the dots in the language of the act itself, especially when challenged on specific policy-related points?

It seems to me, there may be a desire within a certain part of the IT Industry to stifle the debate ... or at least the debate over applicability of much of what is being 'sold' by the new SOX industry in the name of compliance. The debate seems to be about what tools one should buy, what new departments should be created, what type of systems professionals to hire, and how much effort should be contracted out in order to comply rather than what compliance actually means given the language of the SOX act itself.

I have read SOX and I disagree that the 'spirit' of SOX is intent on making it impossible (or difficult) for a developer to upload his own code to a production system. Those sorts of claims to compliance are completely redefining the IT role in industry as the author in the above article has pointed out. Perhaps some level of IT change is necessary in order to 'aid' in the ease of SOX compliance by financial groups and corporate officers. Beyond that basic principal though, it seems completely reasonable to challenge the SOX-based assumptions driving sweeping IT policy at the lowest levels of day to day business.

Jonathan

Judy writes:

7/9/2006 #

Payton,

Have you finished your paper on Sox? I would like to read it.

Anna writes:

2/27/2007 #

I was wondering if you have any opinion on what affect SOX will have on the choice of SDLC? specifically RAD

Anna

Payton Byrd writes:

3/1/2007 #

I would like to take a moment to thank everyone for reading this entry. I never got the time to really do a whitepaper any justice and for the last year I've been working for private companies and thus have become somewhat detached from the day-to-day ramifications of SOX. I think there are big changes coming up for SOX as the feds get feedback on it and probably there will be some language clarifying the role of IT personnel in seperation of duties. Acts of congress don't move quickly, so I'd say for now just continue on with the assumptions I've posted in this entry.

Tim writes:

3/13/2007 #

The word "separation" doesn't even appear in the Act. Neither does "software". "IT" only appears as "it" and not an acronym. "Development" only appears in the phrase "professional development". "Information system" only appears in one area forbidding a company that provides audits to simultaneously provide design or delivery of financial information systems. Every other occurrence of "system" is not connected with software in any way.

H.R. 3763

If none of those things are mentioned in the Act, then how can they truly be required? Does anyone read the actual law, or just the forums about it? How do the dots connect from the text of the law to all the things you mentioned? That seems to be a challenging interpretation to truly hold up against the text. I just don't get it, and I guess it may be because IANAL.

Payton Byrd writes:

3/13/2007 #

@Tim

As with all things constitutional, what's written on the paper doesn't mean anything until a judge rules on it. There's a lot of really smart people who have read the laws and interpret it to require the separation of duties I've outlined here. A law doesn't have to specifically call out a use case for that use case to be covered.

It really boils down to what your SOX auditor says before they sign off that you are in compliance. The public companies I've worked for have had auditors that were very strict on separation of duties. I've also worked for a major auditing firm, and they apply the same separation of duties even though they are private because they don't want a conflict of interest. It's not something to be sneezed at because it's inconvenient.

Jonathan Chalker writes:

6/4/2007 #

From Payton: There's a lot of really smart people who have read the laws and interpret it to require the separation of duties I've outlined here.

I think a lot of these really smart people may also be somewhat self-serving - financially and politically. At my company, though SOX is still quietly a consideration in the background, the "I am SOX, hear me roar" attitude has faded considerably. Either the fad is passing in favor of some other or they are realizing the additional layers of red tape involved in making relatively small changes to the company's technology have dramatically slowed productivity in some cases. Since not a single company has been sued or investigated because a senior developer was allowed to build and write directly to a database in a production environment, it is becoming obvious that such separations might be extraneous to the 'spirit' of SOX. These guys are not the intended target of SOX. These guys have however worn a bulls-eye when it comes to those selling SOX compliance tools, auditing services, etc. It has become even a little embarrassing I think for some of the executive leaders in corporate IT groups that they were so easily duped by scare-tactic marketing. In an effort to exert their senior authority where concerns SOX, they found themselves parroting "a lot of really smart people who have read the laws" instead of thinking and questioning themselves the relevance of the word of the law itself to their day-to-day efforts.

There might be some clarification in the legislation coming soon but as of today, there is still no reason in the law itself I can see for the mass hysteria that became "managing SOX compliance" for the everyday corporate IT department.

I'm still with Tim on this one. It wasn't the courts telling our IT leaders how to behave. It was fear, maybe some laziness, and probably a bit of good old fashioned ego or greed.

Peter Jamack writes:

12/19/2007 #

I think it really depends on the company you work for and the auditor(s) you are dealing with. I worked on a project in the past where SoX was in the background. It was on the radar, but it wasn't in flashing red lights. But I've also worked on a project where SoX was flashing in red, yellow, blue, orange and whatever other lights and the management spent like 8,000 man hours in less than a year getting the department Sox Compliant. And those two projects, about a year apart, were for the same company but in different departments and cities. So it really depends on who is flagged and who isn't.
For me it just means more documentation, maybe getting more approvals and so on. it might make a 4 week project turn into a 2+ month project. Not that big a deal, just a lot of dotting my i's and crossing my t's. But i've worked for projects in the past for government organizations so it's nothing new.

But while all that might not mean much to me, it means everything to management. If they fail a SoX audit, it could also mean projects get canceled or put on hold, managers get moved around, managers moan about thier staff, and lay offs or canceled contracts aren't out of the realm. If a company is marked as having to become SoX compliant, IT no longer really matters to them unless everything is the way the auditor wishes it to be.

Like I said, it might not mean much to me, but then again if suddenly my project gets canceled and I'm out of work because I or others in my deparment really didn't give a crap about SoX , it suddenly becomes an issue that matters. And don't kid yourself that projects that are once deemed most important become unimportant once they fail a SoX audit.

Will anybody care that I access the production server and my co-worker accesses it as well if we aren't supposed to? Probably not right away but it never works that way. If i have access, somebody else will want it and then somebody else and suddenly 2 people turn into 100 people into 1000 people and suddenly you have a serious security issue. And if an auditor catches this, and usually they will cause there is no real evidence to why 1000 people need access to the production server, you have a failed SoX audit.

I've visited various forums over the years and I don't get the big deal about not accessing production servers. It seems half the people on various forums work for 10 people companies or 2 team departments. Not having access to certain files and servers does make things a pain in the neck, but over the past 5 or so years, I've never had access to production servers for any of the 7 or so projects I've worked on. As a contractor, many companies already have security issues in place, so it's just another security feature with SoX that I'd have to go through. No big deal. You learn to work around what you have access to. I guess very few people have worked on projects where half the system was filled with top secret data that you weren't allowed to access even though you sort of needed that info for your application to work. Not fun, but it is what it is and it's not something new.

As far as laws go, it's not about what's in the law it's about how it's intepreted. Many of the laws we follow aren't exactly written the way we follow them. If you look at the constitution, half of our "rights" aren't exactly written the way we interpret them.

Yeah, they say things will change, but when has the government ever tried to make things easier unless there was some kind of kickback involved.

SoX is here to stay, whether we like it or not.

mike myers writes:

12/29/2007 #

As professionals we are obligated to challenge legal compliance interpretations that result in driving up costs as well as those that drive down an individual’s functionality. To rely only on the interpretations of unnamed ‘smart’ people who may be in a position to profit from outsourcing, build their empires or simply be smart but wrong would be intellectually lazy. If a single auditor can create his/her own interpretations without being held accountable to industry standards would be a catastrophe. Of course auditors will be held accountable for what they sign-off on, but the point of this dialogue is to discover what the actual legal requirements are and to help find competent auditors that don’t simply over-regulate in order to protect their own back-side. Generally speaking, it is a good thing to increase the integrity of financial reporting to management and investors. However, to drive up costs unnecessarily in order to do so would be totally counter-productive.

I hope that Payton can provide additional information on or links to the professional auditors interpretations which are the basis for his article. At some point in the interpretation there must be some linkage back to the text of the law itself.

I am sure that there are many debates going on within organizations as they attempt to document their controls. Once controls are put in place, there will be significant implications on individual careers as well as the functionality of business processes, resulting head-counts and operational performance visibility. From my perspective (I have typically been a super-user within operational finance), similar interpretations within my company have been used to deny report writing functionality (read-only access) to end users who also have access to enter or change data on the front-end of the ERP. This will result in a significant degradation in the type contribution my career has been built on and that I am currently being compensated for. Insofar as the impact on companies given the evolution of individual contribution that enable head-count reductions (lean-sizing), it is absolutely critical that we do not read-in more separation of duties then is absolutely required by law or is logical to ensure security. Not only does this impact head-count, but it also impacts timely visibility of operational performance, individual innovation, automation of business processes and the ‘information is power’ equation. Obviously I personally have a stake in this interpretation, but to depersonalize the issue, the bottom line is the Bottom Line.