SOC 2 common mistakes: the ten that produce exceptions, why they happen and how to prevent them

Why the same ten mistakes keep producing exceptions

An exception is the service auditor's record that a control did not operate as described for items in a sample, or was not designed to meet its criterion. Exceptions appear in the report your clients read, and enough against one criterion can turn an unqualified opinion into a qualified one. What they mean and how to respond is covered in our guide to SOC 2 exceptions and qualified opinions. This page is about their causes.

The causes cluster, and few are technical. Most sit in the gap between what a document says and what a team does on an ordinary Tuesday. The table gives all ten at a glance; the sections below explain each.

Mistakes 1 to 3: scope and control design

1. Over-scoping the trust services categories

Security is always in scope; the other four categories are optional. Teams add them because a questionnaire mentioned them or a fuller report looks stronger. Each brings criteria that need operating controls, and privacy reaches into notices, consent and data subject requests engineering rarely owns. The result is exceptions in a category no client asked for. Scope from client commitments: add a category when contracts need it and its controls have run long enough to be tested. Our SOC 2 scope guide covers how to decide.

2. A system description that does not match reality

The description is management's account of the system and its controls. It is often drafted early from stale diagrams and never revisited after a migration. The auditor tests against it, so every difference becomes an exception or a misstatement corrected under deadline pressure. Write it from the live environment, have engineering and operations leads sign off each section, and re-read it before the period and before fieldwork. What belongs in it is explained in the SOC 2 system description guide.

3. Controls written from a template no one operates

A purchased control set can look complete while describing a committee that does not exist. When the auditor asks the owner to walk through the control, the owner cannot, and no evidence exists because the activity never happened. Start from the tasks people already perform, name one owner per control and state the frequency and the record produced.

Mistakes 4 and 5: evidence and populations

4. Evidence gathered only at the end

A Type 2 auditor samples across the whole period. Teams that leave evidence to the month before fieldwork find the March access review unsaved, the screenshot undated or the ticket closed without approval. Recreated evidence is recognisable, and missing instances become exceptions. Run an evidence calendar from day one of the period: control, frequency, owner and record, collected as the control runs and checked monthly by someone other than the owner. Which records count is set out in SOC 2 policies and evidence.

5. Missing population completeness

Before sampling, the auditor asks for full populations: every joiner, leaver, change and incident in the period. It must be satisfied the list is complete and accurate, because a sample from an incomplete list proves nothing. Hand-kept spreadsheets and filtered exports with no record of how they were produced fail that test. Produce populations from the system of record, keep the query and the date it ran, and reconcile across sources, such as HR leavers against identity provider deactivations. How sampling works in fieldwork is covered in the SOC 2 examination guide.

Mistakes 6 and 7: the controls that fail most often in operation

6. Offboarding delays

Removing a leaver's access sounds simple, yet it is a frequent source of logical access exceptions. HR records the date, IT hears days later, and a SaaS tool outside single sign-on is never touched. The auditor compares leavers with deactivation dates and finds accounts active past your policy timeframe. Use a trigger from the HR system, a named owner for each application outside single sign-on and an access review that catches what the trigger missed.

7. Unapproved changes

Change controls require testing and approval before production. Under pressure, engineers merge their own pull requests, hotfixes ship overnight with the ticket raised next morning, or infrastructure is changed in the cloud console. Each appears as a change without prior approval. Let tooling enforce the rule: branch protection requiring a second reviewer, pipelines that reject changes without a linked record, and an emergency route that is documented and reviewed afterwards.

Mistakes 8 and 9: vendors and complementary controls

8. Vendor reports never reviewed

Most service organisations rely on subservice organisations such as cloud hosting providers, usually carved out of the report, so your controls depend on theirs and the vendor risk criteria expect you to monitor them. Teams file the provider's SOC 2 report unread, and the auditor finds no evidence of review. Keep a dated review of each critical vendor's report: period, opinion, exceptions and their impact on you, and the controls the vendor expects you to operate. See vendor management and subservice organisations.

9. Ignored CUECs and CSOCs

Complementary user entity controls (CUECs) are those your report says clients must operate for your controls to work. Complementary subservice organisation controls (CSOCs) are those your providers assume you operate. Both are often copied into the description unchecked. If your report tells clients to manage their own user access but the product offers no way to do so, or your provider assumes encryption you do not apply, the gap surfaces in testing or a client's review. Map each to an owner and an operating control, and list only CUECs your clients can realistically operate. See how to read a SOC 2 report.

Mistake 10: treating the report as a one-off

A report describes a period already past, and clients ask for the next one each year. Treat the first report as the finish line and owners move on, access reviews stop and the evidence calendar lapses; the next period opens with the gaps the first one closed, and a Type 1 meant to lead to a Type 2 is sometimes never followed. Plan the next period before fieldwork ends, keep monitoring running and report control health to management quarterly. See SOC 2 continuous monitoring and the annual cycle guide.

SOC 2 common mistakes: questions buyers ask