IT segregation of duties

It's no secret that auditing standards are in flux. Simply defining segregation of duties is a great example of an area where different top auditing firms embrace different approaches. While it's generally agreed by all that developer access to migrate changes to production is a bad idea, beyond that, it's all a crapshoot. Here's some areas of contention between auditing firms:

• Can developers migrate changes to production if they are acting only in the capacity of production support -- if they don't have access to the physical code (such as a third party application)?
• Should DBA's be able to develop or promote applications using the databases they administer?
• Can DBA's have access to migrate their database changes to production?
• What about system testers -- should they have access to development environments?

Clearly we should follow minimalist principles, and all users should be given no more privilege than is necessary to do their job. However, when you try to apply theory to real IT environments, compromises in terms of mitigating controls may need to be made.

It's always pleasant at such times to lean back and fantasize about a formal release management process. For some companies, SOX can be the catalyst, but this is not a trivial exercise. It requires dedicated resources, expanded application and packaging expertise, as well as a huge shift in roles and responsibilities, which may not be feasible in many organizations.