SOC 2 evidence for non-human identity

Why SOC 2 behaves differently from a certification

An ISO certification audit largely asks whether a management system exists and functions. A SOC 2 Type II asks an auditor to test samples of control operation throughout a defined period and to report what they found, including what they found wrong.

For non-human identity this changes the work in three ways. Remediation has a lead time, a control implemented in month ten produces two months of evidence in a twelve-month period, and the report will say so. Evidence must survive, so retention policy becomes a control dependency. And exceptions are published rather than resolved privately, which means the report your customers read may name the gap.

The CC6 criteria, read for machine identities

Our practical reading. The Trust Services Criteria are written generically and do not name non-human identities; auditors apply them to whatever accesses the system.

The period problem

This is the failure most specific to SOC 2 and the least anticipated.

• Log retention shorter than the period. If cloud audit logs roll off at 90 days and the observation period is 12 months, the evidence for months one to nine does not exist. No amount of current-state excellence recovers it. Check retention against period length before the period starts.
• Controls implemented mid-period produce partial evidence and the report describes the timing. This is survivable and it is better to state the implementation date than to have the auditor discover it.
• Population completeness. The auditor tests a sample from a population you provide. If your population of non-human identities is incomplete, the sample is drawn from an incomplete list, and a later discovery that the population was wrong is a materially worse finding than an exception within a complete one.

Where exceptions actually come from

1. Terminated-owner service accounts. Auditors sample leavers and trace access. Machine identities the leaver created or owned are the classic hit, and they are hard to remediate retroactively because the evidence of who owned them is what is missing.
2. Credentials issued without an approval record under CC6.2. Common where engineers create service accounts as part of normal work and the approval exists only as a merged pull request nobody mapped to the criterion.
3. Access reviews with no non-human population. Same root cause as the ISO finding, and it surfaces here as an incomplete population rather than a missing control.
4. Non-expiring credentials with no documented exception. Not automatically an exception if registered and approved; reliably one if invisible.
5. Third-party integration grants outside the register under CC6.7.

Preparing for a Type II with NHI in scope

1. Set retention before the period begins. Longest single lever, and it costs money rather than effort, which makes it easy to get wrong late.
2. Establish the population and freeze how it is generated. An auditor will ask how the list was produced and whether the method could miss identities.
3. Make approval a system record, not a conversation. If credential creation runs through a request path, CC6.2 evidence is automatic. If it runs through engineers, you will be reconstructing it.
4. Wire the leaver process to the identity registry. This single change removes the most common exception category.
5. Run one review with the non-human population included early in the period, so the pattern is established rather than introduced late.
6. Register exceptions with an approver and an expiry. A documented, approved deviation is a governance decision. An undocumented one is a finding.

SOC 2 does not require perfection. It requires that what you claim is what happened, evidenced across the period, with deviations disclosed. Non-human identity fails that test more often than any other access domain, and almost always for evidential rather than technical reasons.

Frequently asked questions

How does SOC 2 treat non-human identities?

The Trust Services Criteria are written generically and do not name them, so auditors apply the CC6 logical access criteria to whatever accesses the system, including service accounts, integrations and workloads. CC6.2 on registration and authorisation before issuing credentials, and CC6.3 on modifying and removing access, are where non-human identities land hardest, because both require records that most organisations generate only for human accounts.

What is the difference between SOC 2 Type I and Type II for machine identity?

Type I assesses control design at a point in time; Type II tests whether controls operated effectively across a period, typically six to twelve months. For non-human identity this is the decisive difference, because it converts the question from whether you have a control to whether you can evidence it operating throughout, which depends on log retention, population completeness and records generated at the time rather than reconstructed later.

What is the most common SOC 2 exception involving non-human identities?

Service accounts owned or created by terminated employees. Auditors sample leavers and trace their access, and machine identities attached to those leavers are the classic hit. They are hard to remediate retroactively because the missing evidence is precisely the record of who owned them, which is why wiring the leaver process to the identity registry removes more exceptions than any other single change.

Why does log retention matter for SOC 2 and non-human identity?

Because a Type II report covers a period. If cloud audit logs roll off at 90 days and the observation period is 12 months, evidence for the first nine months does not exist and no amount of current-state excellence recovers it. Retention should be checked against the intended period length before the period starts, since it is one of the few levers that cannot be pulled retroactively.

Is SOC 2 a certification?

No, it is an attestation. An independent auditor reports on what they tested and what they found, including exceptions, and there is no pass mark. That is why how exceptions are described matters: the report your customers read may name the gap, and stating an implementation date plainly is generally better than having the auditor discover the timing.