3 ms·

Separation of Duties is very, very much part of SOX regulation. While it may not explicitly say "One person can not both author a change, and push it to prod, w

Separation of Duties is very, very much part of SOX regulation. While it may not explicitly say "One person can not both author a change, and push it to prod, with no one else involved", if that's allowed and pointed out to any auditor, you are going to fail the audit. So, yes, you are technically correct (the best kind of correct!), but in any applicable sense, it is indeed a requirement. As I called out, there is loads of wiggle room on how to address it (technically you probably are in compliance if you just force PR approvals, but I'm not that familiar with the actual verbage, and am definitely not a lawyer), just that the risk aversion of most companies (and the intransigence of auditors) sees those who write the code (dev) and those who deploy the code (ops) being separated quite frequently in order to be SOX compliant.

sokoloff 6y ago
If your controls say you can do that, you will not fail the audit. The audit for SOX is a compliance-with-controls audit. Consider the jobs board for your company, the documentation site, or some other unrelated to financials, but production tech nonetheless. You can write your controls to say that someone can push an update without separating duties. Just as we do for PCI, one key to making SOX sensible is to keep as many systems out of scope of the strictest controls, by sensible design choices (in tech and in policy) and be strict where strictness is sensible and more free when that freedom is more sensible. SOX is only concerned with accuracy of financials and while it’s bad law in several key regards IMO, it seeks to accomplish this mostly via transparency and compliance with elected policy rather than specifically prescribing the policy contents. Many internal functions run on Excel sheets using “we save copies very carefully on shared drives” revision control. When those get changed, there might not be one person who knows everything that changed, let alone two.

sokoloff 6y ago

If your controls say you can do that, you will not fail the audit. The audit for SOX is a compliance-with-controls audit. Consider the jobs board for your company, the documentation site, or some other unrelated to financials, but production tech nonetheless. You can write your controls to say that someone can push an update without separating duties. Just as we do for PCI, one key to making SOX sensible is to keep as many systems out of scope of the strictest controls, by sensible design choices (in tech and in policy) and be strict where strictness is sensible and more free when that freedom is more sensible. SOX is only concerned with accuracy of financials and while it’s bad law in several key regards IMO, it seeks to accomplish this mostly via transparency and compliance with elected policy rather than specifically prescribing the policy contents. Many internal functions run on Excel sheets using “we save copies very carefully on shared drives” revision control. When those get changed, there might not be one person who knows everything that changed, let alone two.