Most organizations have cybersecurity policies, user accounts, backups, software updates, and IT procedures. But during an audit, simply having these controls is not enough.
Auditors want to know whether the controls are properly designed, implemented, consistently followed, and supported by evidence.
This is where IT General Controls (ITGC) come in.
ITGC are the controls that support the overall IT environment. They cover areas such as user access, system changes, IT operations, backups, security administration, and system development. These controls are important because weaknesses in the IT environment can affect the reliability, security, and integrity of business systems and the information they process.
For organizations preparing for an IT audit, compliance assessment, ISO 27001 audit, or financial audit, understanding what auditors actually check can make the process much easier.
In this guide, we explain the major areas auditors typically examine, the evidence they may request, common gaps, and how organizations can prepare.
What Are IT General Controls?
IT General Controls are controls that apply across an organization’s IT environment rather than to one specific business transaction.
They help establish a controlled environment in which applications, systems, databases, networks, and IT operations can function securely and reliably.
Common ITGC areas include:
- User access management
- Privileged access management
- Joiner, mover, and leaver processes
- Password and authentication controls
- Change management
- IT operations
- Backup and recovery
- Incident management
- System development and deployment
- Security monitoring and logging
- IT policies and procedures
- Segregation of duties
- Vendor and third-party access
- Business continuity and disaster recovery
The exact scope depends on the organization, systems being audited, applicable requirements, and the risks relevant to the audit.
PCAOB guidance, for example, identifies IT general controls as important when automated controls or IT-dependent processes are relied upon. It also highlights risks such as unauthorized access, unauthorized system changes, excessive privileges, and loss of data.
Why Do Auditors Check ITGC?
An auditor is not simply asking:
“Does the company have cybersecurity controls?”
The more important questions are:
- Is the control designed appropriately?
- Has the control actually been implemented?
- Is it being performed consistently?
- Who performs it?
- How often is it performed?
- What evidence proves that it was performed?
- What happens when an exception is identified?
- Is the control reviewed by someone with appropriate responsibility?
- Can the organization demonstrate that the control worked during the audit period?
This distinction is important.
For example, a company may have a policy stating that employees’ access must be removed when they leave.
An auditor may then ask:
- Where is the policy?
- Who is responsible for disabling accounts?
- How quickly are accounts disabled?
- Is there a documented offboarding process?
- Can you provide examples from the audit period?
- Are former employees still active in any systems?
- Are privileged accounts handled differently?
- Is the process monitored?
The policy alone does not answer these questions.
What Auditors Actually Check During an ITGC Audit
1. User Access Management
User access is one of the most important areas of an ITGC review.
Auditors want to determine whether people have access to systems and data that is appropriate for their job responsibilities.
They may examine:
- User account lists
- Access request forms
- Manager approvals
- Role-based permissions
- Access provisioning procedures
- Access modification records
- Access removal records
- Periodic access reviews
- Dormant or inactive accounts
- Generic accounts
- Shared accounts
- Privileged accounts
- Administrative access
The auditor may compare an employee’s job role with the permissions assigned to that employee.
For example, an employee in the finance department may require access to accounting systems, but that does not automatically mean the employee should have administrator-level access to the underlying database.
The principle is simple:
Users should receive the access they need to perform their responsibilities, and unnecessary access should be restricted.
PCAOB guidance specifically identifies unauthorized access and excessive IT privileges as risks that auditors need to consider.
What Evidence Might an Auditor Request?
Common evidence includes:
- Current user access reports
- Access approval tickets
- Employee onboarding records
- Role and permission matrices
- User access review reports
- Screenshots or system-generated reports
- Account disablement records
- Administrative account lists
An access-control process is much easier to demonstrate when every access decision leaves a clear audit trail.
2. Joiner, Mover and Leaver Controls
Employee movement is another area auditors often examine.
Organizations should have a controlled process for:
Joiners: New employees receive the access required for their role.
Movers: Employees changing departments or responsibilities have their old permissions reviewed and adjusted.
Leavers: Employees who leave the organization have their system access removed.
The leaver process is particularly important.
An auditor may select a sample of former employees and compare:
- Employee termination date
- Last working date
- Account disablement date
- VPN access
- Email access
- Cloud application access
- Administrative access
- Remote access
The objective is to determine whether access was removed appropriately.
ISACA guidance on effective user access reviews also emphasizes formal onboarding and offboarding processes and timely removal of access when users leave an organization.
Common ITGC Finding
A company may disable an employee’s Microsoft 365 account but forget about:
- VPN access
- SaaS applications
- Cloud consoles
- ERP accounts
- Database accounts
- Remote desktop access
This creates a gap between the documented process and the actual IT environment.
3. Privileged Access
Administrative accounts receive additional attention because they can make significant changes to systems.
Auditors may review:
- Domain administrator accounts
- Database administrators
- Cloud administrators
- Firewall administrators
- Application administrators
- Root accounts
- Superuser accounts
They may ask:
- Who has privileged access?
- Why do they need it?
- Was the access approved?
- Is privileged access reviewed regularly?
- Are administrator accounts separate from normal user accounts?
- Are privileged activities logged?
- Can administrators change their own access?
- Is privileged access restricted using MFA?
The goal is to reduce the possibility that a single account can make unauthorized changes without appropriate oversight.
Segregation of duties is particularly relevant here. ISACA describes examples where the person developing code should not also be able to move that code into a higher environment without independent review.
4. Change Management
Change management is another major ITGC area.
Auditors want to know whether changes to production systems are controlled rather than being made informally.
Changes could include:
- Application updates
- Software releases
- Database changes
- Configuration changes
- Firewall rule changes
- Infrastructure changes
- Security patches
- ERP modifications
- Cloud configuration changes
An auditor may examine whether each significant change had:
- A documented change request
- A reason for the change
- Appropriate approval
- Testing
- Evidence of testing
- Approval for deployment
- Controlled deployment
- Post-implementation review where required
Example
Imagine a developer directly changes a production database because a business user reported an urgent issue.
The change may have solved the immediate problem, but the auditor may ask:
- Who approved it?
- Was the change tested?
- Who performed the testing?
- Who authorized deployment?
- Was the production change logged?
- Was there a rollback plan?
- Was emergency change management followed?
The problem is not necessarily that the change happened.
The problem is that there may be no evidence showing that the change was controlled.
PCAOB inspection findings have specifically highlighted deficiencies involving change-management testing, including whether populations selected for testing were complete and whether control owners appropriately reviewed changes.
5. Emergency Changes
Auditors understand that not every IT change can follow the normal process.
Critical incidents sometimes require immediate action.
That is why organizations should have an emergency change procedure.
Auditors may check whether emergency changes:
- Were properly classified
- Had appropriate authorization
- Were documented
- Were reviewed after implementation
- Were tested where practical
- Had evidence showing why normal procedures could not be followed
An emergency should not become a shortcut around change management.
6. IT Operations
ITGC audits also look at how day-to-day IT operations are managed.
This can include:
- System monitoring
- Job scheduling
- Batch processing
- Error monitoring
- System availability
- Incident handling
- Log monitoring
- Scheduled maintenance
- Capacity monitoring
- Operational procedures
The auditor wants evidence that important IT processes are actually being monitored and managed.
For example, if an automated financial process fails overnight, who identifies the failure?
What happens next?
Is the issue documented?
Is it investigated?
Is the failed process rerun?
Who confirms that the process completed successfully?
These operational controls can become particularly important when business processes depend heavily on automated systems.
PCAOB guidance describes computer operations controls as covering areas such as operational processing, identifying and correcting errors, and maintaining continuity of important data through backup and recovery procedures.
7. Backup and Recovery
Having backups is not the same as having an effective backup control.
Auditors may ask:
- What systems are backed up?
- How frequently are backups performed?
- Are backups automated?
- Are backup failures monitored?
- Where are backups stored?
- Are backups protected from unauthorized access?
- Are backups encrypted where appropriate?
- How long are backups retained?
- Are restore tests performed?
- When was the last successful restore test?
A common weakness is that organizations can show successful backup jobs but cannot demonstrate that the data has actually been restored successfully.
This creates an important distinction:
Backup evidence shows that data was copied. Restore testing provides evidence that the organization can actually recover it.
8. Disaster Recovery and Business Continuity
Auditors may also examine how an organization would respond if a critical IT system became unavailable.
Depending on the audit scope, this can include:
- Disaster recovery plans
- Business continuity plans
- Recovery procedures
- Recovery time objectives
- Recovery point objectives
- System dependencies
- Backup infrastructure
- Disaster recovery testing
- Test results
- Lessons learned
- Corrective actions
Auditors may ask whether the plan exists and whether it has actually been tested.
A document that has never been exercised provides less evidence of operational readiness than a documented plan supported by test results and corrective actions.
9. Incident Management
IT incidents should have a defined process for identification, recording, escalation, investigation, and closure.
Auditors may review:
- Incident management policy
- Incident tickets
- Severity classifications
- Escalation procedures
- Response timelines
- Investigation records
- Root-cause analysis
- Resolution evidence
- Closure approvals
- Lessons learned
They may also examine whether security incidents are separated from routine IT support tickets where necessary.
For example:
A printer not working is an IT issue.
A compromised administrator account is a security incident that may require escalation, investigation, evidence preservation, and management notification.
The organization should have a process that distinguishes between different levels and types of incidents.
10. Logging and Monitoring
Logs provide evidence of what happened inside an environment.
Auditors may look at whether critical systems generate logs and whether those logs are appropriately protected and reviewed.
Areas may include:
- User login activity
- Failed login attempts
- Administrator activity
- System changes
- Security events
- Application events
- Firewall activity
- Cloud activity
- Database activity
The auditor may ask:
- Which systems are logged?
- Who reviews the logs?
- How frequently?
- What happens when suspicious activity is identified?
- How long are logs retained?
- Can logs be modified by the same person being monitored?
The objective is not necessarily to collect every possible log.
The organization should be able to demonstrate that important activities are monitored based on the risks associated with the environment.
11. IT Policies and Procedures
Documentation is another area that can affect an ITGC audit.
Auditors may request policies covering areas such as:
- Information security
- Access control
- Passwords and authentication
- Change management
- Backup and recovery
- Incident management
- Acceptable use
- Remote access
- Asset management
- Business continuity
- Vendor management
But having policies is only the starting point.
Auditors may compare the written policy with what actually happens.
For example:
Policy says: User access is reviewed every quarter.
Evidence should show: Quarterly access reviews actually took place.
If the organization has a policy but cannot provide evidence that the process was performed, the auditor may identify a control weakness.
12. Asset Management
Auditors may also need to understand what technology the organization actually operates.
This can include:
- Servers
- Laptops
- Network devices
- Firewalls
- Databases
- Applications
- Cloud services
- Virtual machines
- Critical business systems
An asset inventory helps the organization identify what needs to be protected, monitored, patched, backed up, and included in the audit scope.
Without an accurate inventory, organizations may unintentionally leave systems outside their control framework.
13. Patch and Vulnerability Management
Depending on the scope of the audit, auditors may examine how security updates and vulnerabilities are managed.
They may ask:
- How are vulnerabilities identified?
- How are critical vulnerabilities prioritized?
- Who approves remediation?
- Are patches tested before deployment?
- How quickly are critical patches applied?
- Are exceptions documented?
- Are unsupported systems identified?
This area may overlap with broader cybersecurity assessments, but it can also be relevant to ITGC when system security and reliability affect the systems being audited.
Ambsan’s Security Assessment approach, for example, includes reviewing infrastructure, policies, access controls, configurations, vulnerabilities, and compliance requirements as part of a broader security review.
14. Segregation of Duties
Segregation of duties means critical responsibilities should not be concentrated in a way that allows one person to perform conflicting activities without appropriate oversight.
For IT, this can include separating:
- Development
- Testing
- Production deployment
- User access administration
- Access approval
- Security monitoring
- Change approval
For example, consider this process:
Developer → Testing → Independent approval → Production deployment
If the same person can write the code, approve the change, and deploy it directly into production, the organization may have a segregation-of-duties concern.
Auditors therefore examine roles and permissions together, rather than looking only at individual accounts.
15. Third-Party and Vendor Access
Many organizations rely on external vendors for:
- Cloud services
- IT support
- Software development
- Managed services
- ERP systems
- Security monitoring
- Infrastructure management
Auditors may therefore ask:
- Which vendors have access?
- What systems can they access?
- Why is access required?
- Is access time-limited?
- Is vendor access approved?
- Is vendor activity logged?
- Is access reviewed periodically?
- Is access removed when the contract ends?
Third-party access should not become an unmanaged path into the organization’s environment.
What Evidence Do Auditors Usually Want?
One of the biggest misconceptions about ITGC audits is that auditors only want policies.
In reality, auditors often need evidence that controls operated during the relevant period.
Depending on the audit scope, evidence may include:
| ITGC Area | Possible Evidence |
|---|---|
| User Access | User lists, approvals, access reviews |
| Privileged Access | Admin account reports, privileged access reviews |
| Joiners | Onboarding forms and access approvals |
| Leavers | Termination records and account disablement evidence |
| Change Management | Change tickets, approvals, testing records |
| Backup | Backup reports and failed-job reports |
| Recovery | Restore-test results |
| Incident Management | Incident tickets and investigation records |
| Logging | System logs and monitoring reports |
| IT Operations | Job schedules, monitoring reports, operational logs |
| Policies | Approved and current policies |
| Vulnerability Management | Scan reports and remediation records |
| Disaster Recovery | DR plans and test reports |
| Vendor Access | Vendor access lists and approvals |
The exact evidence requirements depend on the audit objective, systems, control framework, and auditor.
PCAOB standards emphasize that auditors consider the design of controls, whether controls have been implemented, and the evidence needed to assess their operation.
What Happens If a Control Exists but Has No Evidence?
This is one of the most common problems organizations face.
Suppose your IT team performs monthly access reviews.
However, nobody saves the review results.
During an audit, the organization says:
“We do this every month.”
The auditor may ask:
“Can you show us?”
If there is no evidence, it becomes difficult to demonstrate that the control actually operated during the relevant period.
This is why organizations should follow a simple principle:
If a control matters, document it. If you document it, retain the evidence.
The evidence should be:
- Relevant
- Complete
- Traceable
- Dated
- Protected from unauthorized modification
- Linked to the person or system responsible for the control
Common ITGC Gaps Auditors Find
Some recurring issues include:
1. Former employees still have active accounts
The organization has an offboarding process, but access removal is inconsistent.
2. Access reviews are performed but not documented
The IT team reviews access informally but cannot provide evidence.
3. Developers have direct production access
This can create segregation-of-duties and unauthorized-change risks.
4. Emergency changes bypass normal procedures
Emergency changes are made without adequate documentation or post-implementation review.
5. Backups are running but restores are never tested
Successful backup jobs are mistaken for recoverability.
6. Policies are outdated
The policy describes an old environment that no longer matches the organization’s technology or processes.
7. Privileged accounts are not reviewed
Administrative accounts remain active without periodic validation.
8. Vendor accounts remain active after projects end
Third-party access is not consistently removed.
9. Logs exist but nobody reviews them
The organization collects logs but cannot demonstrate effective monitoring.
10. Controls are performed inconsistently
The process exists, but different teams follow different procedures.
ITGC Audit: Design Effectiveness vs. Operating Effectiveness
This distinction is important.
Design Effectiveness
The auditor asks:
“If this control operates as designed, is it capable of addressing the identified risk?”
Example:
The company requires manager approval before a new employee receives access.
That may be an appropriately designed control.
Operating Effectiveness
The auditor asks:
“Did the control actually operate as intended during the relevant period?”
The auditor may therefore examine samples of access requests to determine whether the required approvals actually occurred.
A control can be well designed but poorly operated.
It can also be consistently performed but poorly designed.
A strong ITGC program needs both.
PCAOB guidance explicitly distinguishes evaluating the design of relevant controls from determining whether those controls have been implemented.
A Practical ITGC Audit Preparation Checklist
Before an audit, organizations can review the following:
Access Management
- Current user list is available
- Privileged users are identified
- Access approvals are documented
- Periodic access reviews are performed
- Former employees are removed promptly
- Shared accounts are controlled
- MFA is enabled where required
Change Management
- Changes are documented
- Changes receive appropriate approval
- Testing evidence is retained
- Production deployment is controlled
- Emergency changes are documented
- Developer and production responsibilities are appropriately separated
IT Operations
- Critical jobs are monitored
- Operational failures are documented
- Incidents are tracked
- Important logs are retained
- System monitoring responsibilities are defined
Backup and Recovery
- Critical systems are backed up
- Backup failures are monitored
- Backup retention is defined
- Restore tests are performed
- Recovery procedures are documented
Governance
- IT policies are current
- Policies are approved
- Responsibilities are clearly assigned
- Risk assessments are documented
- Third-party access is reviewed
- Audit evidence is retained
How to Prepare for an ITGC Audit
The best preparation does not start when the auditor sends the evidence request.
It starts by mapping:
Risk → Control → Owner → Frequency → Evidence
For example:
Risk: Former employees retain system access.
Control: IT disables accounts after receiving an approved employee termination notification.
Owner: IT administrator.
Frequency: Whenever an employee leaves.
Evidence: HR termination notification + account disablement record.
This approach makes it easier to identify missing controls and evidence before the audit begins.
Organizations can also perform an internal ITGC assessment first to identify gaps and prioritize remediation.
A broader IT security assessment can complement this work by examining infrastructure, applications, policies, access controls, configurations, vulnerabilities, and compliance requirements.
ITGC Is More Than an Audit Checklist
IT General Controls are sometimes treated as paperwork required to satisfy auditors.
They are more useful than that.
Effective ITGC helps organizations establish control over:
- Who can access systems
- What users can do
- Who can make system changes
- How changes are approved
- How systems are monitored
- How incidents are handled
- How data is backed up
- How systems are recovered
- How evidence is maintained
This becomes increasingly important as businesses depend on cloud platforms, SaaS applications, APIs, automated processes, remote access, and interconnected systems.
ISACA notes that ITGC considerations continue to evolve as organizations rely more heavily on internet-facing applications and APIs, while access management, change management, and IT operations remain important areas of control.
Final Thoughts
An ITGC audit is not simply about asking whether an organization has cybersecurity policies.
Auditors want to understand whether important IT controls are designed appropriately, implemented, consistently operated, and supported by reliable evidence.
The areas most likely to receive attention include access management, privileged access, employee onboarding and offboarding, change management, IT operations, backups, recovery, incident management, logging, segregation of duties, and third-party access.
The organizations that prepare effectively are usually the ones that can answer three questions clearly:
What is the risk?
What control addresses it?
What evidence proves that the control worked?
If your organization is preparing for an IT audit, compliance review, or internal control assessment, a structured IT audit can help identify gaps before they become audit findings.
Prepare Your IT Environment Before the Auditor Arrives
Ambsan provides IT Audit and Compliance services designed to help organizations assess their existing controls, identify gaps, and build a practical remediation roadmap.
Our broader cybersecurity services cover areas including IT audits, security assessments, VAPT, managed IT services, cybersecurity training, network security, data protection, endpoint security, identity security, and security management.
Want to understand where your IT controls stand today?
Talk to Ambsan’s Security Team and request an IT audit or security assessment.
You can also explore Ambsan’s Security Assessment service to understand how security controls, infrastructure, applications, policies, and compliance requirements can be assessed together.
Frequently Asked Questions
What are IT General Controls (ITGC)?
IT General Controls are controls that govern the overall IT environment. They commonly cover access management, change management, IT operations, security, backup and recovery, and related IT processes.
What does an ITGC auditor check?
An auditor may examine user access, privileged accounts, employee onboarding and offboarding, change management, IT operations, backups, recovery, incident management, logging, policies, segregation of duties, and third-party access.
What evidence is required for an ITGC audit?
Evidence depends on the audit scope but may include access reports, approvals, access reviews, change tickets, backup reports, restore-test results, incident records, policies, logs, and disaster recovery test results.
Is ITGC the same as a cybersecurity audit?
Not exactly. ITGC focuses on controls over the overall IT environment and may support financial reporting or other assurance objectives. A cybersecurity assessment can have a broader security focus, including vulnerabilities, configurations, threats, applications, infrastructure, and security controls.
How can a company prepare for an ITGC audit?
Start by identifying key risks, mapping each risk to a control, assigning control owners, defining how often controls operate, and retaining evidence that demonstrates the controls were performed.