How do organisations know if ITGC controls are actually working?

Why This Matters for Security Teams

ITGC is only useful when it produces repeatable evidence that access, approvals, and logging behave the same way every time a control is sampled. A written policy can look complete while the actual workflow still allows stale access, skipped approvals, or logs that cannot be tied back to a specific change. NIST frames this as an operational outcome problem, not a documentation exercise, in the NIST Cybersecurity Framework 2.0.

This is where many teams overestimate control health. If provisioning happens in one tool, approvals in another, and evidence lives in email or chat, the control may exist on paper but fail under audit sampling. The practical question is whether the same person, system, and timestamp can be reconstructed consistently across the control lifecycle. NHIMG’s Ultimate Guide to NHIs — Standards is useful here because the same traceability gap that affects service accounts and API keys also shows up in ITGC evidence chains. In practice, many security teams encounter broken control evidence only after auditors ask for a sample, rather than through intentional control monitoring.

How It Works in Practice

Security teams determine whether ITGC controls are working by testing the control design and then testing operating effectiveness. Design asks whether the control should prevent or detect the risk. Operating effectiveness asks whether it actually did so for the sampled period, with evidence that can be reproduced from source systems. Current guidance suggests the evidence should come from the same systems that create the event, not from manually assembled screenshots or ad hoc exports.

For access controls, that usually means tracing a request from ticket to approval to provisioning record to actual entitlements in the target system. For deprovisioning, it means proving the user or non-human identity lost access when the workflow said it would, and that privileged tokens, API keys, or service accounts were removed or disabled as part of the same process. For logging, it means confirming that events are generated, retained, protected from tampering, and searchable enough to reconstruct what changed and who approved it. NHIMG’s Ultimate Guide to NHIs is especially relevant because ITGC failures often mirror NHI failures: excessive access persists, evidence is fragmented, and revocation is incomplete.

• Test a real sample from request to approval to implementation.
• Reconcile target-system entitlements against the approved access list.
• Confirm removals, revocations, and timestamps match the change record.
• Verify logs are complete enough to trace the control event end to end.

Frameworks help structure that testing, but they do not replace it. NIST CSF 2.0 can guide control objectives, while ITGC evidence must still be validated against source records and system state. These controls tend to break down when approvals are handled outside the workflow tool because evidence becomes fragmented across email, chat, and manual spreadsheet updates.

Common Variations and Edge Cases

Tighter evidence requirements often increase operational overhead, requiring organisations to balance auditability against delivery speed. That tradeoff is real, especially in environments where change volume is high or access is provisioned across many connected systems. Best practice is evolving, but the core rule remains the same: if the control cannot be sampled from authoritative records, it is not reliable enough for assurance.

Some environments introduce exceptions that need explicit handling. Emergency access may be approved after the fact, but the record still needs to show who authorised it, why it was necessary, and when it was removed. Automated provisioning can strengthen controls, yet it only helps if the workflow is locked to the system of record. For organisations with NHIs, the same logic applies to service accounts, CI/CD tokens, and API keys, where the evidence must show issuance, scope, and revocation. The NHIMG guide on standards is useful because it highlights that revocation and rotation failures often look like ITGC breakdowns during audit. There is no universal standard for this yet across every platform, so teams should document acceptable evidence sources and exceptions clearly.

Related resources from NHI Mgmt Group

• How can organisations know whether device posture controls are actually working?
• How do organisations know whether cloud access controls are actually working?
• How do organisations know if their IaC controls are actually working?
• How do organisations know whether LLM access controls are actually working?