Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 


 
     
Recent Posts
   
Popular Topics
Home   
Search
    Members    Calendar    Who's On

Home » SQL Server 7,2000 » Sarbanes-Oxley » sox guidelines for writing software specs
Add to briefcase

sox guidelines for writing software specs Expand / Collapse
Rate Topic
Display Mode
Topic Options
Author
Message
mm-1009269
Posted Tuesday, October 06, 2009 11:07 AM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, October 06, 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
bitbucket-25253
Posted Tuesday, October 06, 2009 2:10 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 1:09 PM
Points: 5,123, Visits: 20,369
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
mm-1009269
Posted Tuesday, October 06, 2009 2:22 PM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, October 06, 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
Elliott Whitlow
Posted Tuesday, October 06, 2009 3:23 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 3:46 PM
Points: 5,870, Visits: 4,893
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
mm-1009269
Posted Tuesday, October 06, 2009 3:36 PM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, October 06, 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
Elliott Whitlow
Posted Tuesday, October 06, 2009 3:42 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 3:46 PM
Points: 5,870, Visits: 4,893
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
mm-1009269
Posted Tuesday, October 06, 2009 3:49 PM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, October 06, 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

 
 
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.