RE: Restrict ability to alter variables in debugger on production

["Raby, Steve \(GE Advanced Materials, consultant\)" <steve.raby@xxxxxx>]

I don't think that is the case; whoever is interpreting SOX for you is
making a grave error.  SOX does not care HOW data is changed, all it
cares about is a defined process, including approvals where necesary,
and an audit trail so that any changes are transparent.

For example, if Order Entry blows up, and some values on the order
need to be adjusted to process the order, this can be done.  However,
there has to be an approval process (perhaps signature of the IS and
Acct Managers), the before and after values need to be kept, and the
change information has to be filed somewhere.

I don't think that is the case either, you do not "adjust" values on an order 
you make adjusting entries. Actually all this talk about changing data by 
programmers is garbage isn't it? The programmer fixes the problem that caused 
the program crash. If data caused the problem, (e.g. decimal data error) then 
the program is at fault for not picking it up and handling it. As is the 
program that allowed the data to be put there in the first place. 

I agree, although I don't take it as personally as you appear to be
taking it!  

Yeah maybe I am but this is because of years of, you can't do this, you can't 
do that, you can't do the other. Now why isn't this fixed????


To all of you out there working in shops that are cracking down . . 
DO NOT GAME THE SYSTEM.  DO NOT CHEAT.  To do so would be to prove
that such system are necessary, and indeed to prove that you cannot be
trusted.  If you can't do the job because of restrictions imposed by
over-zealous SOX auditors, point it out, but work within the system. 
If you are directed to cheat, get it in writing.

I totally agree, above all, GET IT IN WRITING and signed by whoever directed 
you to do it.

Steve
Possibly a little over cynical