Almost every IT audit, SOC report and SOX assessment rests on the same foundation, and it is not the flashy part. Before an auditor trusts the automated three-way match in your purchasing system, they check whether the right people can change that logic, whether changes are tested before they go live, and whether someone could quietly grant themselves access over the weekend. That foundation is IT general controls.

ITGC are unglamorous and they decide whether the rest of your control framework holds. Get them right and application controls can be relied upon. Get them wrong and an auditor treats every automated control as suspect, which turns a clean opinion into a long list of findings.

What are IT general controls?

IT general controls are the pervasive controls over an IT environment that make the systems and data behind financial reporting reliable. "General" is the key word: unlike an application control, which protects one specific process, an ITGC protects the environment that all the applications run in.

The logic auditors follow is simple. Automated application controls are only trustworthy if the environment around them is controlled. If anyone can change program logic without review, or grant themselves access without approval, then no automated control can be relied upon, because it could have been altered or bypassed. So ITGC get tested first, and everything else depends on them.

The four ITGC domains

Access to programs and data

Who can authenticate, and what can they do once inside. This is the largest domain and the one most likely to produce findings. It covers user provisioning and de-provisioning, privileged access, periodic access reviews, and segregation of duties. For SAP environments this is exactly where authorizations, SoD analysis and Firefighter / emergency access live.

Program changes

How changes to existing systems are authorized, tested, approved and moved to production, with development kept separate from production and no single person able to write and release a change unchecked. In SAP this maps directly to transport management and the controls around it.

Program development

How new systems and major implementations are governed, from requirements through testing to go-live. An S/4HANA migration is a program-development event, and the access and control design done during it is exactly what an auditor will later test.

Computer operations

The day-to-day running of the environment: job scheduling and monitoring, backup and recovery, and incident and problem management. Less glamorous still, and routinely where evidence is missing when the auditor asks.

ITGC versus application controls

The two are often confused. An application control is specific to a business process inside a system: a three-way match before an invoice is paid, a posting block on an unbalanced journal, a tolerance limit on a price change. An ITGC is the pervasive control over the environment those applications run in.

They are not alternatives; they are layers. Auditors test ITGC first precisely because application controls inherit their trustworthiness from the environment. A perfect three-way match means nothing if a developer can change the matching logic and move it to production alone.

How ITGC map to frameworks

The same underlying controls show up under different names depending on who is asking:

  • SOX: for US-listed companies and their subsidiaries, including Swiss entities in US-listed groups. ITGC over access, change and operations are a core part of the IT scope.
  • ISAE 3402 / SOC 1: for service organizations reporting on controls relevant to their clients' financial reporting. ITGC form the backbone of the report.
  • SOC 2: a broader set of Trust Services Criteria (security, availability, processing integrity, confidentiality, privacy), but access, change and operations controls sit at its core.
  • Swiss Code of Obligations: companies subject to an ordinary audit must maintain an internal control system, and IT general controls are part of it.

The practical upshot is that a well-designed set of ITGC serves several of these at once. You are not building a separate control framework for each acronym; you are building one and evidencing it against each.

Where ITGC and SAP security meet

For an organization running SAP, most of the ITGC that matter live in the SAP landscape. The access domain is SAP authorizations, segregation of duties and Firefighter. The change domain is SAP transport management. The development domain shows up most sharply during an S/4HANA migration. This is why SAP security and IT audit are the same conversation for us rather than two separate practices, and why our SAP security work and our IT audit work are joined at the hip.

The platform side matters here too. An access review is only meaningful if the underlying system is patched and monitored, which is the SAP cybersecurity layer beneath the controls an auditor tests.

Getting audit-ready without over-engineering

The most common mistake is building a control framework heavier than the organization needs, then failing to operate it. A control you design but do not run is worse than no control, because now you have a documented control that demonstrably fails.

Right-sizing means matching the framework to your actual size, risk and regulatory context. A mid-sized Swiss company does not need the control catalogue of a global bank. It needs the controls that address its real risks, evidenced in a way an auditor accepts, and operated consistently. That is the difference between passing an audit and living in permanent remediation.

How MTC helps

We assess IT general controls, remediate the gaps, and prepare organizations for SOX, ISAE 3402, SOC and Swiss statutory audits, with a particular strength where the controls live in SAP. Our background spans both IT audit and SAP security, so we design controls that are testable, evidenced and sized for your organization rather than copied from a template. On larger engagements we partner with leading global audit, risk and technology consulting firms while keeping a senior Swiss-based team accountable for the outcome.

Frequently Asked Questions

What are IT general controls (ITGC)?

IT general controls (ITGC) are the controls over an IT environment that make the systems and data supporting financial reporting reliable. They cover access to programs and data, program changes, program development, and computer operations. ITGC underpin application controls: if the general controls are weak, auditors cannot rely on the automated controls inside the applications.

What are the main ITGC domains?

There are four classic ITGC domains: access to programs and data (who can log in and what they can do, including segregation of duties); program changes (how changes to systems are authorized, tested and moved to production); program development (how new systems are built and implemented); and computer operations (job scheduling, backups, incident and problem management).

What is the difference between ITGC and application controls?

Application controls are specific to a business process inside an application, such as a three-way match in purchasing or a posting-block on an unbalanced journal. ITGC are the pervasive controls over the environment those applications run in. Auditors test ITGC first, because reliable application controls depend on a controlled environment; weak ITGC undermine the whole control framework.

How do ITGC relate to SOX and SOC reports?

ITGC are a core part of SOX IT compliance for listed companies and their subsidiaries, and they form the backbone of SOC 1 / ISAE 3402 reports for service organizations. SOC 2 covers a broader set of Trust Services Criteria (security, availability, confidentiality and more), but access, change and operations controls sit at its heart too.