ITGC vs ITAC: where general and application controls diverge

At a glance

What this is: This is a comparison of IT general controls and IT application controls, with the key finding that they address different layers of IT governance and are often used together.

Why it matters: It matters because IAM, audit and security teams need to separate infrastructure control design from application control design when assessing access, segregation of duties and compliance coverage.

👉 Read Zluri's comparison of ITGC vs ITAC for audit and access control

Context

IT general controls and IT application controls are often discussed together, but they solve different governance problems. ITGCs protect the wider IT environment, while ITACs focus on controls inside specific applications. For IAM and audit teams, the distinction matters because access design, segregation of duties and evidence collection are not the same at infrastructure level and application level.

The article is framed as a practical comparison for organisations deciding which control layer to prioritise, and it reflects a common audit question: whether the programme is trying to secure the estate as a whole or the transactions processed inside it. That distinction is relevant to both human access and non-human access, especially where service accounts or application accounts interact with regulated systems.

Key questions

Q: What is the difference between ITGC and ITAC in audit and access governance?

A: ITGC governs the broader IT environment, including access management, change management, patching, backup and physical security. ITAC governs controls inside a specific application, such as who can enter data, who can change it and whether outputs are accurate. Auditors use both to judge whether the environment is secure overall and whether transactions inside key systems remain reliable.

Q: When should organisations prioritise ITGC over ITAC?

A: Organisations should prioritise ITGC when the main risk is infrastructure-wide weakness, such as poor access governance, weak change control or unreliable recovery. ITAC becomes the priority when the risk sits inside a business-critical application, especially where records, approvals or data transfers must stay complete, accurate and segregated. Most mature programmes need both.

Q: What breaks when application controls do not cover service accounts and integrations?

A: Application controls break when non-human identities can write, move or approve data without the same review path as human users. Service accounts and tokens often bypass manual checks, so excessive privileges or unclear ownership can undermine segregation of duties and data integrity even when human access looks well managed.

Q: How should security teams prove that IT controls are working?

A: Security teams should prove control effectiveness with recurring tests that show the control operating, not just documented. That means checking access restrictions, change approvals, backup recovery, input validation and output integrity against real evidence. If the test results do not match the policy, the control exists on paper but not in practice.

Technical breakdown

ITGC scope across infrastructure and access layers

IT general controls are foundational controls that apply across systems, networks, servers and related infrastructure. They create the guardrails for how the environment is designed, changed, protected and recovered. In practice, ITGCs absorb access controls, patch management, change management, physical security and backup recovery into one broader governance layer. Their role is not to validate every transaction inside an application, but to make sure the platform that hosts those applications remains trustworthy. That is why ITGCs are usually the first control family auditors expect to see when assessing overall environment integrity.

Practical implication: map infrastructure-level access, change and recovery controls separately from application control evidence.

ITAC controls for input, processing and output

IT application controls operate inside a specific system and govern what happens to data as it is entered, processed and transferred. Input controls limit who can submit or alter data, processing controls validate that the data is complete and correct, and output controls help ensure data is delivered accurately and securely to the next system or user. These controls are narrower than ITGCs, but they are essential where financial records, regulated data or inter-application transfers must be reliable. They are also the controls auditors use to test whether the application itself preserves data integrity, not just whether the surrounding environment is secure.

Practical implication: test application controls with transaction-level evidence, not just infrastructure configuration reviews.

Why auditors assess both control types

Auditors review ITGCs and ITACs because one answers whether the broader environment is controlled, while the other answers whether the application is processing data correctly. A strong infrastructure control set can still leave gaps if application permissions allow excessive editing, weak segregation of duties or unvalidated output. Likewise, a tightly controlled application can still sit on an untrusted infrastructure if change management, patching or backup discipline are weak. The combined audit view is what reveals whether governance is layered or merely partial.

Practical implication: align audit evidence so infrastructure assurance and application assurance can be tested independently.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

ITGC and ITAC are complementary control layers, not interchangeable options. The article correctly shows that broad infrastructure controls and application-specific controls answer different governance questions. That distinction matters because access risk can exist in the estate even when the application logic is sound, and vice versa. Practitioners should treat the two as separate lines of assurance rather than a single control decision.

Application access controls become a governance problem when identity is not reconciled to function. The article's emphasis on authorised access, segregation of duties and data transfer control is really an identity control issue inside the application layer. If users or service accounts can edit records, move data or approve transactions without clear role separation, ITAC becomes a design label rather than an enforceable control. The implication is that access modelling must be tied to application workflow, not just generic RBAC.

Compliance pressure turns control selection into evidence design. The article ties ITGC and ITAC to SOX, GDPR, HIPAA and PCI DSS, which is a reminder that regulators care less about labels than about demonstrable control effectiveness. For audit and IAM leaders, the real issue is whether access, change and data handling evidence can prove control operation across both layers. Control selection should therefore be driven by what can be tested, not by what sounds broader.

For NHI governance, ITAC failures often expose the hidden account layer inside business applications. Service accounts, API tokens and integration identities can sit behind application functions that auditors see as simple user access. If those identities are over-privileged or poorly reviewed, application controls inherit the failure. Practitioners should therefore extend application control thinking to the non-human identities that execute the workflow behind the screen.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• Read NHI Lifecycle Management Guide for the provisioning, rotation and offboarding controls that usually sit behind application access issues.

What this signals

The governance signal for practitioners is clear: as applications become more interconnected, control testing must include the identities that operate between systems, not just the humans who approve access. With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files and CI/CD tools, the boundary between ITGC and ITAC is increasingly pierced by hidden machine access.

Control layering drift: when teams collapse infrastructure assurance and application assurance into one review cycle, they miss the distinct failure modes each layer creates. That drift usually shows up first in audit evidence, then in access exceptions and finally in transaction integrity problems.

For practitioners

• Separate infrastructure and application control evidence Build two evidence packs, one for ITGC and one for ITAC, so auditors can test platform governance and application integrity independently.
• Tie application permissions to business workflow Review who can enter, change, approve and export records inside each critical application, then align those permissions to segregation of duties.
• Include non-human identities in application reviews Check service accounts, tokens and integration identities that write to or move data between applications, because those identities can bypass human review paths.
• Validate control effectiveness with recurring testing Run periodic assessments that check whether access restrictions, change controls and output validation are actually operating as designed across both layers.

Key takeaways

• ITGC and ITAC solve different governance problems, so treating them as the same control family creates audit blind spots.
• Application integrity depends on both transaction controls and the identities that execute them, including service accounts and integrations.
• Practitioners should separate evidence, test both layers independently and include non-human identities in control reviews.

Key terms

• IT General Controls: Foundational controls that govern the wider IT environment, including access, change, patching, backup and physical security. They are designed to make systems and infrastructure trustworthy enough for business operations, but they do not validate the detailed correctness of every application transaction.
• IT Application Controls: Controls embedded in a specific application to govern data entry, processing and output. They focus on whether the application handles records accurately, completely and securely, especially where finance, compliance or inter-system data flow depends on reliable transaction handling.
• Segregation of Duties: A control principle that separates critical responsibilities so one identity cannot complete an entire high-risk process alone. In application governance, it reduces fraud and error by making sure entry, approval, modification and export actions are split across different roles or identities.
• Non-Human Identity: A digital identity used by software, services, workloads or integrations rather than a person. It may appear in application control paths as a service account, API token or integration identity, and it needs its own lifecycle, access review and accountability model.

Deepen your knowledge

ITGC and ITAC governance sit within the broader identity lifecycle and access control discipline covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is extending audit controls to service accounts and application identities, that foundation is directly relevant.

This post draws on content published by Zluri: Access Management ITGC vs ITAC, and what is the difference between the two? Read the original.