With difficulty.
For example - you can still have an Ops team, and they have the required access.
The developers access to production is done on a case by case basis, with some sort of tracking of who logged in. and why.
Also, doing full pre - merge code review helps, as it is yet another set of eyes on the code that will be pushed to production...
In short - its not a "one solution fits all", and it is something that needs to be discussed with you SOX auditors, to find a working solution for your company
Thanks for the response! We keep a distinct separation of duties, but we try to keep both groups in constant contact to minimize animosity in both groups. We pick and choose some DevOps ideals to make it fit, was just curious about other people's experience.
SoD simply means your systems or processes require at least two different people to make any changes. If your entire tech team is DevOps then it simply means the dev who tests and deploys a given code change is different from the dev who wrote the code. These different roles can be per task, it doesn't have to be full-time persons assigned to full-time roles.
DevOps doesn't mean people doing multiple jobs. You can collaborate with separated roles and be productive. Furthermore you can build abstraction to simply remove manual, unrecorded interaction with systems to satisfy auditing and regulation.
It seems, from reading the article, like the need would be satisfied by having two dev-ops engineers manage something, rather than one developer and one ops guy.
In short - its not a "one solution fits all", and it is something that needs to be discussed with you SOX auditors, to find a working solution for your company