IT General Controls Explained: Four Areas Auditors Test

IT general controls (ITGCs) are the company-wide rules that keep your systems trustworthy: who can get in, how changes are made, how new systems are built, and how day-to-day operations are run. Auditors test them because every report, calculation and approval your systems produce is only as reliable as these controls. Below are the four areas and the evidence auditors ask for.

What are IT general controls, in plain language?

An ITGC is a control that applies to a whole technology environment rather than to one business process. A control that blocks an invoice over a set amount is an application control. A control that decides who may change that rule is a general control.

That split matters for auditors. If the general controls are weak, they cannot lean on the automated checks sitting on top of them, so they test more by hand. If the general controls are strong, they can often rely on a system to behave the same way every time.

The wider setting is internal control over financial reporting, usually shortened to ICFR. COSO, the body behind a widely used internal control framework, describes monitoring as "one of the five components of effective internal control" in its guidance on internal control. ITGCs are one of the places where that monitoring turns into something an auditor can inspect.

Which four areas do auditors test?

Audit teams commonly group ITGCs into four areas. The standards and firms do not all draw the lines in exactly the same place, so treat this as a practical map, not a legal definition.

Area	The question it answers	Typical evidence
Access to programs and data	Can only the right people get in, and do they only have the access they need?	User lists, joiner/mover/leaver records, access review sign-offs, privileged account lists
Program changes	Is every change to a live system requested, tested, approved and released by the right people?	Change tickets, test results, approval records, deployment logs
Program development	Are new systems and major upgrades built, tested and signed off before they go live?	Project plans, test and user acceptance records, data migration checks
Computer operations	Do jobs run, fail safely, get monitored and get backed up?	Job schedules and failure logs, backup reports, restore tests, incident tickets

Not every company has all four. A business that buys software as a service and never builds anything may have little to show under program development. A business with a large in-house platform will have a lot.

How does an access review fit in?

Access is often where findings turn up, and the access review is its centrepiece. In an access review, a system owner or manager checks a list of who can do what and confirms, or removes, each person's access. Auditors want proof that the review happened, that it covered the whole population, and that removals were actually carried out.

That topic has its own article, so I will keep it short here. For how to run one and how auditors test it, see auditing user access reviews.

What does a real audit finding look like?

A public example is worth more than a hypothetical one. In 2011, the US Government Accountability Office (GAO) published its report Management Report: Improvements Needed in SEC's Internal Controls and Accounting Procedures (GAO-11-348R, dated March 29, 2011). It covered the US Securities and Exchange Commission's own financial systems for fiscal year 2010.

In practice, the report reads like an ITGC checklist.

GAO described deficiencies in five areas: security management, access controls, configuration management, segregation of duties, and contingency planning. Many continued from earlier audits.
Recurring items included periodic access recertification, failing to follow the configuration management plan for change management, and untimely vulnerability remediation.
One new finding was segregation of duties: a human resource manager had both reviewer and validator access in the time and attendance system.
GAO tracked 22 open weaknesses from earlier audits. The SEC had closed 18 and 4 remained in progress. Configuration management accounted for 10 of the 22, with 7 completed and 3 in progress.

Two lessons stand out. First, these were ordinary control gaps, not exotic attacks. Second, findings came back year after year until the underlying process was fixed. An auditor who sees the same finding twice will not treat a one-off cleanup as a fix.

This is a government agency audited by a government auditor, not a PCAOB inspection of an audit firm or an SEC enforcement action against a listed company.

Which records will an ITGC auditor want to see?

Auditors ask for evidence that a control exists, and then for evidence that it ran. The second is harder.

Across the four areas, the requests tend to look like this.

A population. A full list, such as every user account, every change released in the period, every batch job that failed.
A sample from that list. The auditor picks items; you do not.
The record for each item. The ticket, the approval, the test result, the log line.
Proof the record is complete and accurate. Where did the list come from, and can you show it was not edited?

Delays often happen at step 4. Teams hand over a spreadsheet that someone built by hand. The auditor then has to test the spreadsheet before testing the control.

How do you prepare for an ITGC audit?

You prepare by making evidence a by-product of normal work, not a scramble before audit season.

Write down each control in one sentence. Who does what, how often, and what record it leaves.
Name an owner for every control. A role, not just a team.
Keep the evidence where the work happens. Change approvals in the ticketing tool, not in email.
Save the report parameters. If a list came from a system report, note the report name, the date range and the filters.
Test yourself first. Pick a sample of changes or leavers and see whether you could prove each one.
Close findings at the cause. If the same issue appears twice, the control design needs changing.

Going deeper: for security and IT teams

This section assumes you already work with audits or controls. The aim is to help you predict what an auditor will do with your evidence.

Design versus operating effectiveness. A control is tested twice. Design effectiveness asks whether the control, if performed as described, would prevent or detect the problem. Operating effectiveness asks whether it actually ran as designed, by the right person, across the period. A walkthrough tests design. A sample tests operation. A well-written procedure that nobody follows passes the first test and fails the second. The reverse happens too: people do the right thing, but nothing records it, so there is nothing to test.

Sampling. Auditors cannot read every record, so they select a sample from a complete population. Two things follow. The population must be complete, which is why they ask how the list was generated. And sample size depends on how often the control runs and on the auditor's risk assessment, so I will not quote a number here. Ask your auditor for their sampling approach early, and keep the full population for the period, not just the items you expect to be chosen.

Information produced by the entity (IPE) and system-generated reports. Most ITGC evidence is a report: a user list, a change log, a failed-job extract. Auditors treat the report itself as something to test, usually checking the source, the query or parameters, and the completeness and accuracy of the output. Practitioners often call this IPE. Keep the report definition under change control, save parameters with each run, and be ready to show the same report reproduced independently. The principle is straightforward: a report you cannot reproduce is weak evidence.

Change tickets. For program changes, the usual test is to take a list of changes released to production in the period, from the deployment tool or system logs rather than from the ticket system. The auditor then traces each one back to a ticket with a request, a test record and an approval by someone other than the developer. Changes that appear in the deployment log but not in the ticket system are the finding. Emergency changes need their own path, with approval recorded after the fact and a defined time limit. GAO's 2011 finding on failing to follow the configuration management plan is this problem in the public record.

Segregation of duties (SOD). SOD means no single person can both initiate and approve a sensitive action. The common ITGC cases are a developer with production access, a user who can raise and approve their own request, and an administrator who can alter the logs that record their actions. The GAO example above, one person holding both reviewer and validator access, is a clean case. Test it by comparing role or permission lists against a conflict matrix, and review privileged accounts separately.

Mapping to NIST SP 800-53. If you already use NIST SP 800-53 Rev. 5, three of its 20 control families line up with ITGC areas: Access Control (AC) with access to programs and data, Configuration Management (CM) with program changes, and Contingency Planning (CP) with the backup and recovery part of computer operations. Program development has a looser match, since system acquisition and development controls sit in a separate family. That is my mapping for convenience, not an official crosswalk. Note that NIST has marked Rev. 5 as withdrawn and superseded, so check which revision your organisation follows.

Questions to ask your auditor or your team. - Which systems are in scope, and why? - Which reports will you rely on, and how will you test them? - Which controls were tested last year, and what changed? - Is any control carried out by a service provider, and do we hold an assurance report for it?

Key takeaways

ITGCs are the controls over the environment that business systems run in. If they are weak, auditors cannot rely on automated checks.
A common grouping is four areas: access to programs and data, program changes, program development and computer operations.
Auditors test design first, then whether the control ran through the period.
Evidence is a complete population, a sample, the record for each item, and proof the report is accurate.
The 2011 GAO report on the SEC shows findings repeating when the process is not fixed.
Make evidence a by-product of normal work, and test yourself with a sample before the auditor does.

Sources

COSO, Guidance on internal control
US GAO, Management Report: Improvements Needed in SEC's Internal Controls and Accounting Procedures, GAO-11-348R, March 29, 2011
NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
Related article on this site, Auditing user access reviews