Who is accountable when SOC 2 evidence is incomplete?

Why This Matters for Security Teams

Incomplete SOC 2 evidence is not just an audit inconvenience; it is usually a sign that ownership, process, or system boundaries were never made explicit. The auditor can only assess what is demonstrated, while the organisation remains accountable for proving that controls actually operated. That gap becomes especially visible when logs are missing, approvals are informal, or offboarding records are scattered across tools.

For control owners, the real issue is not whether evidence exists somewhere, but whether it is complete, attributable, and time-bound. NHI-related evidence often fails for the same reason: secrets, service accounts, and API keys are managed across teams without a single accountable workflow. NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why evidence collection breaks down during audits. Current guidance in the NIST Cybersecurity Framework 2.0 points toward clear governance, repeatable execution, and measurable control outcomes rather than ad hoc proof gathering.

In practice, many security teams discover incomplete evidence only after the auditor asks for it, rather than through intentional control testing.

How It Works in Practice

Accountability for incomplete evidence should follow the control, not the calendar. The control owner is responsible for defining what evidence is required, the business sponsor is responsible for ensuring the control has operating support, and the team producing the evidence is responsible for keeping records complete and retrievable. That division matters because auditors test design and operation, but they do not own the control environment.

A workable process usually includes three layers:

• Control ownership: one named owner per control, with a documented backup and review cadence.
• Evidence specification: define exactly what must be retained, from which system, for what period, and in what format.
• Collection discipline: use recurring workflows for logs, approvals, access reviews, and offboarding artefacts rather than one-off exports.

For NHI-heavy environments, this often means mapping service account creation, secret rotation, and revocation events to specific control statements. The JetBrains GitHub plugin token exposure is a useful reminder that evidence failures often mirror operational failures: if secrets are not governed, proof of governance will also be weak. NIST CSF 2.0 reinforces this by treating governance as part of the control system, not an afterthought. The practical standard is simple: if an event cannot be traced, then the control was not demonstrably operating.

These controls tend to break down when evidence is distributed across ephemeral cloud workloads, CI/CD systems, and unmanaged spreadsheets because no single system can prove completeness end to end.

Common Variations and Edge Cases

Tighter evidence controls often increase operational overhead, requiring organisations to balance audit readiness against the friction of collecting, validating, and storing records.

There is no universal standard for every evidence type, so teams should separate mandatory evidence from supporting artefacts. Current guidance suggests treating high-risk controls, such as privileged access, offboarding, and secret rotation, as non-negotiable evidence areas, while lower-risk items may be sampled. That is especially important where NHIs are involved, because the same workflow can generate many short-lived events that are easy to miss if ownership is unclear.

One common edge case is when engineering owns the system but compliance owns the audit response. That split can work only if evidence responsibilities are pre-assigned and tracked. Another is when a control is partially automated: automation does not remove accountability, it changes where evidence is generated and who must validate it. Where organisations have mature identity governance, audit gaps are often caught during internal review; where they do not, the first sign of failure is usually an auditor request that cannot be satisfied on time.

In environments with rapidly changing infrastructure, especially CI/CD-heavy platforms and temporary service accounts, evidence collection can lag behind reality because the control lifecycle moves faster than the documentation process.

Related resources from NHI Mgmt Group

• How should security teams prepare access evidence for a first SOC 2 audit?
• How should security teams govern non-human identities for SOC 2 compliance?
• Who is accountable when compliance evidence is incomplete?
• Who is accountable when a workflow platform compromise leads to downstream cloud or SaaS abuse?