SOX IT General Controls have a history that predates cloud computing by over a decade. The four ITGC domains — Change Management, Access Controls, Computer Operations, and Program Development — were designed for environments where the data centre was in the basement, change management meant paper forms, and access was controlled by a single LDAP directory. Cloud-native implementations of the same control objectives look fundamentally different, and the audit community has spent the past decade developing testing approaches for cloud environments. Engineering teams that understand what auditors will test can build systems that pass rather than systems that generate findings and remediation requests.
Change Management in Cloud Environments
SOX Change Management controls have three objectives: changes to in-scope systems are authorised before implementation, changes are tested before deployment to production, and changes can be traced from request to implementation. In cloud-native environments, these objectives are satisfied by: pull request approvals in version control (the authorisation record), automated test suites in the CI/CD pipeline (the testing evidence), and deployment pipeline logs (the implementation trace). The PCAOB auditor will request a population of all changes deployed to in-scope production systems during the audit period, sample selections from that population, and evidence for each sampled change demonstrating authorisation, testing, and implementation. If the CI/CD pipeline does not generate structured, queryable deployment records that tie a specific commit to a specific production deployment, the Change Management evidence package cannot be assembled without manual reconstruction.
The most common SOX ITGC finding in cloud-native environments is emergency change management: a hotfix was deployed directly to production outside the normal CI/CD pipeline to resolve a critical incident, and the change was not retrospectively documented and approved. Every cloud-native system needs an emergency change procedure that creates documentation at the time of the change, not as a retrospective exercise. Emergency changes that bypass the normal pipeline should trigger an automatic ticket creation for retrospective review and approval within a defined timeframe (typically 24-48 hours).
Access Controls in Cloud Environments
SOX Access Controls have three objectives: access to in-scope systems is granted based on business need, privileged access is restricted and monitored, and access is reviewed periodically and terminated when no longer needed. In cloud environments, these translate to: IAM role assignments tied to documented business justifications, separation of duties enforced through role boundary policies (no single IAM principal can both deploy to production and approve their own deployments), privileged access management through Vault or AWS IAM Identity Center with session logging, and automated access reviews that generate evidence without manual effort. The access review is a consistent source of audit findings — most organisations can produce evidence of some access reviews but have gaps. Automated access review tools that pull current access grants, present them for review, and generate a timestamped evidence record are the standard solution.
Computer Operations
Computer Operations controls address the reliability and monitoring of production systems. The key evidence artefacts are: monitoring configuration documentation (what is monitored, at what thresholds, and who is notified), incident records for the audit period (demonstrating that incidents were detected, responded to, and resolved within defined SLAs), and capacity management records. Most cloud-native organisations have monitoring infrastructure; the compliance gap is typically in documentation and evidence retention. CloudWatch alarm configurations, PagerDuty runbooks, and incident records must be retained for the audit period and queryable by the compliance team.
Program Development
Program Development controls address the system development lifecycle. For cloud-native systems, the evidence is in the SDLC tooling: requirements in Jira or similar, design documentation in Confluence or similar, code review records in GitHub or GitLab, automated test results in the CI/CD pipeline, and acceptance testing sign-offs before production deployment. The common gap is in requirements documentation: engineering teams treat Jira tickets as lightweight task trackers, not as formal requirements documents. Auditors testing Program Development controls will look for evidence that in-scope changes had formal requirements before development began. A Jira ticket that says "Fix the login bug" with no further detail is insufficient.
- Instrument the CI/CD pipeline to generate structured deployment records that tie each production deployment to a specific pull request, approver, test results, and timestamp
- Implement an emergency change procedure that creates documentation at the time of the change, with a defined retrospective approval workflow
- Build automated access reviews into the compliance programme — quarterly for privileged access, annually for standard access
- Retain monitoring configurations, incident records, and capacity management records in an auditor-accessible location with defined retention periods
- Upgrade Jira workflow requirements for in-scope system changes to include sufficient detail for auditors to assess the formality of the requirements process
- Test the SOX ITGC evidence package before the audit period ends — engage an internal audit team or external advisor to perform a pre-audit walkthrough
EU AI Act: What CTOs Actually Need to Do Before August 2026
DORA Is Live. Here's What 'Operational Resilience' Means for Your Codebase
FedRAMP Rev 5: What Changed and Why Most Current ATO Holders Are Already Non-Compliant
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.