Sox Itgc Audit

SOX IT General Controls Audit

Overview

This skill implements IT General Controls (ITGC) testing for Sarbanes-Oxley Act Section 404 management assessment of internal control over financial reporting (ICFR). ITGCs provide the foundation upon which automated application controls and manual controls depend.

Regulatory and professional framework references:

Key principle: ITGC deficiencies rated deficiency, significant deficiency, or material weakness based on likelihood and magnitude of misstatement to financial statements—not generic security severity alone.

Cross-skill mapping: access and logging domains leverage access-control-identity-audit and audit-logging-integrity; change automation leverages compliance-as-code-governance.

When to Use

Use this skill when:

• SOX 404 annual cycle: scoping financially relevant systems and testing ITGCs
• External auditor requests ITGC walkthroughs and sample testing for reliance
• Auditing ERP/cloud financial systems (Workday Financials, NetSuite, SAP S/4HANA)
• Reviewing change management for financially relevant applications and interfaces
• Assessing segregation of duties (SoD) in provisioning and developer access
• Evaluating computer operations controls for batch processing and backup/recovery
• Testing CI/CD and IaC changes affecting financial reporting infrastructure

Do not use this skill when:

• FedRAMP or federal cloud authorization (use fedramp-moderate-baseline)
• PCI-DSS payment card controls (use pci-dss-script-audit, pci-dss-network-segmentation)
• SOC 2-only audits without ICFR scope (use soc2-trust-services-criteria)
• GLBA Safeguards Rule for customer information at financial institutions (use glba-ffiec-financial-privacy)

Core Process

Execute steps in order.

Step 1: SOX scoping and financial relevance

1. Identify in-scope systems using risk-based scoping:
   • Systems that initiate, authorize, record, process, or report financial transactions
   • Interfaces feeding general ledger, revenue recognition, inventory, payroll-to-GL
2. Document locations and entities (domestic, international) in scope for 404.
3. Classify applications:
   • Tier 1: Direct GL impact (ERP core modules)
   • Tier 2: Indirect or supporting (reporting warehouses, integration middleware)
4. Exclude non-financial systems with documented rationale and management sign-off.
5. Artifact: sox-it-scope-{id}.json.

Step 2: COSO control environment and risk assessment

1. Walkthrough Control Environment (COSO principle 1–5):
   • Tone at top, board/audit committee oversight, organizational structure
   • HR policies, fraud risk factors, accountability for ITGC performance
2. Document Risk Assessment (principle 6–9) for IT changes and access—link IT risks to financial assertion risks (existence, completeness, accuracy, cutoff, authorization).
3. Identify key reports and data used in controls (parameter tables, master data) requiring ITGC coverage.
4. Note management override paths and monitoring controls.

Step 3: Access to programs and data (ITGC Domain 1)

1. Execute access-control-identity-audit with SOX mapping:

2. Test application-layer access separately from OS/database layers for Tier 1 systems.
3. Verify periodic access recertification by business owners (quarterly or per policy).
4. Use Postgres MCP read-only for role assignment queries where financial DB evidence resides.

Step 4: Program change management (ITGC Domain 2)

1. Define change population for examination period: emergency, normal, infrastructure (IaC).
2. For each sample change affecting financial systems, verify:
   • Request and approval (change advisory board or equivalent)
   • Development and testing separate from production
   • Migration authorization and backout plan
   • Post-implementation review for significant changes
3. Cross-ref compliance-as-code-governance:
   • GitHub MCP (mcp/github.mcp.json) for PR approvals, branch protection, CI status checks
   • Terraform/IaC changes mapped to change tickets
4. Emergency change samples: verify retroactive approval and enhanced monitoring.
5. FAIL if unaudited direct production edits or developer standing prod access without compensating controls.

Step 5: Program development (ITGC Domain 3)

1. For new financially relevant implementations in period:
   • Project charter, business case, steering committee oversight
   • Requirements sign-off, UAT with business users, conversion controls
   • Migration cutover checklist and hypercare support
2. Distinguish major projects (full SDLC testing) from minor enhancements routed through change management.
3. Verify segregation: developers lack production deploy rights without independent migration approval.

Step 6: Computer operations (ITGC Domain 4)

1. Test batch job controls:
   • Job schedules, success/failure monitoring, restart procedures
   • Reconciliation of batch output to control totals where applicable
2. Test backup and recovery:
   • Backup success logs, periodic restore tests, RTO/RPO alignment with BCP
3. Execute audit-logging-integrity subset for operations logging:
   • Job failure alerts, privileged command logging, incident tickets
4. Verify problem/incident management links to change management when root cause requires fix.

Step 7: IT-dependent manual controls and automated controls linkage

1. Identify IT-dependent manual controls (ITDMCs) relying on ITGCs (e.g., report parameters, user lists).
2. Map automated application controls (e.g., three-way match) to underlying ITGC prerequisites.
3. Document compensating controls where ITGC design gaps exist—must be evaluated by management and auditors for effectiveness.

Step 8: Deficiency evaluation and SOX 404 reporting

1. Classify deficiencies per PCAOB AS 2201 / company policy:
   • Control deficiency: design or operation failure
   • Significant deficiency: less severe than material weakness; important enough to merit attention
   • Material weakness: reasonable possibility of material misstatement not prevented/detected timely
2. Aggregate deficiencies—multiple low-risk access issues may combine to significant deficiency.
3. Prepare management assessment narrative: scope, methods, results, remediation plans.
4. Coordinate with external auditors on reliance: provide walkthrough docs, population definitions, sample selections.

Step 9: Evidence packaging and remediation tracking

1. Emit findings with SOX/COSO context:

id: FIND-SOX-001
severity: HIGH
control_id: SOX-ITGC-CHANGE-02
observation: "3 of 25 sampled ERP transports lacked independent migration approval"
recommendation: "Enforce dual approval workflow in change tool; remediate standing developer prod access"
owner: ""
due_date: null
status: open

2. Package: scope memo, walkthrough notes, sample workpapers, SoD reports, change tickets, access recertification exports.
3. Hash evidence per templates/audit-evidence-manifest.yaml.

Common Rationalizations

Red Flags

• Terminated employees with active ERP or financial reporting admin accounts
• Production changes deployed without tickets or with self-approval by developer
• SoD conflicts (create + approve same transaction type) without compensating monitoring
• No batch job failure alerting for GL close processes
• Backup restore never tested for financial database tier
• GitHub/terraform changes affecting financial infra without change record linkage
• Management override accounts without enhanced logging and periodic review
• ITGC walkthroughs not performed before detail testing (PCAOB expectation)
• Deficiencies closed without retest evidence in same SOX cycle

Verification

• Financial relevance scoping documented with Tier 1/2 classification and sign-off
• COSO control environment and risk assessment walkthrough completed
• Access ITGCs tested: provisioning, modification, termination, privileged, SoD, recertification
• Change management samples verified for approval, testing, migration, emergency retro review
• Program development projects in scope assessed for SDLC and UAT controls
• Computer operations tested: batch monitoring, backup/restore, incident linkage
• ITDMC and automated control dependencies mapped to ITGC results
• Deficiencies classified (deficiency / significant deficiency / material weakness)
• External auditor reliance materials prepared (populations, samples, walkthroughs)
• Evidence manifest complete with SHA-256 hashes and engagement ID