What breaks when SOC 2 controls are written for humans only?

What breaks in SOC 2 when controls assume only people act?

When a control model assumes every meaningful action is human, it cannot cleanly prove who authorised a machine, how that machine was reviewed, or when its access should be revoked. The result is not just weak documentation, it is a control design that leaves workload activity outside the audit trail the control is supposed to evidence.

Why human-only mappings fail the control narrative

SOC 2 is about demonstrating that controls operate consistently, not just stating that policy exists. If the underlying system includes services, automation, scripts, or APIs, a human-centric design often misstates the actual actor, the actual approval path, or the actual evidence source. That creates a gap between the written control and the real operating model, especially for SOC 2 Trust Services Criteria (AICPA).

In practice, the break shows up in three places: authorisation becomes ambiguous because the actor is not a person, review becomes incomplete because machine permissions are not recertified on the same cadence as users, and revocation becomes ineffective because non-human access is often embedded in deployments, pipelines, or integrations rather than held in a normal user account. Controls that only describe human access tend to miss those mechanics.

That also affects the evidence chain. An auditor can test a policy statement, but they still need traceable proof of issuance, approval, use, change, and removal. If the control owner cannot show that history for service credentials, workload identities, or automated configuration changes, the control may exist in theory but not in evidentiary form. In the SOC 2 context, that is a control operation problem, not just a wording problem.

Where the gap becomes visible in audits and operations

The most common failure mode is a control library that maps ownership to a named employee while the actual access path belongs to a deployment tool, cloud workload, or integration account. Reviewers may sign off on the business owner, but they are reviewing the wrong subject. Over time, that creates stale access, opaque exceptions, and unowned credentials that never enter normal certification cycles.

Another break appears during change management. If configuration changes are executed by automation, then the control needs a way to show what changed, which identity made the change, and what authorized it. Otherwise, the organisation can describe a change approval process while failing to evidence the machine-mediated path that actually altered production state. That is exactly the sort of mismatch that makes audit narratives brittle.

This is why broader control catalogues remain useful as supporting references for evidence expectations and control design, including NIST SP 800-53 Rev 5 Security and Privacy Controls and CIS Controls v8, which both reinforce account management, logging, and configuration control as operationally testable behaviours.

Risk and Threat Considerations

Human-only SOC 2 controls create a real exposure because they can conceal machine privilege, stale credentials, and unaudited automation paths. If a non-human actor can still authenticate or change configuration after the “human” control says it should be reviewed or revoked, the organisation has a trust gap that attackers, misconfigurations, or simple operational drift can exploit.

Failure mechanism: the control owner reviews the wrong identity class, so service accounts, workload identities, and embedded credentials bypass the intended approval, review, and offboarding path. Once that happens, the control cannot reliably detect overprivilege, unused access, or unauthorised change history.

Impact: audit evidence becomes incomplete, privilege exposure persists longer than intended, and the organisation may pass a policy check while still carrying unbounded machine access in production. The practical consequence is weaker assurance over access governance and a larger blast radius if a credential, pipeline, or integration is compromised.

Practitioner Guidance

What to verify: confirm that each control family names the actual actor type, not just the approving business owner. If the activity is executed by software, the evidence set should show identity issuance, entitlement review, and revocation for that software actor, not only for the human sponsor.

Common mistake: treating service credentials as a technical implementation detail outside the control narrative. That shortcut usually leaves a gap between the control statement and the evidence needed to prove it, especially when the same automation spans environments or rotates secrets outside normal user workflows.

What good looks like: the control can answer, for every machine-mediated action, who approved it, which identity performed it, what it could do, and how removal would be proven. If that cannot be shown quickly, the control is not yet written for the environment it actually protects.

Practitioner takeaway: In SOC 2, the test is not whether people are governed well, it is whether every actor that can create change has a complete proof path for authorisation, review, and revocation.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities for SOC 2 compliance?
• What is the difference between human IAM controls and NHI governance?
• When should organizations review access controls?
• What breaks when SOC 2 controls are documented but not operating consistently?