SOX, Internal Controls, and Compliance Frameworks

If you work on an ERP at a listed company, compliance shapes your daily process — what you can access, how code gets deployed, and what evidence you must produce.

What SOX is

The Sarbanes-Oxley Act (2002), passed after the Enron and WorldCom frauds. Applies to companies listed on US exchanges, including foreign private issuers.

The two sections that matter:

  • Section 302 — the CEO and CFO personally certify that the financial statements are accurate and that internal controls are effective. Personally, with criminal liability.
  • Section 404 — management must assess and report on internal control over financial reporting (ICFR), and the external auditor must attest to it.

Section 404 is why your ERP is in scope. If the financial statements come from the ERP, the ERP’s controls are financial reporting controls.

Equivalents elsewhere: J-SOX (Japan), C-SOX/Bill 198 (Canada), UK Corporate Governance Code (with an expanded UK internal controls regime phasing in), EU CSRD for sustainability reporting, and King IV (South Africa).

The control types 

ITGC — IT General Controls
  Apply to the whole IT environment
  ├── Access to programs and data
  ├── Program change management
  ├── Program development
  └── Computer operations

ITAC — IT Application Controls
  Built into the application
  ├── Input validation
  ├── Processing accuracy (three-way match, tolerance checks)
  ├── Output completeness
  └── Automated approvals and limits

Business process controls
  ├── Manual (reconciliations, reviews, approvals)
  └── Automated (system-enforced)

ITGCs are the foundation. If ITGCs fail, the auditor cannot rely on any automated control, and everything must be tested manually — which is expensive and makes the audit much more intrusive. This is why an ITGC failure is a serious finding.

ITGC in practice — what auditors test

1. Access to programs and data 

□ User access is granted through an approved request process
□ Access is removed promptly on termination      ← most commonly failed
□ Access is reviewed periodically (recertification) with evidence
□ Privileged access is restricted and monitored
□ Segregation of duties is enforced
□ Developers do not have production write access
□ Generic/shared accounts are minimised and justified
□ Password/MFA policy is enforced

2. Program change management 

□ Changes are requested, approved, tested, and approved for deployment
□ Testing evidence is retained
□ Deployment is performed by someone other than the developer
□ Emergency changes follow a defined, documented process
□ Environments are segregated (DEV/QAS/PRD)
□ Only authorised code reaches production

3. Program development 

□ New systems and major changes follow an SDLC
□ User acceptance testing is performed and documented
□ Data conversion is validated and reconciled
□ Go-live approval is documented

4. Computer operations 

□ Batch jobs are scheduled, monitored, and failures are addressed
□ Backups are performed and restore is tested
□ Incidents are logged and resolved
□ Disaster recovery is documented and tested

Key ERP application controls

Control Type Tested by
Three-way match with tolerances Automated Inspecting configuration + a sample
Approval workflow with value thresholds Automated Configuration review + a sample
Credit limit check Automated Configuration + attempting to breach it
Duplicate invoice check Automated Configuration + a test posting
Period-end close controls Automated Attempting to post to a closed period
Automatic account determination Automated Configuration review + posting samples
Mandatory field validation Automated Attempting an incomplete posting
Document numbering (gapless) Automated Gap analysis over the population
Reconciliation account controls Automated Attempting a direct posting
Bank reconciliation Manual Reviewing evidence
Manual journal review Manual Reviewing evidence and approval

Automated controls are cheaper to audit than manual ones, because the auditor tests the configuration once plus a small sample, rather than testing every occurrence. This is a genuine business argument for automating a control, and worth making when someone proposes a manual review as a fix.

Control documentation

Every control needs:

Control ID:      FIN-AP-003
Description:     The system prevents posting a vendor invoice where the
                 quantity or price varies from the PO beyond configured tolerance.
Control owner:   AP Manager
Frequency:       Every transaction (automated)
Type:            Preventive, automated, ITAC
Risk addressed:  Overpayment to suppliers; unauthorised expenditure
Evidence:        Configuration screenshot of tolerance settings;
                 blocked invoice report for the period
Test procedure:  Inspect configuration; attempt a posting outside tolerance;
                 review the blocked invoice report for the period
Frequency of testing: Annually (configuration), quarterly (report review)

Developers get asked for evidence. A screenshot of the tolerance configuration table, an extract of blocked invoices, a list of users with a given authorisation. Knowing where to find these quickly makes you valuable during audit season.

Deficiency severity 

Control deficiency         A control doesn't operate as designed
Significant deficiency     Important enough to merit attention by those
                           charged with governance
Material weakness          A reasonable possibility that a material
                           misstatement would not be prevented or detected

A material weakness must be publicly disclosed. It moves the share price, triggers shareholder questions, and sometimes costs executives their jobs. This is why control failures are taken seriously in a way that surprises developers coming from other industries.

Common ERP audit findings

Ranked roughly by frequency:

  1. Terminated users still active — the HR-to-IT deprovisioning link is broken
  2. Developers with production access
  3. Segregation of duties conflicts not remediated or documented
  4. Superuser access over-assigned or unmonitored
  5. Emergency changes without documentation or retrofit
  6. Access recertification not performed or not evidenced
  7. Testing evidence not retained for changes
  8. Shared/generic accounts with no accountability
  9. Manual journal entries without documented approval
  10. Reconciliations not performed timely or not evidenced
  11. Batch job failures not monitored or addressed
  12. Backup restore never tested

Notice how many are process and evidence failures, not technical ones. The control usually exists; nobody can prove it operated.

What this means for your daily work

Practice Why
Every change has a ticket Change management evidence
Every change is tested, with retained evidence Testing evidence
You don’t deploy your own code to production Segregation
You don’t have production write access Access control
Emergency changes are documented within 24h Change management
Custom code respects authorisation checks Access control
Custom code writes to the change log Audit trail
You don’t share credentials Accountability
Batch failures are logged and addressed Operations

“I fixed it directly in production because it was urgent” is a control failure, even when the fix was correct and the urgency was real. Use the emergency process — it exists precisely for this.

Other frameworks you’ll encounter

Framework Scope
COSO The internal control framework SOX assessments are based on
COBIT IT governance framework; maps well to ITGCs
ISO 27001 Information security management
SOC 1 (ISAE 3402) Controls at a service organisation relevant to financial reporting — if you run an ERP SaaS, your customers will demand this
SOC 2 Security, availability, confidentiality, processing integrity, privacy
PCI-DSS If you store or process card data
NIST CSF Cybersecurity framework
ITIL Service management — incident, problem, change

If you’re building an ERP product: SOC 1 Type II is the price of entry for enterprise customers. Their auditors need assurance over your controls because your system produces their financial data. Design for it early — retrofitting evidence-producing controls is much harder than building them in.

Audit season

Typically the last quarter of the fiscal year plus the first months after:

- Walkthroughs: the auditor observes a process end to end
- Control testing: samples selected, evidence requested
- Data extracts requested — often full population
- IT questionnaires
- Interviews with control owners
- Findings raised, management responses drafted
- Remediation plans agreed

Practical advice: respond quickly and completely. A slow or partial response turns a simple question into a finding. And keep the standing reports listed in Audit Trails ready — most requests are the same every year.

The developer’s compliance mindset

Compliance is not bureaucracy for its own sake. Each requirement traces back to a fraud or a failure that actually happened:

  • Access removal on termination → because departing employees stole data and money
  • Developers off production → because developers made unauthorised changes
  • SoD → because single individuals defrauded companies for years
  • Change management → because untested changes broke financial systems
  • Audit trails → because without them, fraud was undetectable

Understanding why makes compliance tolerable and makes you better at proposing solutions that satisfy it rather than fighting it. The colleague who says “we can achieve that control automatically instead of with a manual review” is the one auditors and finance teams both want to work with.

Next