Your SOX Controls Are a Stage Play for Your Auditor
Sarbanes-Oxley is not just a good idea, it is federal law (thanks Enron). The goal of SOX is to ensure that financial reports are true and accurate. One of the key tenants of SOX is the separation of duties. What this means is that whomever deploys to a system that impacts financial data, can’t be the same person that made the change. (in the DevOps world, we meet this via the “pipeline user” service principal)
For publicly traded companies, SOX compliance is non-negotiable. In most companies, this is achieved through a beautiful piece of theater; a colossal, expensive and fragile piece of theater.
If William Shakespear were alive today, he might write a play for the auditors that follows the following script:
- A developer writes code to change a financial calculation. They create a pull request. (Opening Act)
- A different engineer reviews and approves the code in GitHub. (Act I: The Peer Review)
- The developer then opens a JIRA ticket, attaching the pull request link, and assigns it to their manager.
- The manager, having no real context beyond the JIRA title, clicks the "Approve" button. (Act II: The Managerial Sign-Off)
- The JIRA ticket is then assigned to the Operations team. An Ops engineer sees the ticket, navigates to the repo, pulls the approved code, and manually runs the deployment script. (Act III: The Separation of Duties)
(Curtain closes)
The theater empties. The auditor is satisfied, the appropriate people were involved. Checklist met.
But what is the REAL result. The audit trail is a hot mess, spanning multiple different systems. The “rubber stamp” made an appearance. And the Ops engineer could have been one of the Three-blind-mice; having no more visibility into what is going on than a ticket stating “Do the Deployment”.
Can you find the controls? Hint: there aren’t any. William Shakespear would be proud of this theater. Compliance theater that only slows your delivery to the speed of a person, while creating a “chain of evidence" that is built on a wish and a prayer.
The issue is that we are still beholden to ghosts from the waterfall era. We have confused separation of people with separation of concerns.
Before CI/CD and “scripts copying files from a share”, people were the only ones who could “act”. This required different PEOPLE. Auditors built their mental model around this people focused approach. But in today’s day and age, we have a new employee; the pipeline user service principal, or the pipeline itself.
This is a fundamental truth. This satisfies SOX controls. The pipeline is a person.
The service principal for your GitHub Actions runner or your Azure DevOps agent is a distinct, cryptographic identity. It has its own credentials. It has a specific set of permissions, and the piece-de-resistance is that every action is logged in an immutable, timestamped, and auditable trail.
A developer can write code, can push code, can merge code. Their actions can TRIGGER a pipeline to run, but the modern analogy is that the developer just gave Ops a ticket to “Do the deployment”. This is a cryptographic control enforced via IAM. The separation is pure and absolute.
With this in mind, the entire stage play becomes obsolete. William Shakespear can retire. A mondern, robust SOX control isn’t found in a Git log, or a JIRA ticket. It is the pipeline.yml file its self.
- The Old Way: A fragile, manual handoff between three people, creating three separate, hard-to-correlate audit trails.
- The New Way: A single, automated workflow, executed by a non-human identity, that produces a single, cryptographically-signed release manifest as its output. That manifest is the perfect, immutable audit trail.
The best part about our CI/CD pipelines is that we have actually made a stronger, more verifiable control, which is “instantaneous”. We don’t have to wait for manual approvals, or rubber stamps. We have actually IMPROVED compliance while pressing the accelerator.
We have to bring our auditors along. We have to educate them. We have to stop participating in the theater and showing that there is a “better, faster” way to maintain compliance.
The question to ask your Head of Compliance is not "How can we make our change approval process faster?" The real question is: "Is our SOX compliance a fragile, expensive performance designed to satisfy a legacy checklist, or is it an automated, immutable system of proof that makes us both safer and faster?"