TL;DR: Access management absorbs most ITGC audit effort because identities change continuously, evidence goes stale quickly, and auditors test both design and operating effectiveness across human and non-human identities, according to Zluri. That makes lifecycle-linked access controls, not periodic paperwork, the decisive audit boundary.
NHIMG editorial — based on content published by Zluri: Access Management ITGC Audit for Access, a practical checklist and testing guide
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Zluri's practical checklist for ITGC access audit testing →
ITGC access reviews and lifecycle evidence: what audit teams miss?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: ITGC access audits fail when identity lifecycle evidence goes stale