Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase

Can someone help in preparing SOX security document for MS-SQL server production databases Expand / Collapse
Posted Thursday, July 5, 2007 12:57 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, January 12, 2016 12:15 PM
Points: 6, Visits: 193

iam anil, in process of preparing SOX security document for MS-SQL server which includes all the contents which are helpful for production database to be more consistent and can have track of all the changes done on it. I am looking for a document which can provide information that we are doing and to be done. Please send any checklist or some handy which can help the same.
anil kumar

Lina G
Database Administrator
Post #379347
Posted Friday, July 6, 2007 7:11 AM



Group: General Forum Members
Last Login: Yesterday @ 11:56 AM
Points: 7,508, Visits: 8,664


Unfortunately, this is something that is changeable depending on what types of information you keep track of in your database and what type of business you have.

Part of our SOX documentation is a very strict SDLC process in which every data change and program change has to go through Test and QC before we can implement it in Production.  We document the requirements of each change, getting end user approval of the requirements, and each stage of the testing requires approvals.  2 business people have to be in on the request.  1 as a sponser, the other as a requestor.  This whole process ensures there are no potential financial changes being done at random.

Another part of SOX is reporting who has what access to the databases (and what roles they are members of) and writing up a "handbook" on how security is requested, the different reasons for granting / denying those requests and how it is finally implemented.  We've only been doing this for a year, but so far we've kept all reports, going back to the beginning of the implementation.  This helps us track who has access to make data changes and who can just look at things.

Lastly, we're automating all our reports (financial and otherwise) and generating them in PDF so the numbers cannot be easily altered by end users which would cause a SOX violation.  The reports themselves have requirements written up on them which describes how we arrive at our totals and what numbers we're pulling up from what database/table/column.  This way, if an auditor questions what a report is doing, we can pull up the requirements and explain it to him.

The big thing with SOX is to document your processes, which is the reason no one can really send you a SOX document.  Since your processes are different from anyone else's, you're going to have to write up your own procedures.  Hopefully, this will give you an idea of what you need to address in your own SOX initiative.

BTW, SOX is due to expire soon unless Congress renews it.  You'll have to show that you made an attempt to abide by it while it was in effect (for later audits and lawsuits), but if it expires, then there will be a lot of people not even making the effort anymore.

Brandie Tarvin, MCITP Database Administrator

LiveJournal Blog:
On LinkedIn!, Google+, and Twitter.

Freelance Writer: Shadowrun
Latchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.
Post #379558
Posted Friday, July 6, 2007 8:32 AM

Keeper of the Duck

Keeper of the Duck

Group: Moderators
Last Login: Friday, September 16, 2016 11:44 AM
Points: 6,639, Visits: 1,905
This forum thread also provides some guidance:

SOX and SQL server 2000

However, SOX compliance isn't a "cookie cutter" type of thing. So you'll probably finding yourself tweaking things based on what your internal auditors suggest / cite as weak controls. The best approach is to work with your auditors to determine the types of controls they are looking for and then building a security structure around that. External auditors who are validating controls are of limited use in this respect because they have to maintain independence. This is why it's not unusual for two external audit organizations to be brought in: one to help determine remediation steps and another to actually do the attestation.

K. Brian Kelley, CISA, MCSE, Security+, MVP - SQL Server
Regular Columnist (Security),
Author of Introduction to SQL Server: Basic Skills for Any SQL Server User
| Professional Development blog | Technical Blog | LinkedIn | Twitter
Post #379606
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse