SOX and the auditors

[padshore@optonline.net]

Are you sure you have this right? If a change is required, who is the person/people responsible for checking out sources? What would the procedure be if a PRODUCTION program has a problem at 3:00 a.m.? My company is (trying) to be SOX compliant, and have just been through a couple of SOX audits. This was NEVER a problem, however, saying that we do have certain procedures to follow from the beginning (prior to checking anything out) through to implementation. Alan

[Guest.Visitor]

SOX and the auditors

Where I've been, SOX compliance was achieved by paperwork showing the programmer had the authority to check source out and work on the project. If my memory is correct, at least two signatures were required on a form but the programmer checked out the source. Programmer's could move from test to an intermediate testing level. Programmer's were never allowed to move anything up to production. This was done by someone authorized to do it. The same documents that gave the programmer permission to check out source was used to tell the supervisor the programmer completed the project and to move the project up to production. These procedures became meaningless after awhile, though, because the checker-in'r simply did it without thinking about it. As long as you have documentation showing the programmer has the authority to check-out the source, D & T shouldn't require someone else to do the check-out; just the check-in. If they do require a separate checker-out'r, this, too will become rote and meaningless. Tom.

[Steve.Kiferd]

SOX and the auditors

It has been my experience that you (or your CIO, director, etc) sometimes need to challenge the auditors. Often times they are pretty clue free about IBM midrange environments. Bottom line is they are doing everything they can to cover their behind. I was once required to prove the logic of several reports the business defined as control points using SQL to generate the same results. If they could have been easily written using SQL, they would have used SQL. Talk about a PITA. I have been at clients with D&T and checkout by programmers was not an issue. Check in to production should either require approval prior to the programmer moving the form or it should be segregated and someone outside the programming staff should promote the change/s. For production issues there is usually a "fire call" procedure that allows a programmer to get a profile with *Allobj and access to what is needed to correct production issues, however these profiles are audited and the programmer must document everything done while they are logged on using the profile. I have known clients were staff has been fired for not being able to CYA with what had been done to correct production issues.

[gradford@krispykreme.com]

SOX and the auditors

We are just finishing up our third. All though we don't use D&T, our auditors are much more concerned with production objects. Documenting and following procedure is all well and fine but a review of production objects is the hot button. I don't see how not allowing developers to check out source protects anything. Not allowing them to put their own changes into production however does. Do you use a change management tool to formalize your development process? Based on my experience, that level of tracking would certainly provide the auditors with comfort level that they could live with.

[bibarnes@yahoo.com]

SOX and the auditors

I am curious to know if anyone out here has to comply with SOX and also uses Deloitte & Touche as their auditing firm. My reason is that our branch of D&T has mandated that programmers not be allowed to check out source. I know of other companies tat have to comply with SOX that do allow programmers to check source out of production and the restriction is to checking it back in.

[bibarnes@yahoo.com]

SOX and the auditors

Thanks all for the feedback.