Topic starter
09/07/2026 3:23 pm
TL;DR: ITGC access control succeeds or fails on the underlying identity model, not on audit-day evidence, according to Zluri. The core issue is that role design, provisioning, recertification, and de-provisioning must work as a lifecycle system, or least privilege quietly degrades across human and non-human identities.
Editorial analysis by NHI Mgmt Group, based on content published by Zluri: “ITGC Access Controls: Models, Building Blocks, and a Rollout Plan”.
Key questions
Q: Where do ITGC access controls usually fail in practice?
A: They fail at the handoff points between role design, provisioning, recertification, and de-provisioning.
Q: Why do manual access revocation processes create ITGC risk?
A: Manual revocation depends on someone remembering to act after a termination or role change, across every application the person or account can reach.
Q: What are the signs that an access control model is drifting?
A: Common signals include role sprawl, repeated exceptions to the same role, excessive permissions that recur during reviews, and de-provisioning that depends on manual follow-up.
Practitioner guidance
- Define the access scope by identity type Include employees, contractors, service accounts, and other non-human identities in the programme boundary before role design starts.
- Redesign roles around actual job functions Replace historical access bundles and one-off exceptions with role definitions that map to real work patterns and approved entitlement sets.
- Automate lifecycle-triggered provisioning and de-provisioning Tie access grants and removals to HR or identity events so joins, moves, and leavers do not depend on manual tickets.
Bottom line: ITGC access control breaks down when organisations separate role design, provisioning, review, and removal into disconnected tasks instead of one lifecycle.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
09/07/2026 3:41 pm
ITGC access control is a lifecycle design problem, not an audit-day documentation problem. The article correctly shifts the discussion from evidence collection to operating model design. If provisioning, review, and revocation do not share the same identity model, audit testing merely exposes the gap instead of creating it. The practitioner conclusion is that ITGC access control should be designed as a control system, not a paperwork exercise.
A question worth separating out:
Q: Why do non-human identities need to be included in ITGC access testing?
A: Because machine identities carry the same audit risk as users when they touch material systems. If service accounts, tokens, and API credentials are excluded, the review covers only part of the access estate and cannot support a complete control conclusion.
👉 Read our full editorial: ITGC access controls need lifecycle design, not audit-day fixes