ITGC access audits fail when identity lifecycle evidence goes stale

At a glance

What this is: This is a practical guide to how ITGC audits test access controls, with emphasis on provisioning, recertification, de-provisioning, SoD, and service accounts.

Why it matters: It matters because access controls now span human users and NHIs, so IAM teams need evidence, ownership, and lifecycle triggers that survive audit sampling and operational churn.

👉 Read Zluri's practical checklist for ITGC access audit testing

Context

ITGC access control testing is really a test of whether identity change can be controlled, evidenced, and reproduced under audit conditions. In practice, that means the problem is less about policy language and more about whether provisioning, review, and de-provisioning produce retrievable proof for every identity in scope, including service accounts and other non-human identities.

The access problem is harder than other ITGC categories because identity is dynamic while audit evidence is static. Human moves, terminations, role changes, and ad hoc entitlements create a moving target, so access governance has to keep pace with lifecycle events rather than rely on a periodic spreadsheet checkpoint. That is the core failure mode this guide addresses.

Key questions

Q: How should security teams structure access reviews for ITGC audits?

A: They should review access on a defined cadence, scope the review to every in-scope application, and retain evidence of who reviewed what, what was flagged, and what action followed. Reviews that exist only in spreadsheets or email are difficult to defend because auditors need proof that the control actually ran, not a statement that it was intended to run.

Q: Why do service accounts complicate ITGC access testing?

A: Service accounts complicate testing because they often hold standing privilege, are omitted from human review cycles, and may have no clear business owner. That leaves auditors unable to verify whether access was necessary, approved, or removed on time. The fix is to treat non-human identities as first-class audit subjects, not as permanent exceptions.

Q: What breaks when de-provisioning depends on a manual ticket?

A: Manual ticket-based de-provisioning breaks when the ticket is delayed, missed, or detached from the actual termination event. The result is stale access that can persist after the employee or contractor has left or changed roles. Stronger controls tie removal to lifecycle triggers and preserve the actual removal date for audit evidence.

Q: Who is accountable when access findings recur across systems?

A: Accountability should be shared but not diffuse. IT owns the workflow, application owners own access decisions for their systems, HR owns lifecycle events, and internal audit tests whether the control operated as designed. If no one owns the handoff between lifecycle and access change, findings will keep recurring even when each team believes the other is responsible.

Technical breakdown

Why access controls dominate ITGC testing

Access controls attract more audit attention because they change continuously while many other ITGC domains are comparatively stable. A change record is bounded, a badge issue is rare, and a backup schedule is predictable. Access, by contrast, follows the identity lifecycle: joiners, movers, leavers, temporary grants, and role-based exceptions all alter the control surface. Auditors therefore test both the control design and its operating effectiveness, then ask whether evidence exists for each identity and application in scope. The practical reality is that the control is only as strong as the ability to prove what happened after the fact.

Practical implication: tie every access control to a retrievable evidence trail across the full identity lifecycle.

How auditors test provisioning, reviews, and de-provisioning

ITGC testing uses inquiry, inspection, and reperformance, but inspection and reperformance carry the most weight because they produce evidence rather than description. Provisioning is tested to confirm approval preceded access. Reviews are tested to confirm the review happened on schedule, covered the right systems, and produced follow-up actions for flagged access. De-provisioning is tested against the actual termination date, not just the ticket date, because delay creates stale access. Sampling is then used to determine whether the control operated consistently across the period, especially when frequency is high or risk is material.

Practical implication: build testable workflows that preserve approvals, timestamps, and removal dates without manual reconstruction.

Why service accounts and SoD belong in the same audit scope

Service accounts, API credentials, and other non-human identities often sit outside human access review processes even though they can hold broader standing privilege than employee accounts. That gap matters because auditors are not only checking who can access a system, but whether conflicting entitlements and orphaned access are controlled wherever they exist. Segregation of Duties is the same problem in a different form: one identity should not be able to complete incompatible steps in a high-risk process. If the audit boundary excludes NHIs, the control is incomplete by definition.

Practical implication: include non-human identities and SoD conflicts in the same recurring review scope as user access.

Threat narrative

Attacker objective: The objective is to preserve unauthorised or excessive access long enough to evade governance and create audit exposure, operational risk, or data access beyond the intended role.

1. Entry occurs when access is granted without documented approval or when a termination or role change fails to trigger de-provisioning, leaving stale access active.
2. Escalation happens when privilege creep accumulates over time or when conflicting entitlements remain in place across applications and identities.
3. Impact follows when auditors cannot verify who had access, who approved it, or when it was removed, turning weak evidence into a material control finding.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

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

NHI Mgmt Group analysis

Access audit failure is usually a lifecycle failure, not an evidence-formatting failure. The article shows that the recurring weakness is the handoff between HR events, provisioning, and removal, not the audit checklist itself. That is why access findings keep reappearing even when teams can produce paperwork. Practitioners should treat the lifecycle trigger as the control, not the spreadsheet that records it.

Non-human identities are already inside the audit perimeter whether teams acknowledge them or not. The guide correctly includes service accounts, API keys, and tokens because access risk does not disappear when the subject is a machine. That aligns with the NHI governance view in the Ultimate Guide to NHIs, where visibility and ownership are the foundation of auditability. The implication is simple: if NHIs are excluded, the control is not operating over the real environment.

Privilege creep is the named failure mode that explains most access findings. Access rarely fails in a single dramatic event; it fails as entitlements accumulate across role changes and exceptions. That is why the discipline must be framed around standing privilege and lifecycle drift, not just annual review completion. Practitioners should treat cumulative entitlement growth as the control gap to eliminate.

Evidence quality is now part of the control design. The guide makes clear that a control that cannot be re-performed or inspected quickly is functionally weak even if the policy is sound. In audit terms, that means evidence generation must be built into the workflow, not reconstructed later from email threads and spreadsheets. The implication is stronger governance through native evidence, not after-the-fact documentation.

ITGC access governance now overlaps with broader NHI governance and Zero Trust assumptions. Access reviews assume identities are known, stable, and reviewable on a fixed cadence, but modern environments include service accounts, API tokens, and other NHIs that outnumber humans and often hold persistent access. That makes the 52 NHI Breaches Analysis relevant here, because the same lack of lifecycle discipline shows up in both audit findings and breach patterns. Practitioners should design access governance around the full identity surface, not only the HR roster.

From our research:

• Access management, particularly user access reviews and privilege creep, remains the largest concentration of IT-related deficiencies and material weaknesses, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which helps explain why audit scope often misses the identities that matter most.
• That visibility gap sits inside a wider lifecycle problem, so practitioners should align access testing with the NHI Lifecycle Management Guide rather than rely on ad hoc review cycles.

What this signals

Access governance is becoming an identity lifecycle problem across both human and non-human estates. Teams that still treat access reviews as a periodic control check will keep missing the operational handoff where lifecycle events become entitlement changes. With 91.6% of secrets remaining valid five days after notification in our research, the broader lesson is that remediation windows are often longer than teams assume, and audit evidence should be tied to actual removal rather than process intent.

Privilege creep is now a structural audit risk, not a housekeeping issue. When access accumulates across roles, systems, and exceptions, the control surface expands faster than most GRC workflows can track. That is why practitioners should align access governance to the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 where identity scope includes NHIs as well as employees.

Discovery-first governance is the right operating model for audit readiness. If the inventory is incomplete, the review is incomplete, regardless of how polished the evidence package looks. The practical shift is to discover identities first, then govern access second, so that review scope matches the actual environment instead of an assumed one.

For practitioners

• Tie access controls to lifecycle triggers Connect provisioning and de-provisioning to HR and identity events so that role changes and terminations automatically create evidence of action, not just a reminder to act later.
• Separate privileged access from standard review cycles Review administrative and high-risk access on a tighter cadence than ordinary user access, and keep the evidence for who reviewed what, what was flagged, and what changed afterward.
• Inventory and review non-human identities with the same rigor Include service accounts, API credentials, and tokens in the audit population, assign named owners, and ensure each appears in recurring access reviews and de-provisioning checks.
• Define SoD conflicts as machine-checkable rules Encode incompatible entitlement pairs in a policy engine so recurring checks can identify conflicts across applications instead of relying on an auditor to catch them incidentally.
• Preserve evidence at the point of control execution Store approvals, review outcomes, timestamps, and removal dates in systems that can be inspected or reperformed without manual reconstruction from email or spreadsheets.

Key takeaways

• ITGC access testing fails most often where identity lifecycle events are not wired to access change, review, and removal.
• The scale of the problem is amplified by service accounts and privilege creep, which sit outside many human-only review processes.
• Practitioners should build evidence into the access workflow itself so auditors can inspect actual control execution, not reconstructed intent.

Key terms

• ITGC access control: An IT general control that governs who can access systems, data, and functions, and how that access is approved, reviewed, and removed. In audit terms, it must be demonstrable through evidence, not asserted through policy language alone.
• De-provisioning: The process of removing access when an identity no longer needs it, usually because of termination, role change, or contract end. For auditors, the key question is whether removal occurred on time and can be proven from system records.
• Privilege creep: The gradual accumulation of entitlements as an identity moves through roles, projects, or exceptions without old access being removed. It is a control failure because current access no longer matches business need, increasing audit findings and attack exposure.
• Non-human identity: A machine or software identity such as a service account, API key, token, certificate, or workload identity. In audit and governance contexts, NHIs require ownership, lifecycle control, and evidence just like human accounts, but they are often more persistent.

What's in the full article

Zluri's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step ITGC access testing flow for provisioning, review, de-provisioning, and SoD checks
• Detailed checklist items for evidence collection, ownership, and recurring audit sample selection
• Practical examples of access findings, including stale access, orphaned accounts, and privilege creep
• How the platform maps discovered identities to audit scope across human and non-human access

👉 Zluri's full guide includes the access checklist, testing sequence, and common findings practitioners can compare against their own controls.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.