ITGC Audit for Access: A Practical Checklist and Testing Guide

Access controls carry more ITGC audit weight than any other category, because access changes every day and almost nothing else does.

Why access sits at the center of an ITGC audit

ITGC covers five categories: access controls, change management, program development, computer operations, and physical security. All five matter, but access is where most audit hours go, and where most findings originate. PCAOB inspection reports and public GRC data consistently show access management, particularly user access reviews and privilege creep, as the largest concentration of IT-related deficiencies and material weaknesses.

The reason is structural, not incidental. Change management and program development are event-driven and gate-kept: a change follows a defined pipeline of request, test, approve, deploy, and gets tested as a sample of discrete events. Computer operations and physical security are closer to static infrastructure: backups run on automated schedules, badges get issued rarely, and testing is often a fixed-cadence, yes-or-no configuration check.

Access controls behave differently. They track a dynamic identity lifecycle, constantly shifting with hiring, terminations, internal transfers, and ad-hoc permission requests.

Because access is tied to human behavior and organizational churn rather than static system architecture, it stays the most volatile variable in the environment. That volatility is also what makes it hard to keep clean, auditable evidence, and why auditors spend disproportionate time here. Every access audit has to verify a specific identity's access across every application it touches, not a finite set of code deployments or badge records.

That constant motion is exactly what makes access hard to control and easy to get wrong. A quarterly access review can be accurate on the day it runs and stale within a week. This guide focuses specifically on how ITGC audits test access, since that's the category where continuous, evidence-backed control makes the biggest difference to audit outcomes.

What an access-focused ITGC audit actually tests

An ITGC audit doesn't test whether an access policy sounds reasonable on paper. It tests whether the policy actually ran, consistently, for every identity and application in scope, and whether there's evidence to prove it.

Two things get evaluated for every access control:

• Design effectiveness. Would this control, as designed, actually prevent or detect the access risk it targets? A quarterly review that only covers half the applications in scope isn't designed to catch conflicts hiding in the other half.
• Operating effectiveness. Did the control actually run that way, consistently, for the full period under review? A control that worked in Q1 and Q3 but was skipped in Q2 has an operating effectiveness gap, even if the design was sound.

Auditors test both using a mix of methods. Inquiry means asking the access owner how provisioning or review works. Inspection means reviewing the actual sign-off records, tickets, or system logs. Reperformance means independently checking whether a specific terminated employee's access was actually revoked within the policy window. Inspection and reperformance carry the most weight, because they produce evidence rather than a description of intent.

The access control audit process

1. Scope the applications and identities. Not every system needs the same scrutiny. Scoping starts from which applications touch financial data, sensitive data, or feed a material process, then maps every identity type with access to those systems, including service accounts and non-human identities, not just employees.

2. Document the access model. For each in-scope system, document how provisioning works, who approves it, how often access gets reviewed, and how de-provisioning happens on termination or role change. This is also where Segregation of Duties conflicts get defined: which entitlement pairs shouldn't sit with the same identity.

3. Walk through the process once. Before formal testing, auditors typically trace one access event end to end, a new hire being provisioned, or an employee being de-provisioned, to confirm the documented process matches reality.

4. Sample and test. Provisioning and de-provisioning events get sampled across the period, not tested as a single instance. Access reviews get checked for evidence: who reviewed what, what was flagged, and what happened to flagged access afterward. Segregation of Duties gets tested by checking whether conflicting entitlement combinations were identified and resolved.

5. Evaluate and classify findings. Gaps get classified by severity: a control deficiency, a significant deficiency, or a material weakness, based on likelihood and potential impact, not just how many instances were found.

6. Remediate and re-test. Every finding needs an owner and a target date. For access-specific findings, this usually means fixing the trigger, an automated de-provisioning hook, a review cadence, an SoD policy, rather than just closing the one instance that got caught.

Sampling: why frequency changes the bar

Access controls that run constantly get sampled, not fully tested. A control that runs daily, like new-hire provisioning, might see dozens of sampled instances spread across the audit period. A control that runs quarterly, like a full access recertification, might see every instance tested, since there are only a handful in a year.

Sample size also scales with risk. Provisioning into a payroll system draws more scrutiny than provisioning into a low-risk internal tool, even if both run at the same frequency.

This is where manual, spreadsheet-based access tracking tends to fail under testing. A review that's documented for two of the last four quarters doesn't just leave two gaps. It raises the question of whether the control operated consistently at all, which is often enough to escalate a minor issue into a more serious finding.

Access control checklist

Each item below should have a named owner and a retrievable evidence trail, not a verbal confirmation that "we do this."

Provisioning

• New access requires documented approval before it's granted
• Approval routes to the correct role-based approver, not a generic catch-all
• Provisioning requests and their approvals are logged and retrievable by date

Recurring access reviews

• Access is reviewed on a defined, recurring schedule, typically quarterly for high-risk systems
• Reviews produce a record of who reviewed what, what was flagged, and what action followed
• Privileged and administrative access is reviewed separately, and more frequently, than standard user access
• Reviews cover every in-scope application, not just the core system that gets the most attention
• Flagged access that exceeds current role requirements is revoked, not left in place, keeping entitlements aligned with the Principle of Least Privilege

De-provisioning

• Terminated employees and contractors are de-provisioned within a defined window
• De-provisioning is tied to an HR or identity lifecycle event, not solely to a manually filed ticket
• Evidence exists showing the actual de-provisioning date against the termination date

Segregation of Duties

• Conflicting entitlement pairs are explicitly defined for high-risk processes
• Identities are evaluated against those definitions on a recurring basis, not only when an auditor's sample happens to catch one
• Conflicts are either resolved or formally exempted with a documented reason and an expiration date
• Exemptions are tracked and reviewed, not left open indefinitely

Non-human and service identities

• Service accounts and API credentials with access to in-scope systems are inventoried
• Ownership is assigned for each service account, not left unattributed
• Service account access is included in recurring reviews, not treated as a permanent exception

Who owns access findings

Access findings tend to sit at a boundary between teams, which is often why they linger. A few ownership patterns help avoid that.

• IT and access governance teams own provisioning workflows, review cadences, and de-provisioning triggers day to day.
• Application owners are accountable for who has access to their specific system, even when IT operates the underlying tooling.
• Internal audit tests access controls throughout the year, ahead of the external cycle, and tracks open findings to closure.
• HR owns the lifecycle events, hires, terminations, role changes, that should trigger access changes elsewhere.

The recurring failure isn't a missing owner. It's a gap at the handoff between HR's lifecycle event and IT's access change, or between an application owner's sense of who should have access and what IT's system actually shows. Naming one accountable owner per control, even for controls that span two teams, closes that gap before an auditor finds it first.

Common access findings in ITGC audits

A handful of patterns account for most access-related findings, regardless of company size or industry.

• Stale access, including orphaned accounts. An employee changed roles or left, but access wasn't removed, usually because de-provisioning depended on a manual step that got missed. Left unresolved long enough, this produces orphaned accounts: active credentials with no current business owner.
• Privilege creep. Access accumulates as employees change roles, without the old role's entitlements ever being removed. Over time, an identity ends up holding far more access than its current job requires, well past what the Principle of Least Privilege would allow.
• Segregation of Duties conflicts found reactively. A conflict only surfaces because an auditor's sample happened to catch it, not because a systematic check exists to catch it proactively.
• Inconsistent review coverage. Reviews are thorough for the core ERP but skipped or superficial for smaller SaaS tools that turn out to carry the same access risk.
• Evidence that exists but isn't retrievable. The review happened, but proving who reviewed what for a specific date takes days of manual digging through email threads or spreadsheets.
• Service accounts left out of scope. Reviews cover human users thoroughly and skip non-human identities entirely, even when those accounts hold broad access.

How Zluri supports access control testing

Most access governance tools start from a declared inventory: the systems someone connected or registered with them. They review, monitor, and enforce policy on exactly the applications and identities they were told about, and nothing else. That works fine until the audit scope turns out to be bigger than the declared inventory, which it almost always is.

Zluri starts from the opposite direction: discovery first, governance second. Before any review or policy runs, the platform builds the actual application and identity inventory from observed signals rather than from what anyone remembers connecting.

Discovery across eight parallel methods. IVIP pulls from SSO and identity providers, finance and expense systems, direct integrations with 300+ applications, browser extensions, CASBs, MDMs, HRMS, and directories, cross-referenced against a library of over 240,000 known applications. An app that evades one method, an AI writing tool adopted through a personal OAuth grant, for instance, tends to get caught by another, like the expense report that paid for it.

Full identity population, not just the human roster. The same discovery layer maps every identity on every discovered application, including service accounts, API keys, OAuth tokens, and AI agents alongside employees and contractors. Access reviews built only around the HR roster miss this population entirely, even though it typically outnumbers human identities and often holds broader standing access.

Access reviews scoped to match the audit boundary. Once the inventory exists, reviews can run at three levels: application-based, group-based, or user-based, so the review boundary lines up with whatever boundary the audit is actually testing, rather than forcing every review into a single, generic shape.

Segregation of Duties as a scheduled policy check, not a sampling exercise. Zluri's SoD capability, currently in early access within IGA, evaluates identities against defined conflicting-entitlement policies on a recurring basis. Violations are raised at the identity level, so one identity holding conflicting access across multiple accounts surfaces as a single finding. A policy can also span multiple applications, catching conflicts that live between systems, not just inside one.

De-provisioning tied to lifecycle events. Access removal ties to identity lifecycle triggers rather than depending solely on a manually filed ticket, closing the gap between a termination date and an actual de-provisioning date that shows up repeatedly as a finding.

Exemptions with built-in expiration. Where a conflict needs temporary allowance, exemptions require a documented reason and a maximum duration, with automatic reopening once the exemption expires, rather than an indefinite, undocumented exception.

Evidence as a byproduct, not a reconstruction. Every discovered application, every review outcome, and every policy decision is logged as the workflow runs, not assembled retroactively when an auditor asks. The result: when the question is "show me every system and identity with access to in-scope data," the answer comes from continuous discovery of the environment as it actually is, not a scope document describing how it used to look.

Because this is where Zluri's expertise is concentrated, access controls are treated as the highest-leverage part of an ITGC audit to get right, not one category among five to spread evenly thin.

Frequently Asked Questions

Why do access controls get more audit attention than other ITGC categories? Access changes constantly, as employees join, move roles, and leave, while change management, computer operations, and physical security tend to be more stable processes. That constant change makes access harder to keep current and more likely to produce findings.

What's the difference between a provisioning finding and a de-provisioning finding? A provisioning finding means access was granted without proper approval or beyond what a role should have. A de-provisioning finding means access wasn't removed in time after a termination or role change, letting stale access persist.

How often should access reviews happen to satisfy ITGC testing? Quarterly is the common baseline for high-risk systems, though the right cadence depends on the system's materiality and how quickly access changes for that population. What matters most to auditors is consistency: the same cadence, actually followed, every period.

Are service accounts included in ITGC access control testing? Yes. Non-human identities and service accounts with access to in-scope systems should be inventoried, owned, and reviewed the same way human user access is, since they carry the same risk if left unmanaged.

What evidence proves a Segregation of Duties control is operating effectively? A documented policy defining the conflicting entitlement pairs, a record showing identities were evaluated against that policy on a recurring basis, and evidence of how any violations found were resolved or formally exempted with a reason and expiration date.

What is privilege creep and why does it matter for ITGC audits? Privilege creep is the gradual accumulation of access as an employee changes roles, without the entitlements from the previous role ever being removed. Auditors flag it because it violates the Principle of Least Privilege and often produces the exact conflicting entitlement combinations that Segregation of Duties controls are meant to catch.

How is access-related deficiency data typically reported? PCAOB inspection reports and industry GRC benchmarking consistently point to access management, particularly user access reviews and privilege creep, as the largest source of IT-related deficiencies, more than change management, computer operations, or physical security combined.

Can access control evidence be reused across SOX, SOC 2, and ISO 27001? Largely yes. The underlying access review, provisioning, and de-provisioning evidence maps to similar access control requirements across these frameworks, even though the reporting format and audience differ.

‍