IT General Controls: Why Auditors Cannot Understand Financial Reporting Risk Without Understanding Technology
- John C. Blackshire, Jr.

- Aug 10
- 9 min read
ITGCs Are the Foundation Under the Controls Auditors Rely On
Modern organizations do not process their financial information on paper.
Revenue flows through applications. Payroll is calculated by systems. Vendors are maintained electronically. Journal entries are posted through ERP systems. Access rights determine who can create, approve, modify and delete information. Automated controls make thousands—or millions—of decisions without direct human intervention.
That creates a fundamental issue for auditors:
If you do not understand the controls over the technology, how much confidence can you place in the information produced by that technology?
This is why Information Technology General Controls (ITGCs) have become essential knowledge for internal auditors, external auditors, SOX professionals, compliance managers, finance professionals and IT personnel.
Corporate Compliance Seminars' Information Technology General Controls – ITGCs program is an intensive 8-CPE live webinar focused on the controls surrounding the IT environment, computer operations, access to programs and data, system development, program changes, continuity, monitoring and SOX compliance. The program also examines COBIT as a framework for understanding and evaluating IT controls.
What Are IT General Controls?
IT controls can broadly be considered in two categories:
IT General Controls and Application Controls.
Application controls operate within individual business applications and transaction processes. Examples might include:
Three-way matching of purchase orders, receiving information and invoices
Automated credit-limit checks
Edit checks
Required fields
Automated calculations
Duplicate invoice detection
System-enforced approval limits
ITGCs operate at a broader level and help establish whether the overall technology environment can be relied upon.
The CCS program focuses on ITGCs over areas including the IT environment, computer operations, access to programs and data, program development and program changes, while also discussing application controls related to transaction processing.
Think of ITGCs as the foundation underneath automated controls and electronic information.
If that foundation is weak, the auditor needs to question what is built on top of it.
The Auditor's Fundamental Question: Can I Trust the System?
Suppose Internal Audit is reviewing Accounts Payable.
Management explains that the ERP system prevents an employee from both creating a new vendor and approving payments to that vendor.
Excellent control.
But the auditor should keep asking questions:
Who can change the system configuration?
Who can change user permissions?
Who has administrator access?
Can privileged users bypass the segregation-of-duties rule?
Are access changes logged?
Who reviews those logs?
How are terminated employees removed?
How are emergency changes controlled?
The automated application control may be perfectly designed.
But if an administrator can disable it without detection, the underlying ITGC environment changes the auditor's assessment.
ITGCs and SOX Are Closely Connected
The relationship becomes especially important for organizations subject to the Sarbanes-Oxley Act.
Financial reporting today depends extensively on information technology.
That means controls over:
Access
System changes
Computer operations
Interfaces
Reports
Data
Automated calculations
can affect the reliability of financial reporting.
The CCS ITGC program specifically addresses SOX requirements, mapping IT controls to PCAOB and COBIT concepts, procedures for IT SOX compliance and testing approaches.
This is why SOX cannot realistically be viewed as an accounting-only compliance program.
Financial controls increasingly depend upon technology controls.
Access Controls: Who Can Do What?
Access management is one of the most important ITGC areas.
Every organization should be able to answer:
Who has access to what—and why?
Auditors should consider areas such as:
New-user provisioning
Terminated-user removal
Transferred employees
Privileged accounts
Administrator access
Service accounts
Password controls
Authentication
Periodic access reviews
Segregation of duties
A control can fail simply because access that was appropriate two years ago is no longer appropriate today.
Consider an employee who moves from Accounts Payable to Treasury.
Their new access may be completely appropriate.
But what happened to the old Accounts Payable access?
If nobody removed it, the employee may now possess capabilities that were never intended to coexist.
That is why periodic access certification matters.
Privileged Access Deserves Special Attention
Not all user accounts present equal risk.
A system administrator may have the ability to:
Create users
Reset passwords
Modify configurations
Access sensitive data
Change security settings
Install software
Modify logs
That means privileged access represents concentrated power.
Auditors should therefore ask:
Who has privileged access?
Why do they need it?
Who approved it?
Is access limited to what is necessary?
Are privileged activities logged?
Who reviews the logs?
Are emergency accounts controlled?
Are dormant privileged accounts removed?
The question is not merely whether management has an access policy.
The auditor needs to determine whether access is appropriately controlled in practice.
Change Management: Who Changed the System?
Organizations continually change technology.
They:
Install patches
Modify applications
Add functionality
Change configurations
Develop interfaces
Implement new systems
Correct defects
Every change introduces risk.
A poorly controlled change could:
Break an automated control
Alter a financial calculation
Create a security vulnerability
Corrupt data
Cause an outage
Allow unauthorized functionality
Effective change-management controls generally address questions such as:
Who requested the change?
Who approved it?
Who developed it?
Who tested it?
Who moved it into production?
Was testing successful?
Was segregation of duties maintained?
What happened when emergency changes were necessary?
The CCS program specifically covers program development, program changes and the systems life cycle within its ITGC curriculum.
Development and Production Should Not Be the Same Thing
Imagine a programmer who can:
Develop a software change.
Test the change.
Approve the change.
Move it into production.
That is efficient.
It is also a control problem.
The developer can potentially change production functionality without meaningful independent oversight.
The same internal-control concept auditors apply to Accounts Payable applies here:
Do not give one person incompatible responsibilities when those responsibilities allow that person to initiate and conceal an inappropriate action.
Segregation of duties is not just an accounting concept.
It is an ITGC concept.
Computer Operations Keep the Organization Running
Technology controls are not limited to cybersecurity.
Organizations depend on IT operations every day.
Relevant controls can involve:
Scheduled processing
Batch jobs
System interfaces
Backups
Job failures
Incident management
Capacity
Availability
Problem resolution
Suppose a nightly interface transfers transactions from a sales system into the general ledger.
What happens if the interface fails?
Does someone receive an alert?
Who investigates?
How does management determine whether every transaction eventually transferred?
A technology failure can become a financial reporting failure.
The auditor needs to understand that connection.
Disaster Recovery Is an Internal Control Issue
Organizations sometimes treat disaster recovery as an IT department responsibility.
It is actually an organizational resilience issue.
The CCS program specifically addresses continuity of IT services and the IT Disaster Recovery Plan as part of its curriculum.
Auditors should ask:
What systems are critical?
How long can each system be unavailable?
What data can the organization afford to lose?
Are backups maintained?
Are backups protected?
Can they actually be restored?
Has the disaster recovery plan been tested?
What happened during the last test?
Were deficiencies corrected?
A backup is useful only if it can be restored.
A disaster recovery plan is useful only if it can work.
IT Governance Comes Before Individual Controls
One of the strengths of the CCS course is that it begins with IT governance, rather than jumping immediately into passwords and access lists.
That is important.
IT governance asks broader questions:
Does IT understand organizational objectives?
Who establishes technology priorities?
How are IT risks identified?
Who owns those risks?
How are technology investments approved?
How is performance measured?
Who monitors cybersecurity?
How are major technology failures escalated?
Does the Board receive appropriate information?
An organization can have excellent password controls and still have poor IT governance.
Auditors need to see both levels.
COBIT Gives Auditors a Framework
The CCS program uses the COBIT Framework extensively as criteria for understanding
IT governance and controls and also compares COBIT with ITIL.
That provides auditors with something extremely valuable:
structure.
Without a framework, IT auditing can deteriorate into a collection of technical questions.
With a framework, the auditor can connect:
Organizational Objectives
↓
IT Objectives
↓
IT Risks
↓
Processes
↓
Controls
↓
Evidence
↓
Monitoring
That is much closer to the risk-based approach used elsewhere in modern auditing.
ITIL and COBIT Are Not the Same Thing
The CCS program also examines similarities and differences between ITIL and COBIT.
Auditors sometimes encounter both and assume they are interchangeable.
They are not.
At a high level, COBIT provides a governance and management framework for enterprise information and technology, while ITIL is heavily associated with IT service-management practices.
For an auditor, the important question is not:
“Which framework is better?”
The useful question is:
“What criteria are appropriate for evaluating this organization's technology risks, governance, processes and controls?”
That is the audit mindset.
ITGCs Are Also Fraud Controls
Weak technology controls do not merely create the possibility of accidental errors.
They can create opportunities for fraud.
Consider what someone with inappropriate system access might be able to do:
Create a fictitious vendor.
Change vendor banking information.
Modify an approval limit.
Post unauthorized journal entries.
Change payroll information.
Disable a control.
Alter logs.
Extract confidential information.
That is why the CCS learning objectives specifically include understanding how internal controls can manage risk and reduce fraud.
The fraud question should always be:
What could someone do if they intentionally attempted to circumvent this control?
That question frequently produces a very different audit.
ITGCs Affect Audit Evidence
Technology also affects the evidence auditors use.
Suppose the auditor receives a system-generated report containing every journal entry posted during the year.
The auditor intends to use that report as the population for testing.
Before selecting a sample, the auditor should determine whether the population can be relied upon.
Questions include:
Which system produced the report?
Which parameters were used?
Is every relevant ledger included?
Could records have been excluded?
Can users modify the report?
Were system changes controlled?
Are relevant access controls effective?
This creates an important connection between ITGCs and financial audit evidence.
If auditors cannot trust the system, they may not be able to trust the report generated by the system.
ITGCs and Application Controls Must Be Understood Together
A common mistake is to treat ITGCs and application controls as completely separate subjects.
They interact.
Suppose an ERP automatically rejects duplicate invoice numbers.
That is an application control.
But the auditor should consider:
Who can modify the duplicate-detection configuration?
Are changes approved?
Who has privileged access?
Is the configuration periodically reviewed?
The effectiveness of the application control can depend upon the ITGC environment supporting it.
The CCS program specifically distinguishes between ITGCs and application controls and discusses application controls in the context of transaction processing.
Monitoring Tells Management Whether IT Is Working
Management should not wait for Internal Audit to discover that technology controls have failed.
Organizations need monitoring.
The CCS curriculum includes a dedicated section on monitoring the effectiveness of IT and measuring IT performance.
Useful indicators might include:
Terminated accounts not removed timely
Failed backups
Unresolved critical vulnerabilities
Emergency changes
Failed batch jobs
Excessive privileged accounts
Security incidents
Unresolved access-review exceptions
Disaster recovery test failures
Aging IT audit findings
Good metrics provide management with early warning.
That allows management to manage the control environment rather than merely react to audit findings.
AI Makes Strong ITGCs Even More Important
Artificial intelligence adds another layer to the IT control environment.
Organizations are increasingly using AI to:
Analyze transactions
Generate reports
Write software
Assist employees
Summarize information
Make recommendations
Automate workflows
Auditors should begin asking familiar ITGC questions about unfamiliar technology:
Who can access the AI system?
What information can employees provide to it?
How are models and configurations changed?
Who approves AI applications?
How are outputs validated?
What data are retained?
How is confidential information protected?
How does management monitor AI use?
AI governance is new.
The underlying control concepts are not.
Access. Change. Operations. Security. Monitoring. Governance.
The same ITGC disciplines remain highly relevant.
Internal Auditors Cannot Say “I'm Not an IT Auditor” Anymore
There was a time when a financial or operational auditor could perform much of an audit while treating technology as somebody else's specialty.
That position is increasingly difficult to defend.
An auditor does not necessarily need to become:
A programmer
Network engineer
Database administrator
Cybersecurity engineer
But auditors should understand enough technology to recognize when technology affects the risk they are auditing.
A Procure-to-Pay auditor should understand how access affects vendor changes.
A payroll auditor should understand automated interfaces.
A financial auditor should understand system-generated reports.
A fraud auditor should understand privileged access.
An operational auditor should understand system availability.
Technology risk is business risk.
What Participants Will Learn
Corporate Compliance Seminars designed Information Technology General Controls – ITGCs to provide practical training rather than a purely technical discussion.
The program covers major topics including:
IT governance
Internal controls
IT risks
Balancing risks and controls
IT control frameworks
COBIT
ITIL
IT organization governance
Systems development life cycle
Computer operations
Access to programs and data
Program changes
IT service continuity
Disaster recovery
IT monitoring
SOX compliance
Mapping PCAOB and COBIT concepts
IT SOX procedures and testing
The objective is to help professionals understand how ITGCs support governance, risk management, compliance and reliable business information.
Who Should Attend?
The program is designed particularly for:
Internal Auditors
External Auditors
IT Auditors
IT Professionals
SOX Professionals
Compliance Managers
Risk Professionals
Finance Professionals
Professionals responsible for IT governance and controls
CCS specifically identifies IT professionals, auditors and compliance managers among the primary audiences for the course.
Information Technology General Controls – ITGCs: Event Details
The CCS program provides 8 NASBA-approved CPE credits in Auditing and Information Technology. It is offered as a live Group Internet-Based program over two days, generally Wednesday and Thursday, with sessions from 10:00 a.m. to 2:30 p.m. Central Time and a 30-minute lunch break each day. The program is classified at the Basic level, with no prerequisites or advance preparation required. CCS also offers customized private sessions for groups of two or more.
The Bottom Line: Follow the Technology to the Risk
Almost every major business process now depends on technology.
That means auditors need to follow the transaction beyond the traditional business process.
Ask:
Who has access?
Who can change the system?
Who approves those changes?
What happens when processing fails?
Can we trust the reports?
Can someone override the control?
Can the organization recover from a failure?
Who monitors whether all of this is actually working?
Those are ITGC questions.
But they are also business-risk, fraud-risk, financial-reporting and internal-control questions.
That is why IT General Controls should no longer be considered knowledge reserved for IT auditors.
Corporate Compliance Seminars' Information Technology General Controls – ITGCs program is designed to give auditors, IT professionals and compliance managers the practical foundation needed to understand these controls, evaluate the risks they address and determine whether the organization's technology environment can actually be relied upon.
Comments