Why do non-human identities need to be included in ITGC access testing?

Why ITGC access testing must include non-human identities

ITGC testing is meant to tell auditors whether access to material systems is actually controlled. That includes service accounts, API credentials, tokens, and other machine identities because they can create, change, read, or transfer business data just like a person can. If they are omitted, the test only covers part of the control population and the conclusion is incomplete.

For a control test to be credible, the population must match the real access estate, not just the workforce directory. In practice, many of the highest-risk entitlements belong to non-human identities, which is why a human-only sample can look clean while leaving production access, integrations, and automated jobs untested.

When machine access is in scope, the testing question is not whether the account has a human owner, but whether it can reach a material system, whether that access is approved, and whether the access path is still necessary. That makes the test about effective control coverage, not account type.

Where the audit gap appears

Excluding non-human identities creates a false boundary around ITGC testing. The reviewer may see joiners, movers, and leavers, but miss the accounts that run batch jobs, sync data between platforms, call internal APIs, or hold privileged integration access. A control that ignores those accounts can still pass on paper while leaving material systems exposed.

This is especially important where credentials are long-lived, shared, embedded in code, or used by automation. Those access paths do not behave like a normal user lifecycle, so they are easy to overlook unless the review explicitly looks for them. NHIMG’s Service Account Security Guide and IAM and IGA Basics both reinforce that governance has to cover people and machines when access conclusions are being drawn.

The practical audit standard is completeness. If an integration user, API token, or workload identity can affect financial reporting, customer data, or core operations, then it belongs in the access population even if no employee logs into it interactively.

Because non-human access often sits outside traditional HR-driven processes, teams should also compare entitlement review results against discovered machine identities and privileged service accounts. NHIMG’s Top 10 NHI Issues and Identity Convergence Guide are useful references for understanding why separate silos routinely miss real access risk.

What strong ITGC testing looks at instead

Good testing starts with the protected asset and works backward to every identity that can reach it. That means listing human users, service accounts, application identities, API clients, tokens, and certificate-backed credentials where they have material system access. It also means validating approval, ownership, review frequency, and removal when the access is no longer needed.

The right test evidence is not just a spreadsheet of user accounts. Practitioners should expect inventory evidence, entitlement mapping, owner attestation, and proof that non-human accounts were reviewed using the same control logic as user accounts. NHIMG’s What are Non-Human Identities section is a good anchor for the kinds of identities that should appear in scope.

Testing also has to reflect how machine access fails in real environments. If a service account has no named owner, a token never expires, or an integration account can reach more systems than it needs, those are access-control findings even if the account is not a person’s login. For an auditor, the question is whether the organisation can demonstrate complete control over all material access paths, not whether those paths are human-operated.

When the estate includes OAuth apps, third-party integrations, or certificate-based service authentication, the test should trace from the access path to the business function it supports. That is the only way to tell whether the access is justified, still used, and reviewed on a realistic cycle.

Risk and Threat Considerations

When non-human identities are left out, the organisation may overstate the effectiveness of access controls while the most persistent and hardest-to-see credentials remain untouched. Those accounts are attractive because they often have broad system reach, weak ownership, and long-lived credentials that survive employee changes.

Failure mechanism: A partial review excludes machine accounts from the tested population, so stale, overprivileged, or orphaned access can persist without challenge and undermine the control conclusion.

Impact: Unauthorized data access, lateral movement, fraudulent system activity, and failed audit support can follow because the review did not cover the full access estate.

Practitioner Guidance

What to prioritise: Start with material systems and build the access population from discovered accounts, not from HR records alone. If an identity can authenticate to a production application, database, cloud workload, or privileged integration, it belongs in the review set.

What to verify: Confirm that each non-human identity has an owner, a business purpose, a defined review cadence, and an explicit revocation path. If any of those are missing, treat the access as incomplete governance rather than a minor exception.

Common mistake: Teams often test only interactive logins because those are easiest to sample. That produces a neat control narrative but misses the credentials that automation actually uses.

Practitioner takeaway: ITGC access testing is only defensible when it covers every identity that can exercise material system access, regardless of whether a human is the one pressing the button.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?