Does SOX restrict access to QA environments or just production?

Question

Our dev team has 4 environments: Dev, Test, QA and Production and changes progress in that order across the environments.

Our DBA has given "SOX" as the reason for denying team leads, developers and testers update READ ONLY access to database objects on the Test, QA, and Production environments. As a result, we cannot verify that deployments were correctly performed.

I can see limiting access to production data. The data may be sensitive. However.we have full read access to the data. But I want to be able to see the code in production to verify that it is the code that SHOULD be in production and that something was not incorrectly deployed or left out of the deployment. Even if our deployment process were automated, there would still be a need to verify that the automated process worked as expected.

Dos SOX legal requirements really limit access to non production environments? Does SOX really have anything to say on whether developers should be denied READ ONLY access to Production database objects (code/schema) or is this restriction really self imposed?

This is not a programming but a legal question, and thus off-topic. — Deduplicator, Feb 20 '16 at 16:44

score 2 · Accepted Answer · answered Oct 11 '09 at 03:32

From what I understand, and in my experience, SOX compliance led to me not having any read access to the production database. This could be because of things like credit card numbers being in there, as, in our development environment, the real numbers were changed and encrypted, so we couldn't see anything anyway.

Also, in a proper deployment document you should simulate on QA what will happen when going to production, so you shouldn't be able to do anything on QA, as, if you have to do something then there is a problem with your deployment docs. You should fix your docs so that the sysadmins can do the deployment without any help from the developers.

At one company they actually had QA on a different network that the developers basically couldn't get to, in order to comply with SOX regulations.

This document may help you out: http://hosteddocs.ittoolbox.com/new9.8.06.pdf

As expected, the doc link mentions "A key requirement of Sarbanes-Oxley (SOX) compliance is separation of duties in the change management process. In a packaged application environment, separation of duties means that the same individual cannot make a change to the development database AND then move that change to the production database" ..but there is no mention of SOX restricting *READ ONLY* access to code on a dev or production server. I still think that this was a self-imposed restriction that my dept has placed on themselves to make our team less effective & it has worked. — Chad, Oct 11 '09 at 13:01
In my experience I haven't had read access to prod databases either, so it may be that the consultants are recommending this as a way to be safe. — James Black, Oct 12 '09 at 00:12

score 0 · Answer 2 · answered Jan 28 '13 at 22:20

I would recommend looking at a tool like Stackify that helps give restricted access to production servers and databases. Their system is designed to help you manage and troubleshoot productions applications while not being able to change anything. They provide audit reporting and etc to help with compliance.

score 0 · Answer 3 · answered Sep 08 '11 at 12:03

My understanding is that giving developers read only access to a QA database is not a violation of Sox.

Likely you would need to ensure the access is granted along with a documented formal justification and properly approved via a change control system.

Does SOX restrict access to QA environments or just production?

3 Answers3

Linked