The SOX ITGCs Auditors Actually Sample (And Where They Live in Your Code)

SOX ITGCs Are Not Just an IT Ops Problem

The Sarbanes-Oxley Act's IT General Controls (ITGCs) are designed to ensure that systems processing financial data are reliable, accurate, and protected from unauthorized modification. Most compliance guidance frames ITGCs as infrastructure and operations controls. But a significant set of ITGCs are satisfied or violated at the application layer.

Change Management Controls (CC8)

The change management ITGC domain (mapped to COSO CC8 in most frameworks) requires:

CC8.1. Authorize Changes Before Implementation

Every change to production systems must be authorized. In code terms: all commits to main/production branches require review, approval records must be retained, and emergency change procedures are documented and audited.

The code-level finding: direct commits to production branches without PR/review records are CC8.1 evidence gaps. Audit logs must show who approved what change.

CC8.2. Test Changes Before Deployment

Changes must be tested before reaching production. For software, this means:

• Test environments that reflect production configuration
• Test results are captured and retained
• Security testing is included in the change control process

Security scan results as part of the deployment pipeline are CC8.2 evidence. A SARIF report attached to a PR review is CC8.2 documentation.

Logical Access Controls (CC6)

CC6.2. Segregation of Duties

Developers should not have unilateral access to deploy code to production. This control requires:

• Separation between development and production access
• Production deployments require a second party
• Privileged access to production databases is logged and reviewed

In code terms: hard-coded production credentials in developer configurations, or developer access tokens with production write permissions, are CC6.2 findings.

CC6.3. Restrict Privileged Access

Administrative access to financial systems should be restricted, monitored, and time-limited. In application code, this means admin endpoints are separated from application endpoints, admin actions are logged to a separate audit log, and admin sessions have shorter timeout intervals.

Computer Operations Controls (CC7)

CC7.2. Monitor System Components

System components must be monitored for anomalous behavior. At the application layer: audit logging for financial transaction processing, alerting on unusual access patterns, and exception handling that preserves audit trail information.

CWE-778 (Insufficient Logging) is a CC7.2 finding for applications processing financial data.

The Auditor Evidence Requirement

SOX auditors test ITGCs by sampling evidence. For CC8.1, they'll select a random sample of production changes and ask for the approval record. For CC6.2, they'll ask for the deployment authorization log. For CC7.2, they'll ask for the audit log and evidence that exceptions were investigated.

The common failure mode: the controls exist in policy but the evidence isn't captured or retained in a format auditors can evaluate. Automated scanning with timestamped, signed SARIF output creates evidence records that survive audit scrutiny.

How Deva Addresses SOX ITGC

Deva's SOX preset maps code-level findings to the specific ITGC control domains. CWE findings related to authentication, logging, and access control are annotated with their SOX control references. The SARIF export includes metadata suitable for inclusion in audit evidence packages: timestamp, scanner version, rule set, finding count by severity, and remediation status. SOX work usually runs alongside PCI-DSS and SOC 2. See financial compliance for the unified preset.