IT General Controls (ITGC) Audit Guide: Risks, Testing and Evidence

An organisation may have documented access policies, change approvals, backup procedures, and monitoring in place. Yet it can still fail an ITGC audit if it cannot demonstrate that these controls operated consistently and effectively throughout the audit period.

This is the core reason organisations fail ITGC audits: evidence of control operation is incomplete, inconsistent, or missing. ITGC audits test two critical dimensions: whether controls are well-designed to prevent or detect specific IT risks, and whether those controls actually worked as intended in practice when applied to real systems and transactions.

Many audit findings arise not because controls are absent, but because the organisation has no proof that controls executed—no access logs, no approvals, no investigation records, no sign-offs. ITGC testing requirements appear across SOX compliance, SOC 1 Type II engagements, SOC 2 audits, internal audits, ISO 27001 assessments, and regulatory examinations. This guide covers ITGC framework-building, risk assessment, control domains, testing methods, evidence requirements, common findings, and audit reporting.

What Are IT General Controls?

IT General Controls are policies, procedures, and system configurations supporting the reliability, integrity, and availability of IT systems and the data they process. ITGCs encompass access management, change management, backup and disaster recovery, operations monitoring, and vendor management—controls that operate across applications rather than within a single application.

ITGCs are foundational to control effectiveness. A purchase-order approval control in an ERP system is only as effective as the access controls preventing unauthorised modifications to the approval workflow, the change management process preventing unapproved patches from disabling the control, and monitoring detecting when the control is bypassed. When ITGCs fail, application controls become unreliable. Auditors assess ITGC strength early because weak ITGCs signal that the entire control environment is at risk.

ITGC vs IT Application Controls

IT Application Controls are built into a specific business application: approval workflows, validation rules, segregation of duties enforcement within a system, reconciliation logic. An IT Application Control prevents an invalid vendor ID in accounts payable.

ITGC Controls are the infrastructure supporting all applications: who can access systems, how changes are implemented, whether backups work and can be restored. An ITGC control ensures only authorised people can modify the validation rule itself. Application controls fail if developers can bypass them, if backups don't work so data corrupts, or if system access is permissive so anyone can extract transaction data.

Building an ITGC Framework

A practical ITGC framework-building process follows these steps:

• Identify in-scope systems: Determine which applications, databases, and infrastructure are material to financial reporting or operations.
• Define risks and control objectives: Identify IT risks and articulate what controls should achieve.
• Select controls: Design or select specific control activities.
• Assign control owners: Designate responsibility for each control and establish accountability.
• Set frequencies: Define how often each control executes (daily, quarterly, annually).
• Define evidence: Specify what proof is needed to demonstrate control execution.
• Test design: Confirm the control can prevent or detect the risk as designed.
• Test effectiveness: Gather evidence that the control executed throughout the audit period.
• Report deficiencies: Document control failures and deviations.
• Track remediation: Manage findings to closure with documented evidence.

ITGC Risk Assessment and Risk-Control Matrix

A risk-control matrix documents the relationship between IT risks, control objectives, and control activities. Each row captures the complete control picture: Risk, Control Objective, Control Activity, Owner, Frequency, Preventive or Detective, Manual or Automated, Evidence Required, and Operating Effectiveness.

Example Risk-Control Matrix Entry:

Where ITGC Audits Apply

SOX (Sarbanes-Oxley): Public company auditors test IT controls supporting management's assessment of internal control over financial reporting. Focus is on controls preventing or detecting misstatements in financial statements.

SOC 1 Type II: Service auditors test the design and operating effectiveness of service organisation controls relevant to user entities' financial reporting.

SOC 2 Audits: Type II reports test controls against Trust Services Criteria in the categories included in the engagement scope (not all categories are included in every report).

ISO 27001: Organisations implement an information security management system with policies, processes, and controls to manage information security risks.

COBIT 2019: A governance and management framework for enterprise information and technology addressing strategy, risk, and performance.

Key distinction: These frameworks overlap, but their objectives, criteria, and assurance requirements are not interchangeable. Which framework applies to an audit determines what controls are tested, how they are tested, and what evidence is required.

Core ITGC Control Domains

Logical Access and Identity Management: Restrict system access to authorised users; manage user provisioning and deprovisioning; enforce authentication and authorisation controls. Auditors test access reviews, termination procedures, authentication methods.

Privileged and Service Accounts: Manage accounts with elevated permissions; detect and investigate inappropriate use. Auditors test PAM systems, approval workflows, access logging.

Change Management: Ensure only authorised, tested changes are deployed to production; enforce segregation of duties. Auditors test change approvals, testing evidence, deployment logs.

Computer Operations and Job Monitoring: Detect and investigate system failures and critical job failures; ensure issues are resolved. Auditors test monitoring setup, alerting, investigation documentation.

Backup, Restore and Disaster Recovery: Ensure data can be recovered after loss or corruption; test restoration periodically. Auditors test backup frequency, restoration testing, recovery procedures.

System Development and Implementation: Ensure systems are developed securely and tested before production deployment. Auditors test design reviews, code review, security testing.

Cloud, Vendor and Third-Party Oversight: Ensure external services maintain adequate controls and provide assurance evidence. Auditors test vendor assessments, SOC reports, incident monitoring.

How Auditors Test ITGC Controls

Inquiry: Ask control owners how a control operates. Limited value because it describes intent, not actual execution.

Walkthrough: Follow a transaction or control activity end-to-end once. Provides process understanding but limited evidence of operating effectiveness.

Inspection: Review documentary evidence (logs, approvals, tickets, reconciliations). High value because it provides tangible proof of execution.

Observation: Watch a control execute in real-time (backup run, change deployment). Powerful for confirming controls work.

Reperformance: Re-execute a control independently to confirm it produces correct results.

System Configuration Review: Examine system settings to confirm they match policy (password policy, encryption, timeouts).

Risk-Based Sampling: Select a sample from the complete population based on risk and audit judgement. Sample size depends on risk, frequency, population, and confidence requirements.

Design Effectiveness: Is the control designed to prevent or detect the risk?

Operating Effectiveness: Did the control execute as designed throughout the audit period? Most audit work focuses on operating effectiveness—proving controls actually worked in practice.

ITGC Evidence Matrix

Common ITGC Audit Findings

• Terminated users not removed from systems promptly or removal delayed without documented reason.
• Access reviews completed without supporting evidence such as active user lists or manager approvals.
• Excessive privileged access granted (developers with database admin rights, QA with production access).
• Shared or generic accounts without individual audit trail.
• Developers able to promote their own changes without independent peer review or approver verification.
• Emergency changes approved only retrospectively, outside defined timeframes or without written approval.
• Incomplete user acceptance testing before production deployment.
• Backup restoration tested infrequently or failures not investigated.
• Failed jobs documented in logs but not investigated or resolved.
• SOC 2 reports obtained but not reviewed or findings not documented.
• Previous audit findings closed without remediation evidence.

ITGC Audit Report: Structure and Example

A complete ITGC audit report includes: Objective (scope of the audit), Scope (which systems and periods), Systems Reviewed (list), Audit Period (dates), Control Objectives (what controls were designed to achieve), Testing Performed (methods and approach), Evidence Reviewed (types of documentation examined), Exceptions (deviations or failures), Risk and Business Impact (what could go wrong), Severity (critical, high, medium, low), Management Response (remediation plan), Responsible Owner (who is accountable), and Target Remediation Date.

Fictional Example:

Condition: In a sample of 15 terminated employees, 4 retained production database query access 2–6 days after termination.

Risk: Terminated employees could access, query, or potentially modify customer data and financial information after their separation.

Cause: Termination notices were delayed reaching IT; automated deprovisioning failed for 2 employees.

Recommendation: Implement automated deprovisioning triggered by termination notice with completion within 4 hours; establish daily reconciliation of terminated employees to active access.

Management Response: Approved. Implementation target 30 June 2026.

ITGC Audit Preparation Checklist

• Confirm in-scope systems and document the business rationale for inclusion.
• Create or update the risk-control matrix covering all in-scope systems.
• Assign control owners and communicate testing timeline and evidence requirements.
• Verify all evidence populations are complete and accessible.
• Review current user access lists by system and identify inactive accounts.
• Obtain terminated employee records and verify deprovisioning documentation.
• Reconcile change control tickets to deployment logs to ensure all changes are tracked.
• Test backup restoration at least once during the audit period.
• Review failed-job logs and confirm investigations and resolutions were documented.
• Obtain latest SOC 2 Type II reports from all third-party service providers and document review.
• Prepare IT staff for auditor walkthroughs and interviews.

ITGC Remediation and Governance

Organisations benefit from security and IT governance leadership as they mature ITGC programs. A fractional compliance officer or security advisor can design control ownership structures, prioritise audit findings by business impact, improve evidence collection and documentation processes, coordinate SOC 2 or ISO 27001 readiness, establish continuous monitoring programs, and prepare organisations for future audits.

This approach is particularly useful for payment businesses, fintechs, and service organisations where IT general controls are foundational to customer trust and regulatory compliance, but internal resources may not justify a dedicated full-time security leader.

Final Takeaway

ITGC audits succeed when organisations view them as genuine assessments of system reliability and security, not compliance checkboxes. The difference between organisations that pass and those that fail is not the sophistication of technology; it is consistency of control execution and completeness of evidence. An access review is valuable only if it covers all active users, is performed timely, and has documented manager approval. A backup is valuable only if restoration is periodically tested and works. A change is reliable only if it was tested, approved, and deployed consistently. Organisations that prepare rigorously, assign clear ownership, automate where possible, and remediate findings promptly pass audits and build genuine resilience.

ComplyFactor Advisory Team

ComplyFactor is a specialist audit and compliance advisory firm working with payment processors, fintechs, service organisations and regulated businesses. Our advisors bring direct SOX, SOC 1 Type II and SOC 2 examination experience to every engagement.

Our services Book a consultation