SOX Section 404 requires that management assess and report on the effectiveness of internal control over financial reporting. The PCAOB's Auditing Standard AS 2201 defines how external auditors evaluate those controls. The controls that are relevant to software engineering — IT General Controls (ITGCs) — cover change management, access control, computer operations, and program development. A DevSecOps pipeline in a SOX-regulated environment must be designed to produce evidence that satisfies ITGCs, not just to deploy software quickly. Most DevSecOps implementations in financial services are not designed this way.
Change Management Controls Under SOX ITGC
PCAOB AS 2201 requires that changes to financially significant systems follow a documented approval process. In a DevSecOps context, this means: every commit that touches financially significant code must be traceable to an approved change request; the deployment pipeline must enforce that unapproved changes cannot reach production; and the evidence of approval must be retained for the duration of the audit retention period (typically 7 years under SOX). Most CI/CD pipelines produce deployment records — git hashes, build IDs, deployment timestamps. These records satisfy the "what deployed" question. They do not satisfy the "who approved it" question without integration with a change management system (ServiceNow, Jira, BMC Remedy) that captures approval workflows.
Segregation of duties (SOD) is a core ITGC requirement: the engineer who writes the code should not be the same person who approves and deploys it to production. In a small DevSecOps team, this is operationally difficult. The architecture solution is a deployment pipeline that enforces SOD through technical controls — requiring a different GitHub/GitLab user to approve the pull request, a different role to approve the production deployment — rather than relying on process controls that are difficult to audit.
SAST/DAST Integration as an ITGC Control
Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) are typically justified on security grounds. In a SOX ITGC context, they are also change management controls: they provide evidence that changes to financially significant systems were tested before deployment. The evidence requirement is specific: the SAST/DAST scan results must be retained, associated with the specific deployment, and available to the auditor. A scan that runs and produces results that are discarded satisfies neither the security requirement nor the audit requirement.
The common failure: SAST/DAST is integrated into the pipeline as a gate — builds fail if critical findings are present — but the scan results are not retained in an auditor-accessible format. Retaining scan results requires storage outside the CI/CD system (which may not have 7-year retention), structured output format (SARIF is the standard), and a query interface that allows the auditor to retrieve results for a specific deployment by date and system. Build this retention infrastructure into the pipeline from the start, not as a post-audit remediation.
Code Signing and Deployment Integrity
SOX ITGC requires that production systems contain only approved code. Code signing provides cryptographic assurance that the code deployed to production is the code that was approved. The pipeline architecture: each build produces a signed artifact (Docker image, JAR, Lambda package); the signature is verified at deployment time using a public key from a hardware security module; the signing event is logged with the approver identity. This architecture makes it cryptographically impossible to deploy code that was not signed by an authorized build process, which is the ITGC control that auditors are looking for.
- Integrate ServiceNow or equivalent ITSM with your CI/CD pipeline — deployment to production requires a linked approved change record in the ITSM system
- Implement branch protection rules that enforce SOD: require code review by a different user, require CISO or security team approval for changes to authentication or financial calculation code
- Configure SAST/DAST result archival to S3 or equivalent with 7-year WORM retention, indexed by build ID and deployment timestamp
- Implement code signing using AWS KMS, Azure Key Vault, or GCP KMS with HSM backing — sign every production artifact at build time
- Generate a Software Bill of Materials (SBOM) for every production deployment — retain SBOMs alongside audit logs for supply chain risk documentation
- Configure the deployment pipeline to write a deployment record to an immutable audit log on every production deployment — include: artifact hash, signer identity, approver identity, change record reference, deployment timestamp
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.