Re: Back and a Question

if it doesn't state in SOX that developers can't have access to production data, how do the auditors determine what is a violation?

Not having access to PROD data is a real problem for ETL systems that recieve external data feeds. You can have alot of validation checks when you get the file, but you will never catch everything and sometimes you get bad data. You need to people to check it.

I guess the other option is to 'promote' a developer to systems administrator and put him on the production team so he can look at the data?

• Original message -------------- From: Nuno Souto <dbvision_at_iinet.net.au>

> From where I stand, it's exactly like Ryan described:
> we got SOx-audited last year and again this year and in both
> occasions access to production by developers came up as an
> absolute no-no and something we simply cannot allow.
> Which I tend to agree with, BTW. ;-)
>
>
> --
> Cheers
> Nuno Souto
> from sunny Sydney
>
>
>
> Quoting David Aldridge :
>
> > Tsh, is there any lie that those operations people won't tell in order
> > to keep us out of their sandbox?
> >
> > Seriously though, I don't think that SOX is that detailed, and I don't
> > believe any STIG is either. It sounds like that rule is more along the
> > lines of an _interpretation_ of the regulations, or a quoting of the
> > regulations to justify a rule (depending on your degree of cynicism).
> >
> > ryan_gaffuri_at_comcast.net wrote:
> > >
> > > I did DOD befoer this. I am doing financial now. The federal government
> > > actually passed security laws for financial companies as part of
> > > Sarbanes-Oxley(SOX). I was told by operations that one of the rules is
> > > that development cannot have access to production data. That is a
> > > problem for production support when you get data issues.
> --
> http://www.freelists.org/webpage/oracle-l
>
>

--
http://www.freelists.org/webpage/oracle-l