The Most Common SOC 2 Findings (and How to Fix Each One)

How SOC 2 findings work: exception vs. deficiency vs. qualified opinion

SOC 2 is governed by the AICPA Trust Services Criteria, codified in TSP section 100 (the 2017 criteria with revised points of focus, 2022). The examination itself is performed by a licensed CPA firm under the attestation standards in SSAE 18, specifically AT-C section 205 — note that AT-C section 320 governs SOC 1, not SOC 2. Only the Security category (the Common Criteria, CC1 through CC9) is mandatory; Availability, Processing Integrity, Confidentiality, and Privacy are added when in scope.

When an auditor tests a control and finds it did not operate as described, the observation is an exception (also called a deviation). A single exception is not the same as a failed control. Finding one prompts the auditor to do more testing — expand the sample, look for compensating controls — and only then judge whether the control’s design or operation is insufficient to meet the criterion. That broader conclusion is a deficiency. Enough deficiency on a criterion, and the auditor cannot issue a clean opinion on it.

A word of caution on vocabulary that competitors routinely get wrong: the ladder “exception → significant deficiency → material weakness” borrows from internal control over financial reporting (SOX and SOC 1 under AT-C section 320). In SOC 2 attestation practice, auditors most often speak of exceptions/deviations and of design versus operating-effectiveness deficiencies that drive a modified opinion. Keep the SOC 1 terms out of SOC 2 conversations unless you are actually discussing financial-reporting controls.

Most readers stop at three opinion types; there are four. The disclaimer of opinion is issued when the auditor cannot obtain sufficient appropriate evidence — the classic cause being a missing or inadequate management assertion — and it is worth knowing when you evaluate a vendor’s report.

Does one finding fail your SOC 2?

No. You cannot “fail” a SOC 2 audit the way you fail a pass/fail exam. A report can be issued with noted exceptions and still be perfectly usable in enterprise procurement. What matters is whether an exception rises to a deficiency that changes the auditor’s opinion on a criterion from unqualified to qualified. There is no fixed count that flips the switch — the auditor performs additional sampling when an exception surfaces and weighs its materiality and pervasiveness. Aim for clean, but a well-explained exception with a corrective action plan is not a deal-killer.

The three buckets auditors actually use

Before the symptom-level list, it helps to see the parent framework auditors apply. Every SOC 2 finding falls into one of three buckets, and knowing which one you are facing tells you whether the fix is a document, a design change, or a track record you have to rebuild over time.

The last bucket is the one that stings in a Type II: a design fix can happen overnight, but proving operating effectiveness requires the corrected control to run cleanly for the rest of the observation period.

The 12 most common SOC 2 findings, ranked

The ranking below reflects what we observe across first-year Type II engagements at Auditsuisse; it is auditor experience, not a published statistic. Each finding names its exact Common Criteria identifier so you can trace it back to the full SOC 2 controls list by Trust Services Criteria.

1. Incomplete or unretained access reviews (CC6.2 / CC6.3)

This is the single most frequently documented finding we see. The review often was performed — someone eyeballed the user list — but no reviewer sign-off, population, or date was retained, so it is unpresentable and generates an exception even though the control operated. CC6.2 covers registration and authorization of new users; CC6.3 covers modification, removal, and periodic review of access. The 2017 TSC says access should be reviewed periodically; it does not mandate a frequency. Many organizations define quarterly reviews for privileged access in their own policy — that is common practice, not an AICPA rule.

2. Orphaned accounts for terminated or transferred employees (CC6.3)

An active account belonging to someone who left the company — caught in an access sample — is a near-universal qualifying-type finding under CC6.3, which expects timely removal of access relative to the termination event. Transfers are just as risky: the person kept their old team’s access on top of the new. The fix is to tie deprovisioning to the HRIS termination event so it is automatic, not a manual afterthought. See the CC6.3 access removal control for what evidence auditors expect.

3. Missing or inconsistent MFA on admin, production, VPN and CI/CD (CC6.1)

Here is a nuance most competitors get wrong: MFA is not named as a control in the 2017 TSC text. The criteria speak in terms of authentication under CC6.1’s points of focus; auditors evaluate MFA as how you implement that authentication, not as a criterion in its own right. In practice, MFA gaps surface on cloud root/admin accounts, production consoles, VPN, and CI/CD pipelines — the systems teams forget when they only enforce it on the primary SSO app. Enforce it everywhere through the identity provider and the finding disappears.

4. Excessive privilege / no least-privilege enforcement (CC6.1 / CC6.3)

Standing admin rights that nobody uses day-to-day are a classic least-privilege and segregation-of-duties (SoD) finding. Auditors look for a role-based model and evidence that access matches job function. Just-in-time elevation and periodic entitlement reviews are the durable fix.

5. Change-management approvals that bypass the ticketing system (CC8.1)

CC8.1 governs change management. The finding arises when an auditor traces a sample of production changes and cannot find authorization or peer review in the system of record — typically because the approval happened in a Slack thread or a verbal “ship it” rather than the ticket. The fix is to make the ticket-plus-pull-request approval a hard gate before deployment.

6. No evidence of testing or peer review before deployment (CC8.1)

Related to #5: direct-to-production pushes with no separation between the developer and the deployer. Branch protection with a mandatory reviewer, plus a test/CI gate, produces the evidence auditors sample.

7. Untested or undocumented incident response (CC7.3 / CC7.4)

CC7.3 and CC7.4 cover evaluating and responding to security events. A polished incident-response plan that was never exercised is a finding waiting to happen. Run at least one tabletop exercise in the period and document it — who participated, the scenario, and the lessons captured.

8. Unremediated vulnerabilities and stale pen-test findings (CC7.1)

CC7.1 covers vulnerability detection. Running scans is not enough; auditors want to see findings tracked to closure against an SLA. Open, aging penetration-test findings with no remediation record are a common exception. Tie each vulnerability to a ticket and a due date.

9. Weak vendor / subprocessor risk oversight (CC9.2)

CC9.2 covers vendor and business-partner risk. Findings arise when there is no vendor inventory, no risk-tiering, or no collection of subprocessors’ own SOC reports. Our guide to vendor management for SOC 2 compliance covers the subprocessor oversight gaps auditors flag most.

10. Generic or unenforced policies not matching practice (CC1 / CC5)

Templated policies that describe controls the company does not actually operate are a CC1 (control environment) and CC5 (control activities) problem. Auditors test operating effectiveness against observed behavior, so a policy that overstates practice creates its own exception. Write the policy to match what you do.

11. Missing or inconsistent logging and monitoring (CC7.2)

CC7.2 covers monitoring for anomalies. Logs that are not centralized, not retained, or never reviewed generate findings. Centralize logging and alert on the events that matter.

12. Backups and BCP/DR not tested (Availability A1.2 / A1.3, if in scope)

If Availability is in scope, A1.2 and A1.3 expect tested recovery. Backups that are configured but whose restores are never verified are a common finding. Perform and document a restore test at least once in the period.

One more that reviewers frequently raise: complementary user entity controls (CUECs) and subservice-organization scoping. When your report relies on the customer to operate certain controls (CUECs) or carves out a subservice provider, gaps or omissions in how those are described become findings in their own right.

Access-control findings deep-dive

Because access control (CC6) produces the most findings, it deserves a closer look at exactly what the auditor asks for and how to prevent the exception with automation.

Notice the recurring theme: most access findings are really evidence findings. The control operated, but the proof was not captured. Treat reviewer sign-off, dates, and populations as first-class artifacts — retain reviewer sign-off as evidence rather than discovering at fieldwork that a completed review is unpresentable.

Change-management findings deep-dive: tracing one change

To understand CC8.1 findings, walk through how an auditor tests a single production change. They pick a change from your deployment history and try to reconstruct its full lifecycle from your system of record:

First, was there a ticket or work item describing the change and its rationale? Second, is there a pull request with a peer review from someone other than the author — i.e., separation between developer and approver? Third, is there evidence the change was tested before it shipped? Fourth, does the deployment record match the approved change? If any link is missing — the approval was a Slack thumbs-up, or the author merged their own PR — that sampled change is an exception. Multiply that across a sample and you have a CC8.1 deficiency.

The durable fix is to make the system enforce the workflow: branch protection requiring a non-author reviewer, a required CI check, and a deploy gate that ties back to the ticket. Then the evidence is generated automatically every time, and there is nothing to reconstruct at fieldwork.

Where findings actually live in the report

Buyers and first-time issuers are often surprised by where an exception physically appears. A SOC 2 Type II report has a consistent structure, and findings do not float freely — they live in a specific section.

Two things matter here. First, the exceptions themselves sit in Section 4, the test-results matrix — the heart of a Type II. Second, your written response to an exception goes in Section 5, “Other Information,” which is unaudited. That means you can explain and contextualize a finding, but the auditor does not vouch for your response. And to be precise about terminology: there is no “management letter” in a SOC 2 report — that is a financial-audit artifact. The management response lives in Section 5.

How findings differ in a Type I vs a Type II report

The same underlying gap shows up differently depending on the report type. This is worth understanding before you decide how findings differ between a Type I and Type II report.

This is why the Type II is harder to remediate mid-flight: fixing the control today does not erase the dates earlier in the period when it did not operate. Catching design gaps in a Type I or readiness pass first is the cheapest insurance.

Remediation quick-reference by tool

Most findings trace back to a specific system’s configuration. This table maps the tools you already run to the finding they typically produce and the concrete fix.

How to evaluate a vendor’s SOC 2 exceptions

If you are on the receiving end — a security or procurement lead reviewing a vendor’s report — a few exceptions are not an automatic rejection. Read Section 4 for the nature of each exception, then read the vendor’s response in Section 5. Ask: is the exception on a criterion that matters to your data? Did management acknowledge it and describe a fix? Is it a one-off deviation or a pattern across the period?

Also check the dates. A report covers a stated period, and there is usually a gap between the period-end date and the day you are reading it. A vendor covers that gap with a bridge letter (or gap letter) — a management-signed statement that nothing material has changed. It is a representation, not auditor-tested assurance, so industry practice limits it to roughly 90 days, and any open exception should be represented honestly in it. A bridge letter can never substitute for a fresh Type II.

How to catch these before fieldwork: a pre-audit self-test

Nearly every finding on this page is cheaper to fix before the observation period than during it. The highest-ROI move is to run a readiness assessment to catch these before fieldwork, then fix design gaps while the clock has not started. Understand where in the audit timeline exceptions surface so you are not remediating under deadline pressure, and remember that over-scoping creates more places to fail — scope tightly.

A simple self-test: for each of the top-12 findings, can you produce, right now, a dated and signed piece of evidence that the control operated? If the honest answer is “we do it but nothing is saved,” you have an evidence problem, and repeated remediation cycles are exactly what inflate audit cost. Building durable evidence capture now is the single best predictor of a clean report.