A common sign is that the auditor notes the control was not observed in operation because the triggering event never occurred. In that case, the report may explain why the control was not tested and may rely on confirmation from the engineering team or supporting documentation. That does not prove the control is ineffective, only that evidence was limited.
Why a Control Can Be “Not Fully Tested” Even When the Audit Is Complete
A SOC 2 control can be untested in practice when the audit period does not produce the condition needed to observe it, such as a rare exception, outage, approval event, or escalation path. In that case, the auditor may document the limitation, rely on corroborating evidence, and still conclude that the control design appears sound without having watched it operate end to end.
This is common in controls that only trigger on exceptions or low-frequency events. The absence of a live observation usually means the evidence base was narrower than ideal, not that the control failed. Practitioners should read the report carefully to separate “not observed” from “not effective.”
When you see this wording, the key question is whether the audit team had alternative evidence that supports the control’s operation, such as tickets, logs, approvals, screenshots, or engineering confirmations. If those artifacts are thin or indirect, the issue is evidence coverage, not necessarily control failure.
What the Audit Report Usually Gives Away
The clearest signal is explicit language that the control “was not observed in operation,” “was not tested due to no occurrences,” or “could not be fully tested because the triggering event did not occur.” That phrasing tells you the auditor encountered a scope or timing limitation rather than a broken process.
Another signal is a reliance statement that the test depended on management explanation, supporting documentation, or a sampled artifact instead of direct observation. That does not automatically weaken the report, but it does tell you the result rests more on corroboration than on real-world execution during the period.
A third clue is uneven evidence across the control population. If a control is meant to run repeatedly but the auditor could only validate it once, or only through a proxy, the report may still pass while leaving some uncertainty about consistency. That is the difference between one successful proof point and a fully exercised operating control.
- Look for phrases that limit the test to a single exception, event, or sample.
- Check whether the evidence was direct observation or secondary confirmation.
- Note any auditor comments about scope, timing, or unavailable activity.
What Practitioners Should Do Before Assuming the Control Is Fine
The most useful response is to determine whether the control is inherently event-driven or whether the audit period simply failed to capture normal operation. If the control only activates on rare exceptions, then the audit may need stronger retrospective evidence, better logging, or a longer review window to demonstrate operating effectiveness.
For controls that should occur regularly, weak testing can indicate a process gap, poor documentation, or insufficient monitoring. In those cases, the issue is not just audit evidence, it is whether the organization can prove the control is being performed consistently enough to be trusted.
What to verify: confirm whether the control owner can produce time-stamped evidence, a traceable workflow, and a clear explanation for why the trigger did or did not occur during the period. If the control depends on human memory or a one-off email, the audit trail is usually too fragile.
Decision rule: if the control is rare by design, improve the evidence model; if the control should be routine, treat missing direct testing as a cue to inspect process reliability, not just audit wording.
Practitioner takeaway: the sign to watch is not simply “not tested,” but whether the report leaves you with only narrative assurance instead of repeatable, time-bound evidence that the control would work when it matters.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | SOC 2 evidence gaps often hinge on whether access-related control activity was observable during the period. |
| DE.CM — Security Continuous Monitoring | Unobserved controls are often a monitoring and evidence-collection problem, not just a documentation issue. | |
| Recommendation — Review PR.AC evidence so you can prove the control operated when triggered. Strengthen DE.CM telemetry so control execution leaves a verifiable trail. | ||
| CIS Controls v8 | 8 — Audit Log Management | Audit-period testing depends on logs and records that prove the control ran as intended. |
| 6 — Access Control Management | Many SOC 2 controls under test involve approvals, reviews, or exceptions tied to access governance. | |
| Recommendation — Use Control 8 to retain evidence that a rare control actually executed. Apply Control 6 to preserve traceable approval and exception records. | ||
| NIST SP 800-63 | IAL — Identity Proofing | When auditor evidence relies on documented verification, assurance depends on the strength of recorded proofing steps. |
| AAL — Authenticator Assurance Level | If a control depends on authenticated actions, the evidence must show the asserted assurance level was actually used. | |
| Recommendation — Retain proofing records that let auditors verify the process without live observation. Capture authenticator evidence that demonstrates the required assurance level in operation. | ||
Related resources from NHI Mgmt Group
- How should security teams prove SOC 2 password controls during an audit?
- Who is accountable when an agentic system exposes control gaps during an audit?
- What breaks when SOC 2 teams rely on ad hoc evidence collection during the observation period?
- What are the signs that a SOC 2 program is not ready for a credible audit?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
