Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

sox guidelines for writing software specs Expand / Collapse
Author
Message
Posted Tuesday, October 6, 2009 11:07 AM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, October 6, 2009 4:10 PM
Points: 85, Visits: 182
Hello!

I'm a developer and I write my own requirements and I have read access to production servers.

Am I violating SOX guidelines by writing my own requirements and then doing the development? I'm really unsure how to interpret SOX since I'm an IT person but technically, I'm not in the IT department.

Can somebody please help me understand?

Thank you very much!
-Michelle
Post #798685
Posted Tuesday, October 6, 2009 2:10 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, September 18, 2014 7:50 PM
Points: 5,322, Visits: 25,235
So much depends on what access you have or could have to the companies accounting system.... or any other system that directly or indirectly would impact on the companies financial statements.

My only suggestion is talk or suggest to your supervisor that your activities be reviewed by either the companies accounting firm and or attorney.

In the interim period have your requirement documents formal approved by your supervisor.


If everything seems to be going well, you have obviously overlooked something.

Ron

Please help us, help you -before posting a question please read

Before posting a performance problem please read
Post #798781
Posted Tuesday, October 6, 2009 2:22 PM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, October 6, 2009 4:10 PM
Points: 85, Visits: 182
Thanks bitbucket,

I do have some knowledge because I used to work with QA but that's when I was in IT.

I don't have access to financial information

Thanks
-Michelle
Post #798791
Posted Tuesday, October 6, 2009 3:23 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, May 15, 2014 5:11 PM
Points: 6,032, Visits: 5,283
You are part of a publically traded company right? Or a wholly-owned subsidiary of one? Otherwise SOX is an optional.. Some companies have chosen to act like they are required to operate in SOX compliance as a way to have better control. I'm just wondering if yours is one of those..

You can often get seperation of duties by being the requestor of the change and the verifier, but not the implementor. What that means is that you don't actually do the deployment, you can help someone else but the have to be the ones doing it.

Also what is your change control process for putting things into production, if you are subject to SOX you should have a written policy that is audited. You chould have someone internally who is intimate with this process.

CEWII
Post #798830
Posted Tuesday, October 6, 2009 3:36 PM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, October 6, 2009 4:10 PM
Points: 85, Visits: 182
Elliott W (10/6/2009)
You are part of a publically traded company right?
You can often get seperation of duties by being the requestor of the change and the verifier, but not the implementor. What that means is that you don't actually do the deployment, you can help someone else but the have to be the ones doing it.

Also what is your change control process for putting things into production, if you are subject to SOX you should have a written policy that is audited. You chould have someone internally who is intimate with this process.
CEWII


Well, they haven't really subjected me to a change control process because I'm not in IT. But that's a good point, I should have my boss intiate a process.

Thanks for pointing that out...
-Michelle
Post #798837
Posted Tuesday, October 6, 2009 3:42 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, May 15, 2014 5:11 PM
Points: 6,032, Visits: 5,283
I think the having the rights discussion is often silly. I was a developer that had rights to very nearly every prod server, and rarely ever used them, and when I did it was usually because we had a down or near down condition and I couldn't find another warm body to help me.

But as long as you follow your documented change control process you should be good. Very likely the process will only handle the deployment to production and not anything about the processes (other than testing) that came before. So you designing and implementing should not be a problem..

CEWII
Post #798844
Posted Tuesday, October 6, 2009 3:49 PM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, October 6, 2009 4:10 PM
Points: 85, Visits: 182
Elliot,

I just finished a year long automation project and I had to put everything in temp tables and variables because I don't have write access to the database.

Well, anyway thanks for the advice Elliot, I appreciate it!
-Michelle
Post #798849
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse