SOC 2 exceptions — findings in the audit report that indicate a control was not suitably designed or not operating effectively — are more common than most technology companies expect when they begin their SOC 2 journey. They are also more consequential than many realise: a SOC 2 report with material exceptions is significantly less useful for client assurance purposes than a clean report, because exceptions tell your clients that controls they were relying on were not working as described.
Most exceptions are avoidable. They typically arise not from fundamental security failures but from preventable programme design and execution gaps.
Exception Type 1: Access Reviews That Don’t Actually Happen
Access reviews — periodic reviews of user access rights to confirm they remain appropriate — are a near-universal requirement in SOC 2’s Common Criteria. They are also one of the most commonly cited exception areas in SOC 2 audits. The failure mode is consistent: access reviews are scheduled and documented as a process, but during the audit period, they either do not happen on the defined schedule or are completed without the evidence that demonstrates they were genuinely conducted.
A reviewer who marks “approved” on an access list without reviewing individual accounts, or who approves access for users who have changed roles or left the organisation, has not conducted an access review — they have ticked a box. Auditors will sample access review evidence and test whether the review was substantive, not just whether a record exists.
Exception Type 2: Offboarding That Misses the Timeline
Timely removal of access when employees leave the organisation is a fundamental access control requirement. SOC 2 auditors sample access termination events to check that access was removed within the organisation’s defined timeline after departure. Organisations that have a defined 24-hour or next-business-day access removal policy but that actually process some terminations over several days — because the process depends on manual HR-to-IT communication that sometimes fails — will have exceptions in this area.
Exception Type 3: Undocumented or Inconsistent Change Management
Change management exceptions arise when the audit period includes changes to systems that were not processed through the documented change management procedure. This happens frequently in cloud-native organisations where infrastructure changes occur through automated pipelines with limited formal change ticket trails, or where “emergency” changes are made outside the normal process without the required retrospective documentation.
Exception Type 4: Vendor Risk Management Without Evidence
SOC 2 requires annual (or more frequent) assessment of significant vendors. Organisations that have a vendor risk management policy but limited evidence that vendor assessments were conducted during the audit period — no questionnaire responses on file, no documented risk reviews — will have exceptions in this area. The control must be documented in policy and evidenced in practice.
The Readiness Investment That Prevents Exceptions
Exceptions are primarily prevented by investing in the readiness phase: building controls correctly, testing them before the audit period begins, and establishing the evidence collection processes that will demonstrate consistent operation throughout the observation period. The readiness phase is not overhead — it is the work that produces a clean report.
At Bitsecura, our SOC 2 readiness programmes specifically focus on the controls that most frequently generate exceptions — designing and testing them correctly before the audit period begins, and building the evidence practices that demonstrate consistent operation. If you want a clean report, start with a rigorous readiness programme. Talk to us here.
Bitsecura provides SOC 2 readiness and compliance support services. Learn more about our SOC 2 services.