The Framework That Still Runs the Quarter
Sarbanes-Oxley turned 22 this year. Section 404's internal-controls-over-financial-reporting requirement has outlived multiple software-delivery paradigms — waterfall, Agile, DevOps, platform engineering — and the IT General Controls (ITGC) framework that auditors use to test it has changed remarkably little. The Big Four audit guidance in 2024 reads very similarly to 2004.
The consequence is that IT auditors still ask for change tickets, access reviews, and segregation-of-duties evidence that was designed around a mainframe release cycle and monthly deployments. Modern engineering teams deploy dozens of times a day through pipelines that the control framework doesn't obviously cover. The gap creates friction: auditors ask for evidence the team can't produce in the expected format, and the team feels constantly interrupted by audit cycles.
This post walks through how to translate modern software delivery into ITGC evidence — and, separately, how to layer software-specific controls (SBOM, SCA, signing) onto the existing SOX framework without confusing the IT audit team.
The Four ITGC Domains
SOX ITGC evidence clusters into four domains, which SOC 1 auditors call Control Objectives for Financial Reporting and Big Four firms call Change Management, Logical Access, Computer Operations, and Systems Development / Program Development.
Change Management — controls over authorization, testing, and deployment of changes to systems supporting financial reporting. Auditors sample change tickets and look for evidence of request, approval, testing, and deployment records.
Logical Access — controls over who can access in-scope systems. Access provisioning, periodic review, and termination.
Computer Operations — job scheduling, backup/recovery, incident management. Historically the smallest domain; in modern environments it covers observability and incident response.
Program Development — initial development controls for new in-scope systems. A smaller domain for most companies; matters most during major system implementations.
Mapping Modern Delivery to Change Management
Modern change management under SOX is where most friction sits. A CI/CD pipeline that auto-deploys on pull-request merge produces hundreds of changes per week; auditors are used to sampling from a change management system. The resolution is to treat the pull request AS the change ticket.
Specifically:
- Change request and business approval → the pull request itself, with description templates that capture the change purpose, author, and any ticket reference.
- Development and testing → the CI pipeline run attached to the PR, showing linter, unit, integration, and security-test results.
- Review and approval → required reviewers under CODEOWNERS, branch protection rules enforcing at least one approval before merge.
- Deployment → the CD pipeline run, with deployment logs and the SHA of the deployed commit.
- Verification → monitoring alerts, canary analysis, or post-deployment checks recorded in the same system.
When the IT auditor samples a change, they receive a link to the PR with the pipeline runs attached. The conversation becomes "here is the tool-emitted evidence" rather than "let me find the ticket."
This mapping works only if three conditions hold. First, branch protection has to prevent merges without review — enforced, not just configured. Second, the CI/CD pipeline has to emit an auditable log that survives beyond the runner's retention. Third, deployments to in-scope systems must come only from the pipeline, not from humans with console access.
Logical Access in the Platform Era
Access controls under SOX ITGC cover "who can do what to the system." In a modern environment, the boundaries are blurrier: a developer can't directly write to production, but they can merge a PR that deploys to production. Auditors need to understand the pipeline as a control.
The evidence pattern:
- Source-code access reviews — quarterly review of GitHub/GitLab/Bitbucket permissions on in-scope repositories. Template: role, repository, justification, reviewer signoff.
- Pipeline access reviews — who can modify CI/CD configuration (GitHub Actions workflows, Jenkinsfiles, Azure Pipelines YAML). These are now privileged access.
- Production access reviews — who has console access (emergency), service-account access, or break-glass credentials.
- Secrets access — who can read the HashiCorp Vault namespace, AWS Secrets Manager path, or equivalent, for in-scope systems.
The emergency-access angle matters. Many engineering organizations have break-glass paths for production that bypass normal change management. SOX auditors will ask about these; the control is that break-glass use triggers an automated ticket, an after-action review, and recorded approval.
Segregation of Duties in DevOps
The classic SoD concern is that the same person shouldn't both develop code and deploy it. In DevOps, this cleanly fails — developers routinely merge their own PRs after a reviewer approves. The compensating control is that the merge requires a second human reviewer and an automated pipeline; the combination of reviewer plus pipeline enforces separation of duties more strongly than a single deployer role ever did.
Auditors are generally comfortable with this framing when it's documented. The key elements are:
- Branch protection requiring at least one reviewer other than the author.
- Prohibition of direct pushes to the main branch.
- Pipeline-only deployment paths, with pipeline configuration stored in protected repositories.
- Quarterly reviews of who can bypass branch protection.
Software-Specific Controls as a Layer
SOX didn't contemplate software components or SBOMs. But auditors increasingly ask about vulnerability management and supply chain as part of the Risk Assessment domain. The clean approach is to layer software-specific controls onto the ITGC framework:
- Component inventory (SBOM) — supports change management. When a security finding requires a change, the SBOM identifies scope.
- Automated vulnerability gates — pipeline controls that block merges on critical CVEs. These are preventive change management controls.
- Build reproducibility — deterministic builds let auditors verify that deployed artifacts match source. This strengthens the PR-as-change-ticket model.
- Artifact signing — Sigstore or equivalent ensures only pipeline-produced artifacts deploy. This supports logical access (restricts deployment to pipeline identity).
None of these are strictly required by SOX, but they produce evidence that strengthens the existing ITGC story.
The SOC 1 Distinction
Service organizations supporting financial-reporting customers undergo SOC 1 Type II audits. SOC 1 uses Control Objectives for Financial Reporting that closely parallel SOX ITGC. For service providers, the mapping is slightly different — the COFR is phrased around specific outcomes rather than categorical controls — but the underlying evidence is the same.
A service provider running a payment platform that supports a customer's financial reporting will have its SOC 1 report tested by the customer's SOX team. Strong ITGC evidence in the SOC 1 feeds directly into the customer's SOX compliance.
Common Pitfalls
Manually re-creating change tickets. Don't. The PR is the ticket. Export from the source-control system, with timestamps and reviewer identities intact.
Overscoping ITGC. Not every system is in scope. SOX auditors should define the in-scope systems (those supporting financial reporting) clearly. Applying ITGC to non-in-scope dev environments creates wasted work.
Missing break-glass controls. Emergency production access is the most common control gap. Build the alerting and after-action workflow before the audit, not during.
Forgetting third-party SaaS. If the financial close runs on a SaaS vendor, the vendor's SOC 1 report is part of your SOX evidence. Collect them.
How Safeguard Helps
Safeguard's policy gates integrate with GitHub, GitLab, and Azure DevOps to make PRs the auditable change records SOX expects — with reviewer identity, CI results, and deployment logs emitted in auditor-friendly exports. SBOM generation and vulnerability gates add software-supply-chain depth to ITGC change management, and signed artifacts strengthen the deployment-path story under logical access. Quarterly access-review exports for in-scope repositories and pipelines are generated automatically. When auditors sample changes, the evidence is the tool-emitted record rather than a reconstructed narrative.