ITGC certification exposes the access control gaps auditors find

At a glance

What this is: This is a Zluri explainer on ITGC certification, showing how access controls, change management, logging, and documentation support audit readiness across major compliance regimes.

Why it matters: It matters because IAM, PAM, and lifecycle teams are often the control owners auditors scrutinise first, especially when orphaned access or weak evidence undermines compliance.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Zluri's guide to ITGC certification and audit-ready controls

Context

ITGC certification is the formal validation layer around general IT controls such as access management, change control, logging, and operational evidence. In practice, it asks a simple question: can your organisation prove those controls work when auditors test them, not just when policies say they exist? For identity teams, that question lands directly on account lifecycle, privileged access, and evidence quality.

The article frames ITGC as a compliance readiness exercise across SOX, ISO 27001, HIPAA, and PCI DSS. That framing is useful, but the deeper governance issue is whether access reviews, deprovisioning, and change approvals are actually tied to the systems auditors sample. A control that cannot be evidenced is still a control failure. This is especially true when leaver access remains active or when review trails are incomplete.

Key questions

Q: What breaks when ITGC access controls are not tied to lifecycle management?

A: Access can remain active after employment ends, which means the control exists in policy but not in practice. That creates audit findings, weakens accountability, and leaves sensitive systems open to stale privileges. The fix is not just recertification. It is continuous reconciliation between HR events, entitlement data, and privileged access records.

Q: Why do ITGC audits focus so heavily on access reviews and logging?

A: Because access reviews show whether entitlements are still justified, while logging shows whether system activity can be traced and defended. Together, they prove that controls operate consistently rather than existing only as documents. When either is weak, auditors cannot rely on the control environment and the organisation loses evidence quality.

Q: How do organisations know if ITGC controls are actually working?

A: They test whether approvals, deprovisioning, and logging produce consistent evidence across the same systems auditors will sample. If the team cannot reproduce who had access, who approved it, and when it changed, the control is not functioning reliably. Effective ITGC is measured by traceability, not by policy language.

Q: Who is accountable when ITGC certification fails an audit?

A: Accountability usually sits with the control owners for identity, change management, and operations, not with auditors. Certification fails when evidence is missing, stale access remains unresolved, or approvals cannot be proved. That is why governance needs named owners, clear escalation paths, and a repeatable evidence chain across teams.

Technical breakdown

ITGC certification and access controls

IT General Controls are the foundational controls that govern who can access systems, how changes are approved, and how activity is logged. In identity programmes, this usually means joiner-mover-leaver processes, role assignment discipline, privileged access review, and audit trails that show access was authorised at the point of use. Certification does not create security by itself. It validates that the control design and control operation are both defensible under audit scrutiny. If access is too broad or reviews are informal, the issue is not just risk but evidence failure.

Practical implication: tie every high-risk access path to a named owner, a review cadence, and an auditable approval trail.

Change management, logging, and audit evidence

ITGC also depends on change management and logging because auditors want to see that system modifications are reviewed, approved, and traceable. Logging is not just detection telemetry. In certification terms, it becomes proof that changes were controlled and that sensitive actions can be reconstructed after the fact. This matters when teams rely on admin access, infrastructure automation, or outsourced operations. Without clear evidence of who changed what and why, the organisation may have the control in policy but not in practice.

Practical implication: standardise change tickets, approval artefacts, and log retention so control evidence survives the audit window.

Why orphaned access is an ITGC failure mode

The article’s example of ex-employees retaining access highlights a common ITGC failure mode. Orphaned accounts, stale service access, and delayed deprovisioning all break the assumption that access ends when business need ends. For auditors, that is more than a housekeeping issue. It shows that lifecycle governance is not integrated with control testing. In identity terms, the account may be inactive in business reality but still active in the systems that matter most.

Practical implication: reconcile leaver events against application entitlements and privileged accounts before the next certification cycle.

Threat narrative

Attacker objective: The objective is to keep unauthorised access alive long enough to reach sensitive systems or survive an audit sample.

1. entry: A former employee, contractor, or other leaver retains valid access to critical systems because deprovisioning did not happen or was not verified.
2. escalation: The orphaned account remains usable for sensitive applications, allowing access to data, configuration, or financial workflows beyond the intended employment window.
3. impact: Auditors find the stale access during certification testing, creating a compliance failure, possible penalties, and reputational damage.

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

ITGC certification is really access accountability under audit pressure. The article treats certification as a compliance milestone, but the identity reality is narrower and harsher. Auditors are testing whether access, change, and logging controls can be evidenced at the exact systems where risk concentrates. For practitioners, the lesson is that certification quality depends on lifecycle discipline, not policy volume.

Orphaned access is the control failure ITGC most often exposes. The article’s leaver example is the right one because it shows how access can outlive the business relationship that justified it. That failure is especially visible where access reviews are manual, delayed, or disconnected from HR and ticketing signals. Practitioners should treat stale access as a certification blocker, not just an IAM hygiene issue.

ITGC is a governance test of whether evidence and entitlement data stay in sync. A programme can have strong controls on paper and still fail if audit artefacts are incomplete, inconsistent, or difficult to reproduce. That makes identity operations part of financial and regulatory resilience, not a back-office support function. Practitioners should align access certification, logging, and change records as one evidence chain.

Access certification only works when the underlying lifecycle is real. Re-certifying a dormant or loosely governed account does not restore trust in the control environment. The deeper problem is that many organisations certify access states that were never fully reconciled to begin with. For IAM and IGA leaders, the implication is to validate control integrity before the audit window, not during it.

ITGC and NIST CSF both point to the same operational truth. If access, change, and recovery controls cannot be shown to operate consistently, the environment is not audit-ready. That is why the control owner model matters as much as the framework mapping. Practitioners should use certification findings to harden ownership, escalation, and evidence quality across the identity stack.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to GitGuardian & CyberArk.
• Top 10 NHI Issues places stale credentials and lifecycle gaps into the broader NHI governance picture, which is where audit-ready control design starts.

What this signals

Control evidence will matter more than control intent. If your programme cannot demonstrate access review completion, change approval traceability, and leaver offboarding across the same record set, ITGC findings will keep surfacing. The practical response is to treat evidence quality as a control objective, not a documentation task.

Orphaned access is a lifecycle problem before it is an audit problem. The teams most exposed are those running fragmented IAM, IGA, and PAM processes without a shared reconciliation model. Linking identity events to control verification is what keeps audit findings from becoming repeat incidents.

If you want a broader identity baseline, the Ultimate Guide to NHIs is useful for understanding how lifecycle, rotation, and access governance fit together across machine and service identities.

For practitioners

• Reconcile leaver access before certification testing Cross-check terminated users against application entitlements, privileged accounts, and shared access paths before auditors sample the environment.
• Standardise evidence for access and change controls Require each review, approval, and modification to produce a durable artefact that can be retraced during the audit window.
• Tie ITGC ownership to identity operations Assign explicit control owners for joiner-mover-leaver activity, privileged access, logging, and escalation so gaps do not drift between teams.
• Test whether controls survive audit sampling Run internal mock audits against the exact systems auditors are likely to inspect, then close any gaps in traceability or approvals.

Key takeaways

• ITGC certification is less about paperwork than proving that access, change, and logging controls actually work.
• The clearest failure mode in this article is orphaned access, which turns lifecycle gaps into audit findings.
• Teams should align identity operations, evidence production, and control ownership before auditors sample the environment.

Key terms

• IT General Controls: IT General Controls are the foundational processes that govern access, change, and operations in an IT environment. They are designed to keep systems reliable, auditable, and secure. In practice, they support evidence collection, accountability, and the repeatability auditors expect.
• Access Certification: Access certification is the formal review and approval of who still needs access to a system or dataset. It confirms that entitlements remain justified and that stale, excessive, or orphaned access is identified and removed. For identity teams, it is a control test as much as a governance process.
• Orphaned Account: An orphaned account is an identity that remains active after the person, contractor, or system that should own it is no longer present. It is a common failure mode in lifecycle governance because it preserves access without accountability. In audits, orphaned accounts often expose gaps in offboarding and entitlement reconciliation.
• Change Management: Change management is the controlled process for reviewing, approving, documenting, and validating system modifications. It exists to reduce unintended impact and create traceable evidence for auditors. In identity-heavy environments, it also helps prove that privilege changes and configuration updates were not made ad hoc.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.

This post draws on content published by Zluri: ITGC Certification: What It Is & How To Obtain It? Read the original.