SOX Compliance for Engineering Teams

Sarbanes-Oxley (SOX) affects every publicly traded company and an increasing number of pre-IPO startups preparing for audit readiness. For engineering teams, SOX means your code changes, deployments, and access controls need documented evidence that they follow controlled processes. It doesn’t mean you can’t move fast — it means you need to prove you moved responsibly.

---

What SOX Requires from Engineering

SOX Control Area	Engineering Translation
Change management	Every production change has an approved ticket, review, and deployment record
Access controls	Least-privilege access, regular access reviews, MFA everywhere
Separation of duties	The person who writes code cannot also approve and deploy it
Audit trail	Immutable logs of who did what, when, to which system
IT General Controls (ITGC)	Backups tested, disaster recovery documented, incidents tracked

---

Change Management Controls

SOX-compliant change flow:

    Developer creates change
        → PR requires at least 1 reviewer (not the author)
            → CI/CD tests pass (automated gate)
                → Change ticket approved by change manager
                    → Deployment executed by CI (not developer)
                        → Deployment evidence logged (commit SHA, timestamp, approver)

Evidence Artifacts

Artifact	What It Proves	Storage
PR with review approval	Code was reviewed before deployment	GitHub/GitLab (immutable)
CI/CD pipeline logs	Tests passed, deployment was automated	CI system (retained 7 years)
Change ticket	Business justification documented	Jira/ServiceNow
Deployment record	Who deployed, when, what version	Deployment system + logging
Rollback capability	Recovery plan exists	Documented runbook

---

Access Control Requirements

Control	Implementation	Evidence
Least privilege	RBAC with named roles, no shared accounts	IAM policy snapshots
MFA enforced	Hardware key or TOTP for all production access	IdP configuration audit
Access reviews	Quarterly review of who has access to what	Spreadsheet/tool export with sign-off
Joiner/mover/leaver	Automated provisioning/deprovisioning	HR→IT integration audit trail
Emergency access	Break-glass procedure with mandatory post-review	Break-glass log + incident report

Production Access Tiers

Tier	Access	Who	Approval
Tier 0	Read-only logs and metrics	All engineers	Auto-provisioned
Tier 1	Application-level config changes	On-call engineer	Self-serve with logging
Tier 2	Database read access	Data engineers, SRE	Manager approval
Tier 3	Database write access	DBA only	Incident ticket + 2 approvals
Tier 4	Infrastructure admin	Platform team lead	VP approval + time-limited

---

Separation of Duties Matrix

Role	Write Code	Review Code	Approve Deploy	Execute Deploy	Database Access
Developer	✅	❌ (own code)	❌	❌	❌ (production)
Peer reviewer	✅	✅	❌	❌	❌ (production)
Release manager	❌	❌	✅	❌	❌
CI/CD system	❌	❌	❌	✅	❌
DBA	❌	❌	❌	❌	✅

---

Audit Trail Requirements

System	What to Log	Retention
Source control	Commits, PRs, reviews, branch protections	7 years
CI/CD	Build logs, test results, deployment records	7 years
Cloud IAM	Access grants, role changes, login events	7 years
Database	Schema changes, admin queries, access grants	7 years
Incident management	Incident timeline, resolution, post-mortem	7 years

---

Automating SOX Evidence Collection

Evidence	Automation Approach
PR review proof	GitHub API → extract PR approvals, auto-archive
Deployment records	CI/CD → structured deployment log (JSON)
Access reviews	IdP API → quarterly export of all access grants
Change tickets	Jira API → extract approved change tickets
Test results	CI → test result artifacts archived per deploy

---

Anti-Patterns

Anti-Pattern	Audit Risk	Fix
Shared service accounts	No individual accountability	Named accounts with MFA
Self-merged PRs	Separation of duties violation	Branch protection: require reviewer ≠ author
Manual deployments	No deployment evidence	CI/CD with immutable deployment logs
Console-based changes	No change ticket trail	Infrastructure-as-code with PR-based changes
Overdue access reviews	Stale access = unauthorized access	Automate quarterly reviews with IdP integration

---

Checklist

• Branch protection: PRs require at least 1 reviewer ≠ author
• CI/CD deploys to production (no manual deployments)
• Change tickets required and linked to every production deploy
• MFA enforced for all production access
• RBAC implemented with named roles (no shared accounts)
• Quarterly access reviews documented and signed off
• Emergency access (break-glass) procedure documented with audit trail
• Audit logs retained for 7 years (source control, CI, IAM, database)
• Separation of duties matrix documented and enforced
• Evidence collection automated where possible

---

:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For compliance engineering consulting, visit garnetgrid.com. :::