Because SOC 2 is an attestation of whether controls worked in practice during the period under review, not just whether documentation existed. A written policy without evidence of consistent execution does not prove risk is controlled. Auditors test samples, compare them to the control attribute, and determine whether exceptions are isolated or systemic before forming an opinion.
Why auditors care about operating effectiveness
SOC 2 is built around whether controls actually function during the review period. That means an auditor is looking for evidence that the control was not only written, but consistently performed, with the expected result. A policy can support the control design, but it does not by itself show that people, systems, and approvals behaved the way the control says they should.
operating effectiveness matters because a control can be perfectly documented and still fail in practice. If the process was skipped, performed inconsistently, or performed too late to matter, the organisation may have a good policy and a weak control. That gap is exactly what SOC 2 testing is meant to surface.
How auditors test controls in practice
Auditors normally select samples from the period under review and trace each sample back to the stated control attribute. For example, if a control says approvals must occur before access is granted, the auditor checks whether the approval happened, whether it happened on time, and whether the evidence is complete enough to support the conclusion. The result is less about intention and more about repeatable execution.
That is why exceptions are analysed carefully. One missed step may be treated as isolated if the surrounding evidence shows the control otherwise worked consistently. Repeated misses, weak evidence, or unclear ownership suggest the control is not operating as described, which can turn a documentation issue into a reporting issue.
For a baseline view of the criteria auditors are working against, the SOC 2 Trust Services Criteria (AICPA) are the governing reference, and the testing model is also consistent with broader control validation expectations in NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls.
What this means for preparation and evidence
Teams should prepare for SOC 2 as an evidence exercise, not a document collection exercise. The strongest audit packages include dated artefacts that show the control ran as scheduled, who performed it, what system or process it affected, and what happened when an exception occurred. If the evidence is thin, retroactive, or assembled only after the audit begins, the control may be viewed as weak even when the underlying policy is sound.
Practitioners should also remember that policy quality and control effectiveness are related but not interchangeable. A clear policy helps define the standard, but auditors will still ask whether the standard was followed in the real environment. In practice, that means ownership, review cadence, timestamps, approvals, logs, and exception handling matter more than policy language alone.
Where the control touches access, credentials, or secrets, the execution requirement becomes even more important because the risk of unused or unrevoked access grows quickly. NHI Mgmt Group’s Ultimate Guide to Non-Human Identities is useful background on why written rules are not enough when identities, keys, and rotations must be proven in use over time.
Risk and Threat Considerations
The main risk is assuming that a documented control equals a controlled environment. In SOC 2, that mistake can leave material gaps hidden until the auditor samples actual activity and finds that the control was skipped, delayed, or performed inconsistently. Where the control protects access, secrets, or change approvals, a paper-only posture can leave real exposure in place even though governance looks complete.
Failure mechanism: The control exists as a statement of intent, but the organisation cannot show repeated execution, timely evidence, or effective exception handling across the review period. Auditors then treat the gap as a failure of operating effectiveness rather than a mere documentation defect.
Impact: The finding can drive exceptions, remediation work, and delayed assurance because the organisation has not demonstrated that the control reduced risk in practice. In more sensitive environments, the same weakness can also indicate broader control drift across related processes.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV — Oversight | SOC 2 findings hinge on whether controls are overseen and evidenced in operation. |
| PR.AA — Identity Management, Authentication, and Access Control | Control effectiveness often depends on proving access controls worked during the period. | |
| DE.CM — Continuous Monitoring | Operating effectiveness is demonstrated through ongoing monitoring and review evidence. | |
| Recommendation — Monitor control execution evidence and escalate gaps between policy and practice. Validate that access-related controls operated consistently across sampled periods. Collect recurring evidence that controls executed as designed throughout the audit period. | ||
| CIS Controls v8 | 8 — Audit Log Management | Auditors often rely on logs and timestamps to confirm a control actually ran. |
| 5 — Account Management | Account and access controls commonly fail when documentation exists but execution is inconsistent. | |
| Recommendation — Preserve logs that prove the control executed, who acted, and when. Reconcile account actions to evidence that access decisions were enforced in practice. | ||
Practitioner Guidance
What to verify: Before fieldwork, verify that every in-scope control has evidence you can reproduce on demand, including date, owner, system, and outcome. If a control cannot be traced from policy to sample to artefact, assume the auditor will treat it as unproven.
Common mistake: Treating a policy review as sufficient because the wording is strong. In SOC 2 readiness, the hard question is whether the process happened consistently enough to support the trust criterion, not whether the procedure sounds reasonable.
Practitioner takeaway: The safest audit posture is one where policy, execution, and evidence all line up, because SOC 2 findings usually follow the weakest link in that chain.
Related resources from NHI Mgmt Group
- Why do SOC 2 programmes often fail at evidence rather than control design?
- How should security teams structure collaborative access control policy work in a shared browser-based IDE?
- How should security teams govern non-human identities for SOC 2 compliance?
- Why do ServiceNow tickets leak secrets so often?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
