TL;DR: ITGC certification is presented as a way to validate access, change management, logging, and documentation controls against SOX, ISO 27001, HIPAA, and PCI DSS expectations, according to Zluri. The real governance issue is not certification itself, but whether organisations can prove controls work before an audit exposes orphaned access and weak evidence chains.
At a glance
What this is: This article explains ITGC certification as a way to validate access, change management, logging, and documentation controls, with orphaned access and weak evidence chains highlighted as the audit risk auditors most often expose.
Why it matters: It matters because IAM and IGA teams are not being judged on policy intent but on whether access reviews, evidence, and control operation can stand up during SOX, ISO 27001, HIPAA, or PCI DSS scrutiny.
Context
ITGC certification sits in the governance layer of identity and control assurance. In practice, it is not a product or a one-time audit event, but a way of testing whether access controls, change controls, logging, and documentation are operating as intended when external auditors ask for proof.
The article's core message is that organisations often have controls on paper but still fail when evidence is incomplete or access is left uncleared. That makes ITGC relevant to human IAM, privileged access governance, and NHI lifecycle discipline wherever auditability and accountability matter.
Key questions
Q: What breaks when ITGC access reviews miss ex-employees or dormant accounts?
A: The review becomes evidence of process rather than evidence of control. If former employees or inactive accounts still have access, auditors can conclude that the organisation cannot prove revocation, ownership, or entitlement accuracy. That creates findings even when the review was performed, because the underlying identity state was never clean enough to certify.
Q: When do ITGC gaps turn into SOX or audit findings?
A: They become findings when the organisation cannot show that access, change, and logging controls operated consistently enough to support financial reporting. The issue is not only whether controls exist, but whether their evidence chain is complete, current, and credible during external review.
Q: What are the signs that ITGC or ITAC is failing?
A: Look for mismatches between the control layer and the evidence you can produce. Examples include applications processing data without validation, users retaining access that exceeds their role, changes reaching production without testing, or recovery plans that have not been exercised. Those signals usually mean the control exists on paper but not in the operational layer it was meant to govern.
Q: How should security teams run access reviews for non-human identities?
A: Security teams should scope reviews by risk pattern, assign every identity to an accountable owner, and require a documented decision for each item in scope. The workflow should allow direct remediation for obvious cases and owner follow-up for the rest. The goal is not just certification but a clean audit trail and a clear end state for each credential.
Technical breakdown
Why access reviews fail when identity hygiene is incomplete
Access reviews depend on a stable, current account population. If ex-employees, inactive accounts, or over-permissioned users remain in the environment, the review process becomes a paper exercise rather than a control. ITGC certification is therefore as much about identity hygiene as it is about the review itself, because auditors look for proof that access is removed, scoped, and revalidated on a repeatable basis. In IAM terms, the control is only effective when the identity inventory is accurate and the entitlement evidence is trustworthy.
Practical implication: reconcile identity inventories before each certification cycle so reviewers are not validating stale access states.
How change management becomes an audit control
Change management under ITGC is about traceability, not just approval workflows. The control has to show who requested a change, who approved it, what was altered, and whether the resulting system state matches the authorised change. Without that chain, logging becomes noisy data rather than evidence. This is why audit-ready change control is tightly linked to system integrity, especially in regulated environments where even small configuration changes can affect financial reporting, access enforcement, or data handling.
Practical implication: retain approval, implementation, and verification evidence for each high-impact system change.
Why logging and documentation carry compliance weight
Logging is only useful when it supports investigation and accountability. The article treats audit trails, reports, and documentation as proof that controls operate consistently over time, not as after-the-fact artefacts created for the auditor. That matters because compliance regimes often require organisations to demonstrate both design and operating effectiveness. In practice, logging, evidence retention, and process documentation form the bridge between technical control operation and an auditor's ability to validate it.
Practical implication: treat logs and evidence repositories as control assets that must be governed, retained, and retrievable.
Threat narrative
Attacker objective: The objective is to exploit weak control operation and poor evidence quality to preserve unauthorised or stale access long enough to create compliance and audit exposure.
- Entry occurs through unresolved access states, such as former employees or inactive accounts retaining access to critical systems.
- Escalation happens when over-permissive entitlements or weak review processes allow those accounts to keep touching sensitive systems and data.
- Impact is audit failure, compliance findings, financial penalties, or reputational damage when auditors cannot validate that controls worked as claimed.
NHI Mgmt Group analysis
ITGC certification is really an evidence problem disguised as a control problem: organisations rarely fail because they lack the language of access control, logging, or change management. They fail because they cannot prove those controls operated consistently when auditors asked. The practical implication is that certification readiness depends on evidence quality, not policy volume.
Orphaned access remains the clearest symptom of control drift: if former employees or dormant accounts still reach critical systems, the governance model has already lost integrity. This is not a theoretical gap. It is the point where access lifecycle management, access review cadence, and revocation discipline stop lining up. Practitioners should treat stale access as an operating-effectiveness failure, not a housekeeping issue.
ITGC exposes the weakness of audit-bound governance models: controls that only become visible during certification cycles are already too late to prevent findings. The article shows that continuous monitoring, documented approvals, and traceable change history are what make governance defensible. Teams should assume that if a control cannot be evidenced on demand, it will not survive audit scrutiny.
Evidence chain integrity: ITGC succeeds only when control operation, logging, and documentation can be linked back to a specific user, change, or entitlement without gaps. That linkage is what turns governance into something auditable rather than aspirational. Practitioners should build certification around provable continuity between access, change, and reporting states.
Human IAM and NHI lifecycle governance converge at the same failure point: both break when ownership, review, and offboarding are not tied to a current identity inventory. The article is framed around human access, but the underlying lesson applies to service accounts and other non-human identities as well. Practitioners should use the same evidence discipline across all identity types.
What this signals
ITGC turns identity governance into an evidence discipline: if access reviews, change approvals, and logs are not retained in a way auditors can trace, the control has not really been operationalised. That is why certification programmes should be judged on continuity of proof, not on policy completeness.
Teams should watch for a recurring pattern: controls that look strong in documentation but degrade in execution once ownership shifts or accounts go stale. In practice, the fastest way to improve audit outcomes is to treat revocation, approval, and evidence retention as one lifecycle.
Access certification and offboarding must be linked: the article's example of ex-employees retaining access shows why review cycles alone are insufficient. Organisations need revocation discipline that keeps the access state aligned with the current identity state across both human and non-human accounts.
For practitioners
- Reconcile access before certification cycles Validate that user, privileged, and application access lists match current HR and system records before external auditors review them. Remove ex-employees, dormant accounts, and any entitlement without an owner or business justification.
- Preserve a complete change evidence chain Capture request, approval, implementation, and post-change verification records for every material system change so auditors can trace control operation end to end.
- Audit logging for evidentiary completeness Verify that logs, reports, and review outputs are retained, searchable, and tied to specific access or change events rather than stored as isolated artefacts.
- Separate control design from operating effectiveness Test whether a control works in practice, not just whether it exists in policy documents, then document the test result and remediation path for gaps.
- Extend certification discipline to non-human identities Apply the same ownership, review, and offboarding expectations to service accounts, API keys, and other non-human credentials that carry standing access.
Key takeaways
- ITGC certification is less a formality than a test of whether access, change, and logging controls can be proved under audit.
- The article's example of ex-employees retaining access shows how quickly identity governance gaps turn into compliance exposure.
- The control that matters most is not the one written in policy, but the one whose operation can be evidenced end to end.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on access review, entitlement accuracy, and audit-ready authorisation evidence. |
| Recommendation — Enforce PR.AA-05 by reviewing entitlements regularly and removing stale or unowned access before certification. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The access-control gap discussed is over-permissioning and stale access to critical systems. |
| Recommendation — Apply AC-6 to minimise standing access and revoke unnecessary privileges before audit review. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article's ex-employee and dormant-account examples map directly to account lifecycle governance. |
| Recommendation — Use CIS-5 to inventory accounts, remove stale identities, and evidence account ownership. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article explicitly cites ex-employees retaining access, a classic offboarding failure for NHIs and human accounts. |
| NHI-05 — Overprivileged NHI | The article highlights over-permissive access that auditors can flag during certification reviews. | |
| Recommendation — Close offboarding gaps by revoking any identity that no longer has a current owner or business need. Reduce standing entitlements so each identity carries only the access needed for its current role. | ||
Key terms
- IT general controls: The foundational controls that support reliable systems, access, and change management across an enterprise application stack. In practice, ITGC determines whether auditors trust the environment enough to rely on higher-level business controls and transaction evidence.
- Operating Effectiveness: Operating effectiveness is the proof that a control works in real conditions, not just on paper. In DORA contexts, assessors look for logs, timestamps, approvals, and repeatable execution that show the control kept functioning over time.
- Access Certification: Access certification is the periodic review of whether an identity still needs its current entitlements. For NHIs, certification is only reliable when reviewers know the identity's owner, purpose, and expiry, otherwise stale machine access can persist long after the original use case has ended.
- Evidence Chain: An evidence chain is the connected sequence of records that proves an identity action was requested, approved, executed, and reconciled. Without that continuity, access governance becomes fragmented and auditors are left to infer intent from incomplete system data.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org