ITGC Audits and Identity: The Access Certification Evidence Auditors Accept

IT general controls (ITGC) test four identity control areas: how access is granted, how it is removed, how it is periodically reviewed, and how privileged access is controlled. If those fail, an auditor cannot rely on the application controls above them, and the scope of the entire audit widens. That is why identity is usually where an ITGC audit begins and where it most often produces findings.

The gap between having an identity governance platform and passing an ITGC audit is evidence. Every enterprise platform runs certification campaigns. Far fewer produce a complete, timestamped, independently reviewable package without someone assembling spreadsheets the week before fieldwork.

This is what auditors ask for, what satisfies them, and why most campaigns do not.

The four control areas

1. Access provisioning. Every grant traces to an approved request, and the approver had authority to approve it. The test is a sample of accounts: show the request, the approval, and that the access granted matches what was approved. Manual provisioning fails this routinely because the record lives in a ticket that does not match what was actually configured.

2. Access removal. Terminated users have no active access anywhere in scope, within the window your policy states. This is the most commonly failed control in any ITGC audit, and the reason is consistent: removal from single sign-on is treated as removal, while local accounts on appliances, vendor support logins, personal access tokens, and applications bought outside IT keep working. See deprovisioning.

3. Periodic access certification. Access is reviewed at a defined cadence by someone with the standing to judge it, and decisions are executed. Covered in detail below.

4. Privileged and emergency access. Privileged accounts have owners, elevation is approved and time-bound, and emergency (break-glass) use is logged and reviewed after the fact. See break-glass and zero standing privileges.

The evidence package auditors actually request

For each certification cycle, expect to produce five artifacts:

1. Scope derivation. The population of accounts and entitlements reviewed, and how that population was determined from an authoritative source. An auditor will test whether anything in scope was omitted.
2. Reviewer assignment and independence. Who reviewed what, and evidence they were not certifying their own access.
3. Decisions with timestamps. Approve or revoke per line item, recorded by the system rather than transcribed.
4. Proof of execution. That revocations actually happened in the target system, not just that the decision was recorded. This is the artifact most often missing, and it is the one that matters, because a recorded revocation with no downstream removal is a control that did nothing.
5. Exceptions with justification. Anything approved that would otherwise be a violation, with a named owner and a review date.

Why campaigns fail even when they complete

The number auditors increasingly look at is the revocation rate, not the completion rate. A campaign that closes at 100 percent completion with a 2 percent revocation rate across thousands of entitlements is evidence that reviewers approved without reading, and experienced auditors interpret it that way.

The mechanics of rubber-stamping are well understood:

• Reviewers see raw entitlement names such as APP_FIN_GL_RW_PROD, which mean nothing to a business manager.
• Approve is one click and revoke requires justification, so the low-effort path is approval.
• Campaigns run over hundreds of line items with a deadline, so speed wins.

Campaigns that produce genuine revocations do three things differently: translate entitlements into business language, show usage data alongside the grant ("not used in 180 days"), and make revocation the default action rather than the exception. See access certification.

The three findings that recur every year

Terminated users with active access. Almost always outside the identity provider. The fix is reconciliation against an authoritative owner across every in-scope system, not better SSO hygiene. Our secure offboarding checklist covers the systems that get missed.

Transfers that accumulated access. The mover case. Joiners are handled because someone is waiting to work and leavers because HR triggers it, but internal transfers add the new role's access and never remove the old, producing employees whose entitlements are an archaeology of their career. See joiner-mover-leaver.

Privileged accounts with no owner. Service accounts, application identities, and shared administrative credentials created for a project that ended. No owner means no review, no rotation, and no MFA. This is now the fastest-growing population in most estates. See non-human identity.

What to look for in a platform

All enterprise governance platforms run campaigns. For ITGC purposes the differentiators are narrower:

• Connector coverage into the in-scope systems, especially the ones without a modern API. Governance demos well against Active Directory and fails against the mainframe, the ERP, and the homegrown application. Ask each vendor to connect to your five hardest targets during the evaluation.
• Evidence export as a first-class feature, producing the five artifacts above without manual assembly.
• Closed-loop remediation, so the platform confirms the revocation executed in the target system rather than recording an intent.
• Segregation of duties enforced at request time, not discovered at audit. See segregation of duties.
• Non-human identity coverage, because those accounts have no manager to attest for them and are increasingly in scope.

The shortlist for enterprise scale is SailPoint, Saviynt, Omada, and One Identity, with Veza, C1, Lumos, and Zilla Security as cloud-native options that are often faster to deploy in SaaS-heavy estates. Compare them in SailPoint vs Saviynt and Omada vs Saviynt, and see the top identity governance platforms and access certification tools roundups.

Where SOX fits

For companies in scope of Sarbanes-Oxley, ITGCs support the internal control over financial reporting assessment, and PCAOB AS 2201 requires the auditor to test controls over systems affecting financial reporting. Identity is where that testing starts, because unauthorized access to a financial system undermines every control inside it, and segregation of duties over financial processes is the specific control SOX auditors focus on.

Adjacent frameworks test the same ground with different vocabulary. The AICPA Trust Services Criteria behind SOC 2 cover logical access under CC6. ISACA's COBIT is the reference control framework most ITGC programmes map to. NIST SP 800-53 AC family controls cover the same access management ground for federal and federal-adjacent systems.

Practical sequence

If you are preparing for a first ITGC audit, the order that produces the most evidence per unit of effort:

1. Establish the authoritative population. You cannot certify access you cannot enumerate.
2. Fix termination first. It is the most-failed control and the easiest to evidence once reconciliation exists.
3. Run one certification cycle on the highest-risk systems only, with usage data, and measure the revocation rate.
4. Assign owners to privileged and non-human accounts, with removal as the default for anything unowned.
5. Only then widen scope. A narrow campaign that produces real revocations is better evidence than a broad one that produces approvals.

Related reading

• Access review and certification best practices
• How to choose an IGA platform
• IAM audit preparation guide
• Identity controls for ISO 27001 and SOC 2