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?

Answer 1

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