As a dba, what do I need to know about SOX?

[Gooser]

All--

I am a dba at a not-for-profit, but I feel like I am falling behind in my compliance knowledge as a result. What do I need to know about SOX? Any suggestions on good resources? Any comments greatly appreciated.



v/r

Gooser

Why do today
that which may not need to be done tomorrow --me

The Universal Model

 

[mrdenny]

SOX is a royal pain. The basic gist of it that only people who need access to data get access to data, and people that have access to Dev shouldn't have access to Production.

It's all about separation of duties.

The problem with SOX is that it's not that specific on what needs to be done. It gives a set of guidelines which the auditor is free to interpret as s/he sees fit.

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

My Blog

 

[Gooser]

Thanks Denny.

I thought I would get more discussion on this, as SOX is mentioned all over the place.

v/r
Gooser

 

[mrdenny]

Most people want nothing to do with SOX, and cringe at the thought of it.

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

My Blog

 

[djj55]

We are currently setting up for SAS70 which is similar. I like the separation of duties as when there are only a couple of people in IT how do you separate?

Have worked with SOX in the past and do to managements not understanding, it was a moving target.

Good Luck,
djj

 

[RobertT687]

My $0.02.
My understanding is that provisions of SOX only apply to publicly traded companies. If the OP's Not-For-Profit is not a public company he/she shouldn't need to worry about SOX.

My experience with the process is that the important point is being able to show that your company has a formal process for implementing programming changes; that when changes must be made outside the relevant applications there is documentation about when and why it was done and a sign-off from the appropriate managers.

Program source-code control is another important aspect.

Separation of duties is another aspect that SOX wants to enforce, but offers no guidelines when the IT staff is very small.

The SOX auditors I had meetings with had a hard time understanding that as a DBA with sa privilege I had the capability to do anything and everything to the databases I managed. Their insistence that the sa account not be used missed the point that SOME account or accounts with those privileges HAD to exist in order to do DBA tasks.

Our IT group frequently spent more time on the paperwork to document a task that we actually spent on the task itself. If that's not a source of frustration, I don't know what is.

Thanks for letting me vent a little.

 

[mrdenny]

The key to surviving a SOX audit is documentation. SOX says that everything must have a written policy to describe what is going on, and that the policy is being followed. If your written policy is that everyone has access to the data, then you are following your policy. The fact that your policy sucks isn't the purview of the SOX auditor.

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

My Blog